What is the current state of Rhino’s implementation of cycles in terms of features compared to Blender? How far behind is it and is there a list of features that are (still) missing? And finally, can I expect to export my Rhino scene to Blender using FBX or the .3dm import (as discussed here: Using Rhino3dm in Blender) to also export any materials created in Rhino to Blender?
I am currently working on updating our Cycles codebase to the 2020.09.10 version that is in the Cycles standalone repository. From our previous version that is 330 commits. Lots of changes, including a number of code rewrites that will take a time for me to adapt our patches to.
Our version of Cycles has a number of features that do not exist in upstream Cycles
- clipping planes
- rhino-specific texture coordinates
- rhino-specific image/environment mappings
- matrix math node
- rgb to luminance node
- shader lives on object instead of mesh
- different sampling loop
- different mechanism to pull out render results
This means an exact match between Rhino and Blender is not possible unless all patches are landed in upstream Cycles - which is not very likely to happen for a number of reasons that I won’t go in here.
I hope to be able to improve the import_3dm add-on I created by using Rhino Inside in the near future. But a 100% exchange between materials is not possible due to the fact that we have some features in our Cycles version that do not exist in Blender.
Thanks, that’s a clear explanation.
I am looking forward to see the progress further down the line!
One thing I forgot to ask, is there support for Render passes/elements to be able to use for post compositing? If so, could you point me to any resources to see how it is implemented specifically? This will help me to decide whether to use Blender or Rhino for rendering a commercial architectural project I am working on.
In terms of future developments, are there any plans to support a rendered view mode by using Eevee (or similar, more advanced tech for lookdev without having to render to see changes update in real time)? And finally, are there any plans to make a node based shader system like in Blender/ 3ds Max? Although this is pure speculation on my end, but such a thing might also allow Chaosgroup to implement it in Vray for Rhino and that may allow similar features in terms of shaders for both Max and Rhino.
There is support for some passes: combined, depth, normal, more are planned to be added. These are used in the post-effect pipeline in Rhino. For instance the depth pass is used in effects like dof, fog and the denoisers.
We are thinking of adding node-based materials using an embedded grasshopper canvas. But that is still far out. How useful it is for other rendering engines depends of course on the correspondence of nodes between the different engines. That said we have of course our existing material descriptions engines use to create their own representations.
Rendered mode is that mode. It isn’t Eevee, but it is the closest to that, and it is actively developed.
That’s unfortunate, I was hoping there were render passes for direct/ indirect lighting as well as for masking (Material/ Object ID, etc.). I guess Blender will be the go to for this project of mine then.
If I may add my 2 cents to this: it seems like a reasonable way to implement materials with a consistent UI, although I can see it being useful to have the materials in a different Grasshopper canvas than Grasshopper itself as to not convolute the canvas with all sorts of things. I do think it would be good to consider interoperability for shaders, including the use of OSL and Material X, when it is fully deployed in other packages as well.
3ds Max’ dev’s are making great strides to implement both. In case you are interested, there are a couple of dev talks from last month on the subject published on Autodesk’s youtube channel close to 1h of content each.
I figured you’d say so, good to know it’s also being worked on. Well then, keep up the good work!
We don’t have OSL enabled in our version of Cycles, and I don’t think it is on the table any time soon. I don’t know what material x is, first time I have ever heard of this name.
Material X is an open-source material definition (https://www.materialx.org/), a Universal Scene Description (USD) for materials if you will. I’m not well versed in the technicality of it, but Material X is supposedly render agnostic and transfers shader settings across programs. If you can spare the time, have a glance through the resources I provided, they can tell you much more than I can recollect and summarise well.
These are the presentations I was referring to earlier:
This one shows the intent to use OSL and Material X in conjunction with each other and explains how one acts as translator for the other. If a renderer does not support it, the code shader’s code is also implemented as part of the shader definition, at least that is the visionary intent. Autodesk is really trying hard to get this integrated.
Looks interesting. Maybe something to look into in the future.