Hi Andy,
Thanks for clarifying how to try to use Snapshots. There is a ton of issues with Snapshots and therefore we don’t use them. That is a topic for another discussion, maybe in another month or so. For this particular need, we still explored this some more, and tried a few things and we know for sure now this is not going to work. Not even close. Let me explain the realities of a production pipeline and our needs for a team of multiple users working in multiple projects, concepts, files, sometimes many people working on the same files, continuing each other’s work:
We work with pre-made material libraries. We don’t make materials in each of our projects. We design products. We assign materials to models from our highly curated libraries. We do change color, but also, that’s a separate subject, for now, listed as item #4 in my list.
When we assign a material to an object, we want to do it once. If we must assign for Octane + Rhino viewport by doing it twice we double our amount of work. We halve our productivity and we introduce a severe element of human error: what if we assign different materials to Octane and Rhino?
We want to see at the same time what a render is looking like (Octane/Vray material) and what a Rhino viewport is looking like (Rhino material). In fact, we need a system that allows us to have each viewmode/appearance/render engine to be a high-fidelity instance of each other. Dissociation between viewport and render engine creates 2 problems:
- We don’t know if we have applied the right material to Octane by looking at Rhino viewport.
- We don’t even know if we have a applied a material at all. And which parts are still missing material assignment.
So I’m going back to the problem that we need to solve, which is a problem introduced by the lack on integration between Rhino and production-level industry-standard render engines:
- We need to drag and drop materials to our models, from a library
- We need to always look great, consistent, and optimized in both viewport and render engine, and we, Fresco team, are the ones who judge and create that consistency. We need to know what material we have assigned to an object by looking at either our render buffer/window and/or our live Rhino viewport. Example: “Is that object in the model our ‘blue plastic DVI42’ in both the render engine when we hit render; and in the viewport when we work in our model and take screenshots?”. To achieve this, we will make 2 materials for “blue plastic DVI42” to show us the best way to show it in each: viewport and render engine. And we will not rely on either McNeel or Otoy or anyone else to give us what is their interpretation of integration or fidelity. We are curating this process ourselves.
The infrastructure work in our end, done once, and maintained periodically in medium to low frequency will look like this:
We make twin material libraries curated by hand by our team, in various folders: “rhino_materials” + “octane_materials” + “Vray_material” + … And we also need a new Rhino type of material, let’s call it “rhino_multimaterial” and think of it as a folder where we put inside each “rhino_materials” + “octane_materials” + “Vray_material” +… , and eventually we might add a “real-world_materials” and any other future need we have.
Everyday/designer workflow will look like this:
A designer just drags and drops materials from the library to the Rhino model. And everything just works. Rhino viewport screenshots looks fantastic, every single time. Octane renderings look fantastic, every single time. Designer is unsure if a material has been assigned to an object? They can just look at the viewport and they will see it. Right now when you are using Vray or Octane it’s impossible to know if you have the right material assigned to a part by looking at the viewport, even you cannot tell if you have assigned a material at all in many cases. And a viewport is called a viewport because is has ONE JOB: showing you what is going on in your model. Right now, Rhino in Rendered mode is failing miserably to achieve this.
Also please keep in mind that we don’t see a way in the near or even long-term future of seeing more integration between Rhino and 3rd party render engines.
Octane: They have 1 developer for all their plugins, Paul Kinnane, and he has been trying to do some basic level viewport fidelity limited to just de diffuse channel, and I can tell you that today even that is rarely happening, one example of our multiple fully documented requests to him here:
Vray: Their team has told me in person, before the release of Vray 4/Next for Rhino, that the only way we would see any integration into Rhino was by them making their own material editor and don’t even touch any feature of the RDK because it was a [redacted] [redacted] [redacted]. Don’t shoot the messenger, I’m just telling you for context. Also their materials look absolutely awful in the viewport.
We cannot let our business needs be subject to the whims of 3rd party developers desire, priority, expertise and dedication to do a great job and making their materials look stunning in the Rhino viewport. If you think about it: what would be their strategic need to have something that looks to great in Rhino, that people need to never render again? We have that need. They are trying to avoid it.
In summary for # 3 in my original list: we need a synchronous multi-material that shows at the same time Rhino materials in the viewport and render-engine specific materials for each render engine we use in Rhino (and in other products besides Rhino).
Please let me know if you have any suggestions to achieve this, or a better workflow than what I propose. Taking into account all the production needs, and industry realities that I outlined.
Best Regards,
Gustavo
