I have a decent computer. However, when I hatch many curves in one go. Rhino seems to hang for a while. I am talking about only 1000 curves and I apply the hatch function.
Is there a way to speed it up? At the moment, I have to do the hatch in batches, as the time it takes seem to me is growing exponentially.
Rather than doing hatch, is there a way easier way to color in the curves with a color?
I cannot use the array function. The image above is just an example. The holes can be located randomly and the size can be different. So array is not an option.
if you access hatching by code you can significantly improve performance by not passing the curves as a collection, but rather iterating through each curve and say hatch me.
If you have Grasshopper, you can access this little script: 10000 crvs took < 30 milliseconds for everything
A couple of years later this is still a problem! The standard hatch command took more than 5 minutes to process something in the magnitude of 10k circles. This is basic functionality, something should be done about it!
Something tells me this may be due to the Rhino hatch functionâs âboundaryâ option. Even if itâs not active, if you preselect the curves (with 10K for example) it will spend all of its time âsortingâ⌠Here 10K circles also take 4.5 minutes - in V6. And Esc cannot quit the commandâŚ
Using a Python adaptation of Tomâs GH script above, I can hatch the same 10K circles in 5.6 seconds.
import rhinoscriptsyntax as rs
import scriptcontext as sc
import Rhino, time
crvIDs=rs.GetObjects("Select curves",4,preselect=True)
st=time.time()
crvs=[rs.coercecurve(crvID) for crvID in crvIDs]
for crv in crvs:
hatches=Rhino.Geometry.Hatch.Create(crv,0,0.0,1.0)
[sc.doc.Objects.AddHatch(hatch) for hatch in hatches]
sc.doc.Views.Redraw()
print "Elapsed time={:.2f}".format(time.time()-st)
@pascal, I donât see anything in youtrack on this, the current WIP appears to have the same problem here, so can someone check this on your end?
@pascal, all
I was thinking about this some more this morning⌠there is a difference between running the scripted procedure and the Rhino command.
The Rhino command Hatch looks for nested curves - for example if you have one closed curve inside another, it hatches between the curves. So, when you have a lot of curves selected, it has to check them all against each other for ânestednessâ. With a brute-force approach, the time to check goes up exponentially with the number of curves. Certainly with some smart programming (tree, etc.) the time to check and classify can be substantially reduced, but it will still be significant I think.
With the scripted procedure above, you are just asking it to make one hatch per curve, without worrying about the relationships between them. Thatâs really simple, so it just runs - bang!
That is not to say the current implementation of the Hatch command cannot be improved - perhaps the nesting check is not optimized yet - but it also perhaps argues for an additional command/option of âone hatch per curve - just do itâ. Of course that is easily scripted as above.
Hi Mitch - yes, good point⌠Here, or rather there, at the office, on a proper machine, 10,000 circles never finished, I had to stop Rhino from Task Manager⌠So for sure there is something to look into at least - thanks for the heads-up everyone.