Page 4 of 4

Re: Rhino Live announced..if only

Posted: Wed Feb 20, 2013 3:51 pm
by vanhage
I've asked this in another thread, is the octane sdk available so we can begin to create our own tools while we wait for an official rhino plugin to be released? I was so impressed with octane when I tried the demo that I bought it and am trying to find more and more ways to integrate it in my daily workflow(Architecture). I've already written code in grasshopper to automate the scatter node and I'd be curious to see if I can find other ways of linking octane and rhino through scripting to begin to automate certain tasks and make it more "live". Some ideas:

-Set current octane doc sun parameters based on current rhino doc sun parameters.
-Create octane cameras from selected named views in rhino

I'm no developer, but I know enough about programming that I can put together a tool for a specific purpose. The rhino community is very DIY and I think if you can't deliver on a live plugin, let us find our own solutions in the meantime and help build up the rhino/octane user group.

Re: Rhino Live announced..if only

Posted: Wed Feb 20, 2013 3:54 pm
by justix
Refracty wrote:Good marketing, nice feature list and sample images and when you start to try you get stuck.
Apparently it could not be easier but still..error in toolbar and active viewport rendering..nothing than watermark.

Re: Rhino Live announced..if only

Posted: Thu Feb 21, 2013 12:34 am
by newske
vanhage wrote:I've asked this in another thread, is the octane sdk available so we can begin to create our own tools while we wait for an official rhino plugin to be released?
I spoke with them on this issue when the issue was first announced. They say that they are unable to release it publicly due to "licensing issues". Otherwise, with both Octane and Rhino's SDK public it would be a dream for those of us, like you, who know a little bit of programming but not to the extent of writing an entire plugin.

I have done a few Python scripts for exporting to Octane.
The key ones I use are:

  • Export named views
    Path animation
    Flythrough animation
    Scatter UV coordinates (ie. grass, forests)
    IVY growth (agent based) scattered leaves


They're not entirely gamechanging, but they come in useful, particularly the animation which would otherwise be difficult. Also means you can get camera motion blur, which is nice.
Motion Blur
Number of Frames (override)
Number of Samples (override)
Resolution (override)
Shutdown on finish
Rendertarget (containing all details)
*.exe octane location
*.ocs location
*.png out location

Everything else is determined by the rendertarget set up in the octane scene -- though it would be easy to make it do anything that is currently available in the command line options for octane (--help).
Currently speed is linear (whereas in Rhino it is based on control points I believe) though that would also not be hard to include.
I've also mentioned to them how changing the way .bat files are used could greatly enhance the standalone -- (by reading .txt files in one line rather than one render per line) it would be greatly more viable to render in the standalone (without the cost of reloading and revoxelizing every frame).

It would be do-able to export the sun settings, given the Rhino SDK has all the features you need:
Rhino.Render.Sun class properties
Altitude
Azimuth
Enabled
Latitude
Longitude
North
Vector
However, to actually get it into a .ocm is a pain in the ass. The way we've done it previously with named views and scatter nodes (which we don't really do anymore, just export to .txt and link the .txt) is to use an xml reader and search the file and replace. Again, very inconvenient, slow and a pain to write.

It'd be easier just to write a snippet of code to do the math and print what you should set the figures to...