OctaneRender for Rhino Beta 1.20.1 [OBSOLETE]

[jitendra]

Paul,

Where can we download the 32 bit version of the plugin?

Thanks.

[face_off]

I have not packaged a 32bit installer yet (since I've have no one running a 32 bit system to confirm that it works) - so if you email me at paul at physicalc-software dot com, I will do a test build for you and send you the link.

Paul

[newske]

Sorry - I missed responding to this one...

Yes, this will be in the version after the next one. There will be an option in the configuration to progress to the next frame without reloading the scene into Octane IF the Viewport is open. This is how it works in the ArchiCAD plugin and it works very well.

Paul

Fantastic, I very much look forward to it. Thanks Paul.

Octane has been famous for its Node Graph Tree.
What if the Rhino plugin for Octane have Grasshopper components? It would be a win-win plugin.
Maxwell already has this as available here: http://www.food4rhino.com/project/scarab
Thank you. Keep the good work up, Paul.

An interesting idea, but probably a lot of work and probably not what the focus should be.

However, it wouldn't be particularly difficult to just observe the file structure for materials and bake material from grasshopper into files locally stored, and link them into Octane. It wouldn't really need to be Paul or an OTOY dev to do that, either, just someone with a little bit of spare time. Not particularly efficient, but it looks like that's what Scarab is doing - It looks good at applying things to GH geometry but inefficient if you're trying to modify things in realtime without baking - though I could be wrong. Have you tested Scarab jitendra?

[face_off]

Octane has been famous for its Node Graph Tree.
What if the Rhino plugin for Octane have Grasshopper components? It would be a win-win plugin.

There are also other nodegraph solutions available for .NET (which RhinoCommon is based on) which I have looked at. What holds me back from doing it is 1) It is a lot of work for minimal benefit (you couldn't actually do anything that you can't do now), 2) I'm pretty sure no one would use it. If you saw the nodegraph for a typical Rhino scene, it is a massive, jumble of nodes, and I just don't see people being prepared to lay it all out in a presentable way, when the tree can be used without any extra effort.

So the cost (in time) would be high, and the benefit low. And I'd rather spend that time adding features which do benefit users.

Paul

[jitendra]

However, it wouldn't be particularly difficult to just observe the file structure for materials and bake material from grasshopper into files locally stored, and link them into Octane. It wouldn't really need to be Paul or an OTOY dev to do that, either, just someone with a little bit of spare time. Not particularly efficient, but it looks like that's what Scarab is doing - It looks good at applying things to GH geometry but inefficient if you're trying to modify things in realtime without baking - though I could be wrong. Have you tested Scarab jitendra?

You are right, this is not for now, but for future. I do not want Paul to be out of focus.

I have not yet tested scarab, but the potential of using scarab is high.

Checkout this here: http://www.grasshopper3d.com/forum/topi ... h-vraytoon

The workflow is very interesting for animation with changing material properties for each frame, but yea, probably this is not someone's requirement at the moment.

Thanks.

[jitendra]

There are also other nodegraph solutions available for .NET (which RhinoCommon is based on) which I have looked at. What holds me back from doing it is 1) It is a lot of work for minimal benefit (you couldn't actually do anything that you can't do now), 2) I'm pretty sure no one would use it. If you saw the nodegraph for a typical Rhino scene, it is a massive, jumble of nodes, and I just don't see people being prepared to lay it all out in a presentable way, when the tree can be used without any extra effort.

So the cost (in time) would be high, and the benefit low. And I'd rather spend that time adding features which do benefit users.

Paul

I understand your point of view.
I am gonna send you an email regarding the 32 bit octane version. Thank you.

[jitendra]

Hi Paul,
There has been a strange shadow coming when objects are touching each other.
I changed to many HDRi and found the same issue.
It behaves like a default light in the scene, although there is not any light other then the HDRi.
Is that because of zero aperture?

[Refracty]

try ti decrease rayepsilon to 0.00001

[vanhage]

Paul,

First off, just want to say thanks. I've been waiting for octane in rhino for over 9 months. Now I finally make decent renderings quickly in rhino! All the best to you (and your team?) for what you've accomplished.

With that said, I have noticed a few things and wanted to offer suggestions for future improvements.

-The camera properties in the render kernel can be affected by the viewport size and proportion. Invariably this means the same file will render differently depending on the screen size and viewport configuration from computer to computer. It would be helpful to have a way to lock the camera properties so that they aren't reset when you re-activate the octane render viewport.
-It would be nice to be able to save different Sun/Environment settings per render target (like in standalone). If there was a way to break the link with the rhino sun and keep the values in the view's render target, that would be great.
-For blocks which contain objects on layers that are off, the objects are visible in the render window. This can be worked around, but in an architectural context where teams of people collaborate to make the model, it seems odd to have to explode or delete geometry for the sake of the render.
-For the ground plane from Rhino, I can't seem to adjust the material as it is not visible in octane's material tab. How is this assigned?
-It feels like there could be an easier way to manage and tweak octane materials. A preview window would be helpful as well as the ability to import standalone materials.

Thanks and keep up the good work,
-Pete

[face_off]

Hi Pete - thanks for the feedback.

-The camera properties in the render kernel can be affected by the viewport size and proportion. Invariably this means the same file will render differently depending on the screen size and viewport configuration from computer to computer. It would be helpful to have a way to lock the camera properties so that they aren't reset when you re-activate the octane render viewport.

Clicking the Resolution Lock on the Setup tab and then saving the file should address this issue.

-It would be nice to be able to save different Sun/Environment settings per render target (like in standalone). If there was a way to break the link with the rhino sun and keep the values in the view's render target, that would be great.

If there is NO Rhino sun I could have the Octane sun editable. You could then save the rendertarget to different Rhino Views, and the sun could be manually positioned differently in each.
I will do this in the next version. If you turn the Rhino sun back on, this will overwrite the manual settings.

-For blocks which contain objects on layers that are off, the objects are visible in the render window. This can be worked around, but in an architectural context where teams of people collaborate to make the model, it seems odd to have to explode or delete geometry for the sake of the render.

You are right - this looks like a bug. I will try to fix for the next version.

-For the ground plane from Rhino, I can't seem to adjust the material as it is not visible in octane's material tab. How is this assigned?

I will fix this. The Octane ground plane material should be linked to the Rhino material assigned to the ground plane.

-It feels like there could be an easier way to manage and tweak octane materials. A preview window would be helpful as well as the ability to import standalone materials.

A preview window is planned, but I am cautious because the implementation is not straightforward and I want to make sure the plugin is 100% robust before adding something like this. Importing of standalone materials may be possible in a future very of the Octane library, but is not currently possible.

Thanks again for your feedback.

Paul