Oh, that sounds like a can of worms…
What happens if you change it and don’t save the snapshot and then laod a snapshot and then want to go back? I imagine having multiple users using one file might cause some issues here (I will try it out one day)
Oh, that sounds like a can of worms…
There is a warning that appears when you attempt to load a snapshot without the current data being saved - including the materials.
Also, there’s always Undo - it even works with Snapshots.
The problem I see using your workflow, is that you can’t make use of existing material libraries if you want to override one material for another, am I right?
My current workflow when using more than a render engine is to have the same library built for both engines, i.e. I might have one gold metal created for cycles and another gold metal created for Vray. So what would like to achieve is to be able to override the cycles material by te Vray one.
One solution could be giving us the possibility to override a material by dragging another material on top of the current one, that way you don’t have to start from scratch every time you need to swap a material for another one. Does it make sense?
Yes, this is correct. However, we could certainly fix that problem - for example, by allowing you to replace one material with another. Or read a file material directly into an existing material.
That would make the workflow really smooth. Thanks
what about a material mapping table? depending on choosen rendering engine, a certain material could be applied to objects
Andy, but I think we already can import material from Library. Right?
I checked and it seems to be working.
And snapshots seems to be working as you described. I can change materials (even switch to Octane type or VRay) and all material settings saved in snapshots.
We don’t have anything like that, and no plans to do it.
Yes, but what you can’t do is replace an existing material from a library file. That would be required for library files to be used in that workflow.
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.
Continuing our discussion from this hijacked thread last week:
Please see my posts here in this thread above of my detailed explanation of why and how we need better support to 3rd party rendering engines.
Happy to have a call, or a few, to discuss anything you need to give you more context for our needs, that I think are also industry-wide latent needs.
I think we’d need to schedule a zoom call to see where the current stuff is falling behind for you. It seem to me from reading your notes that none of the current industry solutions offer what you need, not just ours…
For one, If you can’t get acceptable photoreal results out of keyshot, octane, maxwell, mavericks or cycles, then I’m thinking there is an issue in your pipeline we are not clearly understanding.
If it wasn’t for covid, I’d come work at your place for a week or so and see what is going on, but things as they are, we’ll have to piece together the story using other means.
Kyle, Getting photorealistic results from any/all of these above (leaving Cycles out of this for now) is an absolutely non-issue. We have great material libraries for them, good lighting scenes, and good hardware, so it’s a very easy, predictable process most of the time.
Photorealism is NOT the problem for us.
They problem is how unintegrated they are with Rhino’s viewport and material editor. And thinking than having a good enough workflow so I can made one pretty rendering, does not meets today’s standards in a production pipeline. We need to render serval concepts, in many setting, many view, animations, many CMF variants, that’s pipeline-level work. And in some cases, like I mentioned before, matching output from different modeling/animation packages, so a standard 3rd party renderer is the way to achieve that.
I have to finish some work now, but I’ll post later some examples of this terrible Rhino (material editor/viewport) to Render output integration. It sounds like you are not familiar with it? Do you have Vray and Octane? Does your team developing the rendering tools do? Are you all even aware of how bad this is?
Correct me if I’m wrong, but nobody does this well, or I assume you’d be using them?
Correct, and you guys so far are the best in the industry. That’s why I’m bitching here, we are so close!
This below is from our internal chat just now: sending out a ‘stay away from Vray 5’ warning, followed by Juan Santocono crying thinking he’ll have to use Octane… and there we are also thinking that if @nathanletwory gives us a good live-link Rhino.inside Blender we maybe don’t have to be such a pain in the ass about all this her anymore. And we can focus on nagging you on modeling things only, which we have plenty
I wish my job was easier sometimes. aaah…
Could you imagine me trying to explain to the Fusion360 team what Octane and Vray even is? Or a PBR material, or shutlining, or wanting to extrude a surface that is not planar?
Yeah, you are all the best of the best, now let’s get to work!
so, by your comment of wanting rhino inside blender…
are you saying that cycles in blender is mostly doing what you need?
No, Octane in Blender for now. It’s fantastic.
Once we are there more often we can maybe explore cycles in a fully featured environment, but I don’t see why when Octane just works so well.