Re: OctaneRender for Rhino Beta 1.20.1 [STABLE]
Posted: Sun Aug 25, 2013 8:14 am
Paul,
Where can we download the 32 bit version of the plugin?
Thanks.
Where can we download the 32 bit version of the plugin?
Thanks.
Community Forums for OTOY Customers
https://render.otoy.com/forum/
Fantastic, I very much look forward to it. Thanks Paul.face_off wrote: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
An interesting idea, but probably a lot of work and probably not what the focus should be.jitendra wrote: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.
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.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.
You are right, this is not for now, but for future. I do not want Paul to be out of focus.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?
I understand your point of view.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
Clicking the Resolution Lock on the Setup tab and then saving the file should address this issue.-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.
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.-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.
You are right - this looks like a bug. I will try to fix for the next version.-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.
I will fix this. The Octane ground plane material should be linked to the Rhino material assigned to the ground plane.-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?
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.-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.