I had numerous cases where I lost important input curves after I projected them onto surfaces, due to the “DeleteInput=Yes” option being persistent across the Rhino sessions (Rhino 7). My suggestion is to either make that option single-take (automatically resets to “DeleteInput=No” for the next run of the command) or add the “deleted” input curves into their own dedicated layer called “Deleted backup geometry”. That will ensure that the user will not lose valuable input geometry by accident. In most cases the user realizes too late that the deleted curves can’t be restored, because the process is silent and there is no warning for that.
You can do that yourself by using the following macro in place of the standard Project command:
! _project _multipause _project d=No _EnterEnd
This works because if you set the command option, the new value still sticks even if you then cancel the command. We run a second Project, set the option and cancel the command before it gets to the user prompt.
Tested in Rhino 7 only.
Regards
Jeremy
Thanks! That works when the macro is ran before selecting the input curve to be projected. Howeber, the only issue is that when I pre-select the input curve and execute your macro, the command is still active and the Command line message is:
Select surfaces, polysurfaces, SubDs and meshes to project onto
Try adding a _SelNone before the second _project:
! _project _multipause _selnone _project d=No _EnterEnd
That seems to make it work with preselection too.
But the macro language is very limited and has no branching capabilities, so if you make a mistake in your selection you will likely see similar oddities and have to escape out as we can’t add any error handling. I’ll leave you to judge whether the benefit outweighs the hassle.
I tend to avoid the issue by leaving DeleteInput set to No and manually deleting the input afterwards on the rare occasions I don’t want to keep it.
I tried the new macro, but the Command prompt still asks me do select more object to project onto. At least in my Rhino 7.
The persistent nature of the “DeleteInput=Yes” option is dangerous (even more than crashing Rhino), because it may lead to unwanted deletion of important curves. I also prefer to not delete the input curves, but it’s necessary when projecting control points of a surface over another object. I often project a surface over an inclined flat surface that way, as well as when i do a reverse engineering over a scan data.
The method shown in the video below is more accurate if the surface has much more dense control points, then the projected surface could be rebuilt to something more simple for manual adjustment.
What do you mean with “branching”? Was not the * symbol used to stack commands in macros? Or I misunderstood it?
By branching I mean if x happens take the actions in path a, otherwise go down path b.
Now I got it. Your macro needs one press of the Esc key to cancel the command entirely when the input curve is pre-selected. Sadly, I fail to make a macro that emulates the Esc key. The _Cancel command added at the end of the macro also does not work in this case.
From the Rhino wiki, it seems the macro feature can’t cope with setting a variable number of command options. You should find the above macro completes correctly if you access precisely one option (and regardless of how many times you access that one option).
I may be wrong but the script should work if you change multipause with simple pause:
! _project _pause d=No
That macro executes the command exactly the way I expected. Thank you!
Must be a default “Project” command in the future Rhino releases instead of the current basic command.
in a more general sense this topic asks the question, wether / which options should be saved globally and survive sessions, or should be be refreshed to default values each restart.
i think rhino is a bit inconsistent here:
for example _offset bothside=yes will not survive for the next call of the command.
whilt through point will store the value (not the behavior “through point”)…
i quite often get annoyed when i 've used _trim keeptrims=yes … which will survive to the next call or - not sure - next session… and suddenly i have former trim curves all over my file…
_extrudeCrv remembers the last extrusion distance from last session
_filletEdge always starts with R=1 on a new session.
i am asking nothing, this is not a wish - it s just an observation.
the options are not consistent.
You are setting the deleteinput option to No before running the command which is much simpler than trying to reset it after. A very sensible piece of lateral thinking!
Using the macro to automatically reset the DeleteInput option after each run is a neat solution, and it makes sense how the double _Project call ensures the option gets set and then canceled cleanly before the user sees the prompt.
I’ll definitely give this a try in Rhino 7 and see how it behaves in later versions too.
Appreciate you taking the time to explain the logic behind it
I like the idea of having different settings across all Rhino tools, such like always starting with 1 mm (1 unit actually) for the fillet tool. However, as @Tom_P mentioned above, there is a huge inconsistency across the different tolls in Rhino. Some will remember the “DeleteInput=Yes” options, others won’t. Every setting related to automatic deletion of the input geometry must be set as a single-take to prevent accidental loss of primary surfaces and curves. That particular behaviour will ensure that the deletion is only possible right after the user sets the “DeleteInput=Yes” option on purpose.
Note that @jim 's FilsrfEX.py script does something clever by adding a dedicated layer called “BaqUpz” where it stores a back-up copy of the original input geometry.
Hi Abdullah,
It would if if could be made to work in all circumstances but, as we’ve found, you can’t get the macro to cater for a variable number of option settings. @skysurfer’s approach of setting the critical option before the command runs is functionally identical, simpler and avoids the variable options issue completely. Go with his approach!
Regards
Jeremy
I’ll definitely give this a try in Rhino 7 and see how it behaves in later versions too.
Appreciate you taking the time to explain the logic behind
i hope this helps
What happened to that crucial setting? Was it included somewhere in Rhino 9 as an advanced option or hidden command?