We need a _MultiRenderEngineMaterial and/or multi-engine library support

Hi all,

We have all seen how poorly 3rd party rendering materials show in the Rhino viewport. And this problem seems to never go away, and we see very little (or none) interest by both McNeel and/or 3rd. party render engine developers to give this task full attention and priority. I expect this will never change. I also expect comments from developers contradicting me, but most likely, time will prove me right. Let’s not get into philosophical arguments, let’s build a beautiful solution without any compromises.

So I propose this solution: McNeel creates a MultiRenderEngineMaterial. It’s basically a material folder that looks like a material, but inside contains multiple shaders/materials for realtime viewport, and one/may different shader for your render engine/s of choice.

I think just in my little company alone, if we have that we could spend a couple of days creating a twin-library for shaders in Rhino using PBR materials + Octane materials + maybe even Vray materials. And then we combine them each into a MultiRenderEngineMaterial and we will have beautiful, successful and self-realized lives from that moment on, instead of living the agony that we have lived for now almost half of my life in my case.

Example: If I assign a red anodized aluminum (called alu_anodized_red) shader to an object, I can make sure that I have the right/optimized/gorgeous PBR shader for Rhino viewport + the perfect/gorgeous Octane shader for Octane renderings, so in reality I would be creating two ‘called alu_anodized_red’: one is a Rhino material, the other an octane material. Instead of the current situations: pick one place where your material will look great and where it will look awful, if recognizable at all.

Also we could do this as material library support. if you guys create a workflow where Rhino can look at a material library folder, and then have subfolders for each render engine/pipeline and Rhino will use whichever material from the subfolder matched to that render engine/pipeline. We would have to have instanced names so Rhino knows which one to swap to which.

We need to figure out a way to be able to worth both in realtime and with our render engine of choice and do so efficiently and with professional results. This so far has been impossible in Rhino. We either have great looking realtime screenshots or great renderings from 3rd. party plugins. Never both. It’s time this is fixed.

What do you all think?



1 Like

one more thing…

I think the real potential for McNeel here is to use this also to do visual management of geometry/production. The minute you create an ‘attributes structure’ to materials you can now have material/display modes or data structures to see all kinds of things. for example:

  • A real material shader structure: (shows all wooden parts in X color and all metal parts in Y color) or of course more complex version of this.

  • a job progress material mode: show me all parts that are going to be machined vs 3D printed vs cut from stock sheet.

  • A sizing analysys: show me all parts bigger than X volume in X color, and smaller that X volume in Y color.

I’m not saying you (McNeel) have to build all this, but just create a system so people can create their own material types and viemodes that support that material type.


Nice idea. I think you might be able to do that already essentially by creating a custom SetDisplayModeEx, and/or RenderWithEngine command (names placeholders).

Using these to set the display type of viewport, or start a render, you could go through all your materials and swap them out with those you need.

You can already create render content (i.e. RenderMaterial) for a specific RenderEngineId (in the form of a Guid) set (decorate your custom RenderMaterial implementation with the attribute CustomRenderContentAttribute). Granted I have not ever used this, but the existance if this leads me to believe it could very well be possible already.

Wrapping a bunch of materials for different engines into one, and swap out magically sounds like a nice thing to have.

I did not undersday a thing you tried to explain. Keep in mind I do not code and that I think the real opportunity marketwise is also for people who do not code. We the dumb ones outnumber the smart ones like you guys.

I did understand this part though:

I think you want to build a little tiny prototype of this, don’t you? I’m here to test it with you :slight_smile:

The only part you should’ve gleaned from the technical mumbo jumbo was “it might be possible!”

I want to do so many things! The big Cycles upgrade I’ve been battling with for a few months is now over - probably some fallout to deal with. But bandwidth is now available!

1 Like


Let me tell you why I’m so interested in this workflow now: your PBR materials.

We want to start designing with a full PBR twin library of our Octane library.

We have been exporting models to .USDZ and they look very good, but the current export approach does not carry PBRs yet, but we can imagine in the future Rhino will have a proper/native .USDZ exporter that can include all PRB materials with it.


I don’t know how you are currently exporting to USDZ, but if it is something of your own making you should be able to carry over the PBR materials in Rhino. Looking at the sample in UsdPreviewSurface Proposal — Universal Scene Description 23.11 documentation it shouldn’t be too hard to generate text that conforms to the spec. I haven’t much looked into USD, just now was my first time to find out what kind of shading is supported, how it looks like.

