Every edit of a control point with native Rhino fires HistoryReplay. CSCVModeling isn’t telling Rhino the surface updated after a single edit or even after you click Ok and close the command. I’m in this loop of calling CSCVModeling, making a couple of edits, click okay to exit the tool, call HistoryUpdate All, and starting CSCVModeling again.
This is a big pain for me. All of my surfaces are decorated and have precision requirements. For example, the minimum distance from girdle to girdle must be 0.25mm, or else my setters start to break diamonds.
If you can get Rhino updated after every CP edit, please have the undo/redo call Rhino’s native _Undo. I have a hotkey on the space mouse for ctrl+z, which is burned into muscle memory. God only knows what I’m actually undoing in the background, but exiting CSCVModeling means I can’t redo anything I accidentally undid.
Hi @EricM,
this a request which is challenging pretty much the architecture of Cyberstrak…
First: Normally I would expect that pressing OK in the CSCVModeling dialog should force Rhinos history update, since I just add the modified object to the Rhino document, also Rhino’s Undo/Redo can access it from this moment on. If this does not work I have to ask McNeel dev if there is anything I can do to support it.
The other request (every edit of a CV inside the dialog should fire immediately Rhino doc update including history update and Rhino Undo/Redo) is more complicated. The current way (when you select something to modify: Take it away from Rhino, do a local Undo/Redo stack until the user presses OK) is implemented by intention. And a lot of users like it very much, also because after 50 edits the Undo chain is shrinked to a simple step aftere leaving the dialog. If I support parallel commands which is planned for a later version this would support several local Undo chains in parallel which would not be possible if I add averything immediately to Rhino.
The only solution I can think off is to offer a special mode for CSCVModeling which will exclude parallel usage to other commands later on. I will think about it, maybe I come back in some days with a prototype that can be judged.
Yes, that is what I prefer, an option for it to work like native Rhino editing. And if that special mode isn’t an option, maybe you could add a “Push” button between “Cancel” and “OK”? Push the updated surface and the local Undo/Redo stack to Rhino while keeping CSCVModeling open and the surface editable. Like pushing a checkpoint?
It is not updating History, but Rhino is getting a new Undo point. The problem is pressing Ctrl+Z during CSCVModeling is going to Rhino’s Undo stack, not yours. Here, I will create a bunch of points, start CSCVModeling, and press Ctrl+Z. Sometimes, it does nothing (neither Undo stack affected). Other times, it undoes the points in Rhino’s stack, but it never undoes the CSCVModeling stack.
Closing CSCVModeling means I can’t redo anything I accidently undid.
I’m also not sure why it flips the surface normal sometimes (backface shade = purple), but that is also annoying when you have objects flown on the surface.
If I would add optional Save every edit step, Ctrl/Z should work then. Currently the local Undo Stack in CSCVModeling does not receive the key.
I will do some experiments, maybe there is a way to support this.
For the normal flip: If just CVs are moved, I would not expect any influence to u/v orientation or normal direction since just CV locations in the surface are changed. The only possibility why this could happen would be degree or span change (especially decrease causes a re-approximation of the surface). A repeatable use case would be helpful.
I can confirm this.
Since I saw this as a minor nuisance I didn’t bother to look into what exactly causes this.
Next time I encounter this problem I will try to find out.
Hm, it took me a while to understand the problem.
Rhino stores every surface as a Brep, even if it is untrimmed. The Brep has a face which shows the normal direction you see (and what is reflected by back/front color). The underlying “real” Nurbs surface which is edited by CSCVModeling may have another orientation. So I have to handle it somehow…
Concerning Undo/Redo: After investigating it taking you small video into account I have to say it is not easy at all. There can be mixed Undo/Redo events - some for CSCVModeling, others for other commands executed in parallel (like your points creation). In native Rhino this can never happen, since only one command can be active at a time.
At least CSCVModeling needs to listen to object change events coming from Rhinos Undo/Redo and needs to filter out events related to the selected object.
I can understand. This is why I would prefer that your tools operate as native Rhino tools, like MoveUVN, where each individual change is pushed to Rhino (foregoing the local Undo/Redo stack).
That said, I am definitely not your target user (I heavily rely on history).
I’d like to know if @sgreenawalt thinks the local Undo/Redo stack has any value.
You would still have the Undo/Redo ability. The difference is that you would have access to all the steps once you complete a command.
Currently, each edit you make during a Cyberstrak command is stored in a local Undo/Redo stack. When you click ‘OK’, Cyberstrak commits that local stack into a single update to Rhino’s Undo/Redo stack. You lose the ability to Undo each individual edit made while the tool was running.
This is a pain point for me. I wish it worked like MoveUVN, with each Undo/Redo available even after you close the MoveUVN panel.
The important thing is that it’s inside the command - how it achieves this is less important, at least to me. So long as it’s part of the command UI/box (a dedicated button on the pop up), it’s cool.
Okay, the only consequence of my request is that it would eliminate the single check-in to Rhino’s native Undo at the end. After each edit, I need the surface or curve updated in Rhino to see History reflow my bits and bobbles.
@Peter_Salzman, I know this is a big ask. I don’t know if you want to poll others to see if anyone relies on the single undo at a command’s end, but I imagine most of us are okay with it working like a native Rhino command.
We are used to the many existing native interactive commands (ShowDir, BoxEdit, MoveUVN, MeshRepair, Zebra, etc), and I imagine that conforming to the expected behavior would eliminate future issues with other odd use cases.
There’s no change to how CSCVModeling works while you are using it. The difference I’m proposing is what happens after you click “OK” and close CSCVModeling.
Currently, if you make 10 changes to control points and click “OK”, those 10 edits get squished into a single undo. You can’t partially undo the edits you made with CSCVModeling. It’s all or nothing.
I would like all 10 edits to remain on the Undo stack after clicking “OK”, the same as we have with MoveUVN.
I love that and don’t want it to change. But I also want to work this way with other Rhino commands as well. CSCVModeling would be so nice for creating a base for FlowSrf, but I’m stuck using a gumball, rebuild, and MoveUVN. Cyberstak isn’t telling Rhino when something is edited, so:
For other commands to work with CSCVModeling, Cyberstak would have to start telling Rhino about each edit rather than presenting everything you did as a single edit when you click “OK”.
Hi! The current implementation is very similar like VSR worked. At VSR you were even able to have multiple modeling commands in parallel (e.g. model the reference surface(s) while Matching or Blending to it). And every command had a separate Undo/Redo stack. That was seen as a pretty cool thing as far I remember.
Anyhow, I will do some experiments to see if an alternative way to the current approach can be offered optionally.
While doing this I will work on some fixes (e.g. the Normal Flip). Btw, currently the support of face edges and surface curves for Matching is nearly ready - it will come in 1.5.