Prioritization of McNeel work to have a good rendering workflow in a team. Using material libraries of realtime PBR shaders + render-engine specific shaders

Fixing Viewport performance with large textures. Maybe there’s a texture quality setting, like render mesh setting so we can work in lower qualities and take high rez viewcaptures in higher quality? cc. @jeff

I have been testing with 8k textures all day, and the display performed fine. If you have a model that repeats the issue, please send it along.

#3 is now fixed in V7

I don’t want to interupt @gustojunk but i think the case of multi material is named wrong here. Though it actually could work to hold at once many engines materials… In my opinion the problem lays in material wrapper and no ecosystem around it. Thats why every engine has own UI on top of Rhino instead of being integrated like in 3ds max. Simple example of this is material breaked on Material and RenderMaterial where those two besides name have nothing in common while they should be based on the same abstract class which would wrap all possible materials and would be elastic to implement own slots for each engine but would handle the base properties for display purposes. If this sounds interesting let me know ill elaborate further.

1 Like

I really dont think so.

RenderMaterial is the material that we use that every engine could customize from. Material is the old-school 1982 OpenGL material spec that was in Rhino 1.0.

If you want to to do a renderer integration into Rhino and provide your own custom material types, you have everything you need to do so.

Hmm… That’s interesting didn’t know so shouldn’t be Material obsolete at least - besides it still takes significant role in IO part while RenderMaterials are not present. Bare in mind that I’m fluid only with RhCommon not with native side so i can be wrong.

Thats for sure and without doubt I just see inconsistency on the RhCommon side in the middle of Render and Document space.

If my suspicions isn’t right well there had to be a reason why engines never integrated to rhino like in case of max - certainly it could be caused of totally different reason.

The reasons for the two are historical and there’s really no need to dwell on it. I have wanted to get rid of the old stuff for years, but the change would be too much to bear for users of the SDK.

We basically use Material in the display, and RenderMaterial for full render engine implementations. As I said, there is plenty of scope for developers to write custom materials for their own engines.

Octane do this, for example.

1 Like

Different materials for the current renderer and the display would be hard because of a decision we made about 3rd party renderers.

If you have a custom material (and in Gustavo’s) case, I assume it is Octane, then Octane gets to decide what ends up on the display for that material. If they make a poor decision, there’s little we can do about that.

A post was split to a new topic: Material panel utilization

Hi @andy,

Thanks so much for jumping into this work. Today’s summary:

  1. fixed. thx!
  2. @IgorK will test later today or tomorrow and provide feedback. We also suspect that teh slow down could be a rhino-wide slowdown base on Material browser. But we’ll confirm.
  3. fixed. thx!
  4. @IgorK wil provide more feedback on this.
  5. This is a complex subject. I need to think more about how as a user/customer so we can reconcile your approach and vision with the realities of what 3rd party developers are doing and have expressed that they will not do. I’ll get back to you soon.

Best Regards,


Hey Gustavo, if I can jump in here on #5, it seems there are maybe two main objectives lumped together:

  1. allowing to have materials set up for multiple engines simultaneously, e.g. for every job you have some toon stuff you do with engine A and beauty stuff you do with engine B, and you’d like to be able to set up materials for both cases in one model (i.e. as opposed to saving out copies for each, or using version control, or somesuch).
  2. for whatever reason, you’d like to render with engine A, while having viewport (on a per-object basis), handled by engine B.

Am I reading you correctly? Just asking because the former seems more fundamentally important (and is a request I’ve heard quite a few times before, wrt a few different 3D platforms), and seems like something that could possibly be handled by a plugin (not one that currently exists, afaik). The latter seems more difficult.

hi @andy

regarding Viewport/ Material Editor performance:

1: Generally, performance in “Rendered” mode is OK, but start to degrade with more objects/materials. We tested with Rhino materials and then with PBR materials. PBR materials show some slower FPS in the Rendered viewport. To solve this issue we might need something like Draft/Quality mode, where we use Draft mode when modeling/editing models and then switch to Quality mode when we need to make screenshots/renders for a client. Or this could be automated feature when while we editing/interacting with viewport/model - its draft mode, but once we don’t interact with model/viewport - it shows Quality mode. Does this makes sense?
2. What’s bugging us more is performance when interacting with Material editor. Specifically, when loading/editing texture slots. For example, if we have a 4K/8K texture assigned in Color slot and we want to go back and change mapping scale - it could take a 2-15 seconds for it to open, then another 5-10 seconds to apply changes to mapping for example. We testing 4K/8K textures. More textures results in slower performance.

