How exactly does RhinoCAM handle sorting of curves?
How exactly does RhinoCAM handle sorting of curves?
How does RhinoCam figure out the sorting of curves during the different 2-1/2d operations?
this plugin David Rutten is working over at Rhino looks pretty promising. Unfortunately RhinoCAM overrides anything that it does.
http://en.wiki.mcneel.com/default.aspx/ ... rting.html
http://en.wiki.mcneel.com/default.aspx/ ... rting.html
Ryan,
I find that it does more or less follow the order that David's plug-in creates. However I don't think that the plug-in is very well optimised yet. I think if we send him example files he can try to make it work better.
Of course it would be best if MecSoft included sorting in RhinoCam. It is really more their problem than Rhino's.
Nick
I find that it does more or less follow the order that David's plug-in creates. However I don't think that the plug-in is very well optimised yet. I think if we send him example files he can try to make it work better.
Of course it would be best if MecSoft included sorting in RhinoCam. It is really more their problem than Rhino's.
Nick
-
MecSoft Support
- Posts: 2405
- Joined: Wed Aug 01, 2007 4:15 pm
- Location: Irvine, CA, USA
- Contact:
The reason we have not responded is because this is not an easy topic since the order is not the same for different methods.
1) For Profiling - the order of profiling is in the order selected. If the user selected multiple profiles with rectangle selection or select all in Rhino then the order will be in order created.
2) For other operations such as V-carving, Pocketing and Profiling since the curves are ordered by the software ie) nested, interference checked etc. the curves that are used by the software can be quite different from the curves that the user input. In such cases the order can become scrambled due to the ordering process that the software goes through. In such cases sorting can possibly be implemented using a scheme similar to the ones in drilling. However, this is not currently available in RhinoCAM.
1) For Profiling - the order of profiling is in the order selected. If the user selected multiple profiles with rectangle selection or select all in Rhino then the order will be in order created.
2) For other operations such as V-carving, Pocketing and Profiling since the curves are ordered by the software ie) nested, interference checked etc. the curves that are used by the software can be quite different from the curves that the user input. In such cases the order can become scrambled due to the ordering process that the software goes through. In such cases sorting can possibly be implemented using a scheme similar to the ones in drilling. However, this is not currently available in RhinoCAM.
Thank you for replying.
For situation #1, you mention that it follows in the order selected, I am a little confused because you mention profiling in situation #2 also. Is #1 refering to engraving?
I understand that for operations like Facing and Pocketing it is difficult to follow the "order selected" routine, although some type of logical order should be followed if possible.
But for engraving using the To condition, you are referring to that as Vcarving correct, I don't understand why it can't follow the "order selected", but it does follow the "order of creation" method. There seems to be no standard between operations or even within the same operation. And in all reality it shouldn't come down to either of these. A user should just be able to window select the regions for an operation by window selection, be prompted for a starting point and it jump from region to region from the starting point of the curve.
Since David wrote the sorting Curves plugin I've been trying to wrap my head around this topic because I spend alot of time picking curves by hand and it is very time consuming, I'm talking 75+ curves. It seems that his plugin sorts the curves and then rewrites the creation time in the order that the plugin sorts. He also mentioned that he could even rename the curves in numerical order.
If 2 1/2 D operations and Profiling, Engraving using ON and engraving using To could follow either creation time or object name, then his plugin could help out alot. Although in reality like NScott mentioned this should be something RhinoCam handles.
The issue of how RhinoCam handles the sorting of curves for 2-1/2 D operations has been mentioned in the forums by other people than me for as long as I've been a user, about 2 years, and I am trying to understand why something this fundamental hasn't been addressed and implemented.
For situation #1, you mention that it follows in the order selected, I am a little confused because you mention profiling in situation #2 also. Is #1 refering to engraving?
I understand that for operations like Facing and Pocketing it is difficult to follow the "order selected" routine, although some type of logical order should be followed if possible.
But for engraving using the To condition, you are referring to that as Vcarving correct, I don't understand why it can't follow the "order selected", but it does follow the "order of creation" method. There seems to be no standard between operations or even within the same operation. And in all reality it shouldn't come down to either of these. A user should just be able to window select the regions for an operation by window selection, be prompted for a starting point and it jump from region to region from the starting point of the curve.
Since David wrote the sorting Curves plugin I've been trying to wrap my head around this topic because I spend alot of time picking curves by hand and it is very time consuming, I'm talking 75+ curves. It seems that his plugin sorts the curves and then rewrites the creation time in the order that the plugin sorts. He also mentioned that he could even rename the curves in numerical order.
If 2 1/2 D operations and Profiling, Engraving using ON and engraving using To could follow either creation time or object name, then his plugin could help out alot. Although in reality like NScott mentioned this should be something RhinoCam handles.
The issue of how RhinoCam handles the sorting of curves for 2-1/2 D operations has been mentioned in the forums by other people than me for as long as I've been a user, about 2 years, and I am trying to understand why something this fundamental hasn't been addressed and implemented.