Grasshopper

algorithmic modeling for Rhino

Hello guys,
I would like just a quick feedback about this ...I notice a very slow performance using grasshopper even with simple definitions. Sometimes it takes ages to update a model for even simple changes i.e. increasing a slider of just 1 step ! Do you notice this too or do you think this is not normal? Is something that can be optmized or it depends on the machine or algorithms the plugin is made of? I am hoping that if I update something in the gx definition then the feedback is kind of real time or am I wrong?

Just to give you an idea if you look at the simple def attached it takes ages to update if just move back and forth the N slider input. It takes 1-2 minutes to update!!!
here are my machine details
CPU Duo T9400
Memory 4GB
HD 320 GB
nVIDIA GeForce 9650M GT 1 GB
Os VistaPremium

Views: 255

Attachments:

Replies to This Discussion

Hi Giulio,

Although the slider is just a single number, changing this one number causes the entire document to be recalculated. You're generating thousands of Polysurfaces in this document which is bound to be slow. The viewport takes a long time to redraw, which is a known issue (especially with custom materials for some reason currently unknown to me). Hopefully we'll be able to speed up the OpenGL part of Grasshopper soon. The time spend calculating data however is there to stay.

If I remove everything display related from the file you posted the speed becomes a lot more acceptable. Are you seeing the same effect?

--
David Rutten
david@mcneel.com
Seattle, WA
To put this on a somewhat more scientific basis... When I profile this particular file (only opening the file and solving the initial conditions, I'm not dragging any sliders yet), I get the following performance table:


The RegenAll section (redrawing both the Grasshopper UI and the Rhino viewports) takes up three quarters of 90% of the total runtime. In fact, the time it takes to redraw Grasshopper is only about half a percent of this, the rest is spend drawing Rhino viewports.

The actual solution (listed under SolveAllObjects) takes only about a sixth. Which is still a lot actually, but way, way less than the time it takes to paint the result.

We're working on a new DotNET SDK for Rhino5 (which will be available in parallel with the old one) and I'm slowly migrating Grasshopper over bit by bit. We're hoping to get much better performance this time around and there's a lot we can do about display.


So, to answer your question... I know it sucks now, but the future does look brighter.

--
David Rutten
david@mcneel.com
Seattle, WA
Hi David,
thanks for your reply. It is always unvaluable. Yes of course I tried to disable the preview and enable it again once the solution is calculated or I switched to wireframe to increase the speed. The point actually is another and that would be helpful the experience of other users..
I mean even if the def I attached generates thousands of polysurfaces it is relatively simpler compared to those I see around on variuos blogs with lot of parameters that generate very complex geometry (like in the scripting gallery on rhino3d).

How do they manage those definition if the only setting they can adjust is the visibility? Is this an issue of usability itself? I mean isn't there any other setting to optmize the calculation at moment? What computers do those guys use??? XEON? Have you maybe some videos to show complex def and to do they behave in those cases?
I meant valuable and not unvaluable ... sorry to exchange :-)

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service