EDIT:
This wish has been modified towards a content aware UI that collapses unneeded information from long menus and emphasizes settings and options relevant to the current renderer without deleting or completely hiding the Rhino basics.
ORIGINAL:
I would like to see a more clear UI distinction between render plugins in Rhino (Leave unto Caesar to the Caesar).
When I switch to the Rhino plugin I want to see only Rhino materials that are assigned to an object and if none the panel should be empty.
Right now it’s a small mess. A plugin developer adds their own materials into the mix and because all are visible into a long confusing list and they also have to worry about cross translations.
Maybe we can have a surface properties dialogue that tells us if a surface has materials assigned from multiple plugins.
a) Is it possible when a Rhino material is created to auto-apply a tag “Cycles; Glass” or “Rhino; Glass” etc and
b) If Rhino render is the current engine and we create a new material, is it possible to hide material options from the other plugins on that menu (with the plus sign) and vice versa.
Hm… I do not have any rendering plug-ins here - when Rhino is the current renderer, and you create a new material, you see material options that apply to a plug-in? That can’t be right…
… If I select “more types”, I get a list with everything, unless we go the extra step of specifically making a drop down selection to filter the list.
When vanilla Rhino ships there is only one render engine (cycles) and the whole interface (and materials) seem cohesive.
When a user switches render engines I would like the same experience; Rhino to behave as if Bella, (or Vray) is the ONLY engine Rhino shipped with and there are no visible traces of anything else. Like changing namespaces in programming.
On the other hand, engines that integrate with Rhino are supposed to also do a good job at understanding the Rhino materials (from Custom to Plastic). These are supposed to be compatible.
added:
Compatible in such a way that when using the Rhino materials and switching between engines results would agree to some degree.
But why ? Why should they ? If an engine determines that “specular” “reflectance” and “glossy” are not separate abstractions and prefer to implement a molecular physics UI why should unnatural conformity be imposed on them? Isn’t that more messy?
If there were discrete render UI spaces , everything will be in the plugin’s render space including all materials. Rhino materials would be hidden.
If I assign a hundred materials using Cycles and then switch render engines, I should see all empty materials panel. Everything should be white and I can assign materials using the new engine. If I switch back to Rhino I should get back all the Rhino materials again and the other engine’s stuff hidden.
Perhaps Custom isn’t the best of the group, but all of the other materials should be fairly straightforward to implement some good version of for each engine: gem, glass, plastic, paint - and even PBR, since it is based on a specification that is (supposed to be) universally well understood in the same way across rendering technology.
The idea is that you can assign your materials and still have them look good between the different rendering solutions with a fair degree of similarity. Without having to reassign materials just for the sake of trying a new engine.
You know the underlying engine is Cycles, but that does not matter.
The way to look at it is: you assign hundreds of Rhino materials - switching engines should not mean you have to reassign. Assigning a paint in Rhino means it should be rendered as a paint material. Regardless of the engine in use.
There is no way you are going to achieve that. I even challenge you. Your material system would have to so complex that ALL other engine materials would have to be a mere subset of yours to ensure infinite compatibility.
Try to bring in the Classroom scene from Blender and see how you translate all the shader node interdependency-hell in a seamless way between engines.
Once you download the Blender Classroom and you spend a few hours calibrating the Rhino materials and textures because nothing will be working correctly initially. Then I’d like you translating all 70 materials to a plugin such as Vray or Bella and render both or all three. I’d like to see how you organize yourself assigning materials of one engine and then assigning again for another engine.
After you are done I will take your scene and make modifications to some materials and I will randomly and accidentally assign some Vray materials and then some Bella materials to some objects so when you hit render there is a mixed bag of assignments. I’d like to see you sort out 210 materials and make sure when you hit render only Cycles materials are assigned to the render scene and then only Bella materials.
But again, the idea of the Rhino materials system is that a user applies “Paint”, then any render engine integrating into Rhino is asked to essentially give the best “Paint” material they can do for the given parameters.
The Rhino material system is not intended to give an infinite amount of knobs and sliders to flick around to get the best possible materials for a specific engine. It is intended to give a set of materials that functions as a common ground between all engines that integrate with Rhino.
You’re asking to fit a square peg in a round hole. Wrong task. Precisely because of the above. If a model has a Rhino Glass on an object each engine should try to do the best glass they can for that. Not the other way around.
Each engine is still free to provide their own materials, and they do. And those most likely won’t be compatible. There is a mechanism to do some crude translation from a special engine material to Rhino Custom, but it is that at best - crude. And that will work only when engine integration plug-ins implement those conversions.
But still, Rhino materials are supposed to be a common ground. And Physically Based material is the modern way, based on PBR, which should work between most engines with minor variations.
All other, engine specific materials should probably be otherwise engine specific: don’t show Bella materials when another engine is active.
That’s the part that doesn’t make sense to me as a user.
If I apply “Paint” and I know I am in Bella namespace, it’s because that’s what I want. If I then switch away from Bella namespace and into RhinoCycles namespace there should be no assignments. I don’t want any of you translating glass for me, I don’t trust anyone. I don’t want a sort-of close enough by someone else’s idea … and when I switch to Cycles namespace I don’t even want glass on that particular object I want it metallic now. So for one engine its glass and on the other it’s metal.
By trying to guess what I want as a user we amplify confusion. Like walking at Walmart about to bump on someone and you both try to guess each other’s moves and you mirror each other’s interference into a gridlock.
At the very least, can the Rhino material auto-generate for themselves a tag “Cycles” upon creation ? It would help do some manual separation. For the rest maybe we can use Snapshots to kind of patch things a little.
(On the general topic. I think people haven’t been nagging you because over the years, because plugins like Vray, or Maxwell were creating their own isolation bubbles (custom UI) and their stuff and materials were in their own separate databases. Once a developer like Bella decides to be a good citizen and use Rhino’s facilities, the lack of isolation gets apparent)
It doesn’t make much sense, since the Rhino material is a Rhino material. It is not just Cycles using it, also Rendered mode is using it. You should try to forget that Rhino Render behind the scenes is Rhino Cycles. The materials are not created specifically for it, they are created for Rhino.
Ok. the tag should read “Rhino” then. There must be a way to differentiate.
There is no such thing as just Rhino. It’s using a render algorithm. I need to differentiate render algorithms.
Also, rendered viewport is a basic view with suggestive color mostly helping in texturing. This basic color communication is something that can happen behind the scenes between Rhino and the plugins. Whichever the active render algorithm is could send a delegate color for each of its materials when queried via API for the rendered view.
(Just because I am not finding the right words to express to you that this is frustrating, it makes no sense trying to convince me that the user’s UI annoyances are imaginary)
@andy They do that already. The biggest plugins (Vray, Maxwell) have their own UIs just to isolate their own materials. It doesn’t make sense any other way. Who was complaining and how was that feature implemented ?
You didn’t hear from other users like me, because the Maxwell plugin UI completed shielded me from any of the Rhino stuff for years. Once a plugin starts using Rhino UI, isolation becomes an issue.
If I create a Bella material it’s for Bella, there is no reason for me to expect it for Cycles. Maybe there could an imaginary “Translate materials” command to bring-in large batches of materials from one engine to the Rhino algorithm/engine.