We are using https://www.simlab-soft.com/3d-plugins/USDZ_Exporter_For_Rhino-main.aspx

But it’s not very good, it only exports basic diffuse channel information. And it’s meant to export models to then further prep in SimLab Composer, which is not very good either IMO. And it’s an extra step we do not want to deal with.

We want to be able to export in 1-click what we see on our Rhino viewport and be ready for sharing and viewing in mobile and AR mode as .USDZ

I also noticed that .USDZ supports animation. Check out the little toy soldier here:

It would be great to be able to export animated Bongo 3 models to .USDZ

…just trying to help you guys sale more Bongo seats.

1 Like

The open source MaterialX project from Lucasfilm was designed to solve this problem:


“MaterialX addresses the need for a common, open standard to represent the data values and relationships required to transfer the complete look of a computer graphics model from one application or rendering platform to another, including shading networks, patterns and texturing, complex nested materials and geometric assignments.”

It was originally created for VFX but I don’t think there’s any limitation that would prevent it’s use in Rhino. I believe Autodesk and the Foundry are looking at supporting it in their products and Lucasfilm is working with Pixar to have it supported in USD:


Apart from longtime permanent solutions already discussed here, isn’t it possible to put materials in separate folders, and into the “main folder” for each material also folders for plugin-renders, and finally, add redirect links (“symlinks” *) from the plugin render to this centralized folder structure?

An awful lot of handcrafting to create such a folder structure, but if it would work, then you yourself could make it work in a day or two.

// Rolf

* HardLink ShellExtensions for Windows


Hi @nathanletwory, only 3 weeks later from our chat on .USDZ export, here we are needing to export an animated .USDZ from Rhino/Bongo, and we don’t seem to find a way to do it. The SimLabVRViewer plugin only exports static geometry.

Any chances you could explore exporting animation too? Thanks!


Hi @gustojunk - after the initial discussion on USD support I had a go at compiling the USD library and tools, but had to abort, because I failed to get it working (on the Mac). I may take it up on Windows in the near future.

For animation support I’ll have to ask @andy, @lars or @Joshua_Kennedy how animation info could be accessed from another plug-in.

We are seeing the need to export two formats of animated models for AR: .usdz for iOS devices; and .glb or .gltf for Android devices.

We have a workaround for .glb or .gltf by animating in Blender or Modo and exporting from there, but no solution for .usdz.

We’d love to be able to do all the exports from Rhino/Bongo so we don’t have to re-animate in Blender/Modo. This last re-work would also be solved by having an animation export as .FBX, but ultimately we want a Rhino/Bongo workflow. And I assume more of your users will be encountering this need in the near future too.



I keep reading this and agreeing with it but I always forget to say that I agree.

I definitely want to be able to assign materials on a per-renderer basis so I can switch renderers easily.

Use snapshots to switch between material sets.

Hi @andy,

This workaround you suggest might make sense if you have a ‘test.3dm’ with 4 objects. but it makes absolutely no sense for real production work. There are 3 reasons for this:

  1. Here’s what currently a file looks like in a real work environment, with JUST single rendering materials: Octane.

I don’t think how hard is to manage materials of a 3rd. party rendering taht doesn’t even have decent/accurate material previwes, when you have: “3 controls, 48 surfaces, 54 polysurfaces, 24 meshes” in a file. This is just a consumer product project. If this was an automotive project that number is about 10X.

I have no idea how I would take a fully set up scene and ‘use snapshots’ to change all the materials, assigned to all the objects, and even the materials not assigned that might need to be assigned later, to materials of a different render engine.

  1. Snapshops are not useable in Layout. And we use layout to plan all the views/assets we create for a client.

  2. Snapshops are a nightmare to use when you need to make a modeling change. Look at this thread for more context: SNAPSHOT in detail viewport layout? - #13 by gustojunk

Pascal might have given us a work-around scripted solution to update snapshots, but I wouodl not bank on it as a production-ready solution.

…So ‘Use snapshots’ is not a reliable, feasible, easy workaround to the already workaround that I’m asking your team to support because you cannot show/render materials adaptively to different render engines and display pipelines.

Please let me know if you have more questions or need more examples to see how painful this process is.


1 Like