Video of testing Rhino materials:

Video of testing Rhino PBR materials:


Hi JD,

The original problem we are trying to solve:
Is a combination of both JD1 & JD2. (I’m calling thee JDX to differentiate form my original requests numbers).

JD1: Yes, we want this. We want to have a way to give each object a Rhino viewport material + an Octane material + maybe a Vray Material (less often these days) + maybe a Bella material?

The fundamental problem is that our preferred, easiest, fastest and most consistent (because we also use it in Modo) render engine is Octane. And we can’t even see the RGB value of our octane materials in the Rhino viewport. So we want to have also separate assignment for Rhino viewport.

JD2: At the same time that we are seeing something on a floating frame buffer in Octane with Octane materials we also want to see in in the Rhino Rendered Viewport with Rhino materials. Not ‘per object’ like you describe, but globally.

The new opportunity this presents:
If we have like a material table of some sort, we can assign different materials for different criteria, not just render engine of choice. Something like this:

For example we could use libraries for visual management of how are we building these models (we do a lot of prototyping): CNC? Formlabs? FDM? What material? in-house? Outsourced?

We could also have materials to show if a model has unwrapped meshes yet of not? Very important for our AR work.

I’m confused as to why JD1 and JD2 and very different? COuldn’t a render engine we just another viewmode? Just like Rantrace (Cycles) is doing, and if I recall correctly Maxwell had a version of this too, where you could set a viewport to show you Maxwell progressive rendering.


It certainly makes things easier that I misunderstood about per-object (I thought you meant you basically wanted SetObjectDisplayMode to work with 3rd-party renderers or something). However even just dealing with the viewport as a whole, I still see it as a separate question from the JD1 point.

The reason is that you have to make something that allows render engines to continue working without having to know about it, since when it comes time to render the model, each is only going to work if it finds its materials actually assigned to things. And once you do that (put engine X’s materials on the model), then raytraced/rendered/etc are going to see those materials, as well.

So it’s one thing to swap a set of materials onto the model (and a table like you show, and/or some other UI, could be used for this), and another to think if there’s also a way to give you a display mode that knows this is being done, and offers a way of drawing using a different material set. I’m knee-deep in exactly this area at the moment for bella, so let me think on it.


So what I’m seeing from your videos - and you’ll have to excuse me if I’ve missed something - is that you are having problems with loading and changing large textures in the Material Editor.

The PBR and Custom materials seem to respond in the viewport about the same - you’re consistantly getting 60fps no matter what you do.

Is that a correct assessment?

  • Andy


As I’ve said to you before, this is exactly what “Snapshots” is for.

Snapshots do not have to be a snapshot of the whole model - a snapshot can be just a replacement set of materials, or a replacement set of material assignments. I would suggest that you would use the former. Here’s how it would work.

Set up your model the way you like it for the display.
Save a Snapshot, checking only “Materials”. Call the snapshot “Display materials”.
Now change each material in the Material Editor to an Octane material, and set it up the way you want it for Octane.
Save a new Materials snapshot - call it “Octane materials”

Rinse and repeat for each renderer you want.

Now, with the Snapshot panel open, you can double click on the different materials snapshots to switch between renderers.

It’s pretty easy…

  • Andy
1 Like


I’ve just done for further testing with the WIP dujour build. Opening the UI for an 8k texture the first time takes about 3 seconds. After the first time it’s less than a second (this is because we have to load the file from the disk).

It’s still not ideal, and there is a bug logged to do this asynchronously. We will do that soon. But it’s quite a bit better than what you were experiencing before, I think.

4k textures are basically instant after the first time. First time load is about 1s per texture.

Changing the repeat values is pretty close to instant in both cases.

  • Andy


thats great to hear! Thank you , we will test the new build once it will be available.


Hi Andy,

Thanks for your feedback and ideas. We are exploring more the option of using Snapshots. We see a few bad shortcoming and we’ll document our findings later this week.



Great! Look forward to hearing what you have to say.

Hi Andy,

Here’s the first issues, workflow friction aside, that I’m seeing with snapshops to save materials per render engine:

  • snapshopts do not reload materials.
  • materials used in non-active snapshot are listed as unused (therefore purgeable) …probably these two issued are related?

material_snapshots_not_working_gf_200518.mp4.3dm (304.5 KB)


1 Like