[C++] Cage editing a custom surface object (CRhinoSurfaceObject-derived)

We have a custom surface object that has some additional drawing routines added to it to show some interesting aspects of the surface.

When we try, however, to use the CageEdit command on the custom surface object, the object is turned into an normal surface object after the first cage control point is moved (maybe even while it is moving, I’m not sure).

Is there some way that we can respond to these captive cage edit operations so that the custom surface object does not get replaced by a normal surface object? I have not been able to find anything in the docs, but am also a bit at a loss what to search for (cage, morphcontrol, captive, ???)

My guess is that in the normal Rhino scheme of updating an object with changes where the original object is copied, modified and then replaced with the new modified copy, that no provision has been made to accommodate custom objects. This probably would require some additional sophisticated programming to handle and was probably not deemed worth the effort at the time CageEdit was developed.

Just a guess.

That is what I fear - maybe it makes sense to do i like that, I don’t know.

Any suggestions on how to tackle this would be welcome. :smile:
Currently I’m thinking an eventwatcher that responds to replace events and checks if the custom object is about to be replaced by a normal object, then quickly re-creates the custom object. It seems a bit unwieldy…

I don’t know of a way of doing this. I’ve added a YouTrack item to document this limitation.

http://mcneel.myjetbrains.com/youtrack/issue/RH-29220

I’m curious: does this happen only with CageEdit, or any time the object is modified?

If yes, that would imply to me that your plugin would need to know anytime the object is changed so that it can rebuild the custom object. Rhino should provide such an event notification. Doesn’t it?

If not, that suggests to me that Rhino isn’t handling CageEdit changes the same as the others - and probably should.

Either way, it seems to me that V6 would be a perfect opportunity to add what it takes, especially if it takes a bit of tear-up.

As a matter of principle, it seems logical to me that if Rhino is going to allow plugins to use custom objects, then it should provide a transparent way of maintaining their custom characteristics through any changes made by Rhino itself.

1 Like

A normal replacement is handled fine, e.g. after moving or scaling, through DuplicateObject if I’m not mistaken. It is cage edit that silently down grades my custom object. Maybe also operations based on morph control will show this behaviour?
With this I mean Twist, Bend, Taper commands. I think these are based on morphing, rather than affine transformation.