It’s a Grasshopper script but from c# I’m using:
.CameraUp , .SetCameraLocations() .ZoomBoundingBox() methods to set the camera/view as I need.
Then I use RhinoView.CaptureToBitmap to take screenshots.
It works, but sometimes the geometry is really heavy and the meshing takes long time and .CaptureToBitmap actually create an empty image (just background color).
Same thing if I try to take screenshots sequentially, moving the camera/view in between a .Capture and the other.
I tried with RhinoDocument.Views.Redraw(); and System.Threading.Thread.Sleep(); but with no luck.
What is the best approach to take screenshots in an automated workflow, with heavy geometries to display and many sequential screenshots in different camera positions?
There is a method like “wait until the grasshopper preview are fully completed”?
Any ideas?
You might want to run your script outside of grasshopper. Without actually running your definition and repeating what you are seeing I can only guess at what is happening. Computation in Grasshopper and drawing the GH geometry on Rhino views are two separate steps and there’s a chance that your script is running in GH before the display step has taken place.
Ugh… What I need is broadly different from animate slider…
I literally have a huge .gh definition that is processing heavy geometries.
After those geometries are processed, there is an “unknown” wait time until the GH geometries are properly displayed on the Rhino viewport (do an hook-able event exist for this?) … currently I’m using a data-dam with 0.5 sec delay…
Lastly a c# script properly set the viewport camera position and boundingbox and do the screen capture via Rhinocommon.
My script IS grasshopper, a .gh file.
You mean to put the Rhinocommon part that do the actual screenshot in an external process… ok! But how can I know when I have to call that process? It seems the same problem to me…
I cannot share the code, it’s months of work under NDA…
There are 30-ish c# scripts here, most of those with at least a hundred rows of code.
The last step is “waiting” for everything to finish (with the data-dam) and do the screenshot:
You might want to experiment with listening to a SolutionEndEvent and have your capture kick off after that instead of waiting for a certain period of time.
