algorithmic modeling for Rhino
it generates a picture on every change of a parameter. If this is working for you...i show you how it works.
It might be, that when you're calling the Rhinocommand it only captures the Rhino content...not the GH stuff, that is attached to the display pipeline. However this script is calling RhinoCommon and it captures also GH content.
I do have another version, where you can disable the world axes, grid and so on...i can try to find it and send you that also...if the method from the other post works for you.
works perfectly! For my personal progress: Is there any possibility to get the code ? :)
I'm happy, that it works 4 you...have found a much more updated version of this script on my pc...take a look at that (attached)
If you need some extra things, i can integrate them, just tell me. Here is the important part of the script:
Rhino.Display.RhinoView rv = (string.IsNullOrWhiteSpace(view)) ?
rv.CaptureToBitmap(false, true, false).Save(filepath, format);
See the SDK for more info: http://4.rhino3d.com/5/rhinocommon/html/AllMembers_T_Rhino_Display_...
Thanks Florian, it worked well!
But it seems like there are dependencies to the order of creation of GH-Components.
This has influence to the order of redrawing geometries in GH/Rhino.
Here the manual capture and the automated:
Geometry components created after the capture components are not visible.
So the viewCaptureToFile Script works as well as the CaptureToBitmap method!
I didn't know that, but it's interesting. It definitely has to do with how the sdk is built. You might get around by Cut and Paste the script once you have everything on the screen, that you're going to capture.
I think you can report this to Steve or Dale at McNeel, this should be fixed.
Did you find out solution for your above view capture issues....
I am facing similar problem
I don't know if you are still stuck on this point (I guess not but who knows) but I faced a similar issue today : by using "viewcapturetofile" through a GH VB Script, only part of the geometries where actually visible on the resulting image.
Found a workaround : call the command twice. Should the first image be crappy, the second which overwrites the first is always good for me.
ScreenshotName = path & "\" & Name & "_Image" & ".jpg"
myDef = " -ViewCaptureToFile " & Chr(34) & ScreenshotName & Chr(34) & " _Scale=1 _TransparentBackground=True _Width=2180 _Height=1024 _Enter"