WIP v7 uses PBR- do you use them? do you want them? Do you even know what they are?

One super powerful, but little known feature of v7 is the ability to use PBR (physically based rendering) materials. The most complete source for these materials is the Adobe Substance Suite. (alchemy, painter, designer, and source)

I’m mounting a campaign to have at least a basic PBR material library included in rhino when it v7 ships, but need to determine if this is a need for our user base at large, or if it’s already a need met by Substance and our current PBR importer.

Take a peek at what PBR gives you, and grab this 3DM file for testing purposes.

Try this:
unzip it to your desktop and then open it in v7. Import your model into this Rhino file and then drag the materials from the material tab onto your model. See how they react in both rendered mode and raytraced mode-

Understand that PBR materials are gorgeous, but their cost is slower (possibly significantly) render times, large (sometimes significantly) file sizes and hassle going to look for materials from an external source like freePBR.com or paying to use substance.

The other thing PBR gives you is physically based emitters that look amazing because they have accurate light falloffs. This in my mind makes cycles in v7 a pretty complete rendering package.


PBR_materials_tester.3dm.zip (6.5 MB)


PBR image based emitters are fun:


great topic @theoutside, I totally think Rhino should have a PBR material library, but it should be be of amazing quality, and one that works well (and optimized for) realtime open GL (rendered viewport). IMO the whole point of PBR is a realtime workflow, not something so slow as Cycles.

Also these materials assignments should NOT interfere with material assignments done for other render engines like Vray or Octane. This is why I mentioned @andy that we need a multi-material workflow. IMO It makes no sense to use PBR shaders in engines like Octane or Vray when you have a much more capable, faster and truly physically accurate render engine (as compared to a fakey-fakey ‘physically based’ hacks).

I also have a question about material quality and Rhino readiness for these. Let me elaborate…

I opened your file, and when I go to the wool ball I only get to see it in two very low quality modes in my rendered viewport:

Hiding/showing other objects I get the display quality to change. I can’t tell which one is the ‘intended one’ or ‘good one’ since both are so bad quality. I don’t know where you found these, but these are not the type of shaders that you bring home Kyle!

I think part of the problem must be that the are 1K maps maybe? FOr all our rendering work we are using 2K for any plastic noise, 4K textures for any metals and 8K textures for any fabrics. Sorry that’s the law: if you don’t like it, complain to the Rendering Council. Here’s the wet-dog wool at 1K:

Here’s a comparison using an 8K material from JRO tools Substance Masters Volume 1: (https://gumroad.com/l/OTAHK) with a couple of different mapping options:

BTW, I noticed that Rhino does not show well the quality of a material when you use UV unwrap:

Also Rhino does not like working with 8K textures at all. It’s slows down to molasses and it shows me this stuff , a lot:

also files will get very very very large, especially once you go with 16bit 8K textures to do pro-juicy work. So a library managment system needs to be in place, because this is nuts:

BTW, I think the metals looks kind of good, but like all things in the CG industry, everything looks like it’s been made by 12 yo boys for their Fallout 4 props/assets. You know, like this…

At least from my industry we need materials that look more like this:

No blood splashing, no scratches, no burned edges, no oxidation, no grimed corners, no finger prints. Just nice, blissful, clean, new, perfect materials.

Is that too much to ask? (…I’ll walk myself out)



Are those materials really impossible to find/customize among libraries of Substance, Quixel, etc.? Beauty of Substance sbs materials or even exported sbsar versions is that you can remove unwanted scratches and tweak material to your likings.
I learned that McNeel’s manpower is limited so sorry but I’m not enthusiastic about that. I would expect a different allocation of resources.

1 Like

You can import substance sbsar files directly.

where are you getting 8k images from? Alchemy top limit is 4k…

We do ‘home baking’ of all the channels in Modo when we need something with lots of detail, like weaves and/or stitches. And we do that using modeled tiles of geometry, not 2D scans. For most things 4K is great, even 2K will be fine for some plastic texture.

Also the challenge is how to you make a library with multiple levels of resolution, that can adapt to various hardware limitations of Rhino users. The Rhino viewport seems to be handling things nicely, but the material editor is melting away here sometimes. Very common to see all the material balls go complete blank. Will that be worse once you have high resolution textures?

here’s an example of what I mean by image-based vs. model-based:


and here’s how they compare in the RhIno Viewport. I’m not sure I’m using the right channel for the modeled one, it should look better. buy you get teh idea. Model based textured tend to be a lot cleaner and don’t have any captured lighting or waviness, that’s what makes things look videogamey and fake IMO. Especially once the material is applied to a proper model that has all the topology of form that in needs, instead of a plain sphere.

interesting… the test materials I posted were from substance at used 1k maps, I can post that wool one at 4k if you want to test it -

In your example the model based one is the worst looking one to my eye, so I’m clearly missing your point.

So here’s a question,

  • If we didn’t include any pbr materials, but included pbr support, and sbsar support so you could get anything you wanted in from substance, polligon, or any other pbr database, how does that feel?
1 Like

Yeah, that mode-based is not a good example, since denim has a lot of irregularity, it;s better suited for a carbon fiber, or a nylon weave. Yeah let’s see the wood in 4K. ANd also did you see my video? why does it look so bad, and in two modes? sometimes a bit blurry, sometimes with triangular ‘holes’ . Something is up with the display.

It would feel exactly like what Rhino has felt for the last 2 decades: you are not even trying when it comes to rendering and viz tools.

My point was not to shut you down Kyle, but to try to give a bit more focus feedback on the effort: making a material library that’s more useful for design/designers. Not for video games assets.

Our biggest workflow pain right now is that all things materials/material editors are very crappy in Rhino. Today my material editor started weirdly shaking all its fields and text, sometimes the material preview balls go blank, sometimes the editing part of a material editor window is empty When you clock on the pencil to edit it). And trying to load 4K/8K textures brings the system to its knees, temporary locking down Rhino. And I have a stupidly fast computer.

Also when we are using Octane we are flying blind because we cannot see even diffuse color of our rendering material in the viewport. This is why we are asking Andy to support multi-engine materials. I rather see all that fixed and ask my team to build our own PBR library, but I say this because I have the luxury to do that when I have a team of people. I have a feeling 99% of your users don’t have that luxury from a staffing and know-how points of view. You used Keyshot, because you didn’t have time not-to. You know how this works.




Import sbsar files into Rhino you mean? How?
By all means, such an option should be there (if it isn’t already)! If they would work with Enscape then, too, it would be stellar.

Regarding the overall UX with materials, I’m with Gustavo here. It’s clunky at best. The delays when popping up the material list are a problem.


SBSAR support is not in Rhino 7 yet, but it’s coming soon.


Thanks, this is great news!!

Hi @theoutside, @andy,

Besides all the issues mentioned above we also have a really bad limitation with Rhino material mapping. We really need to have per-material mapping to have consistency and accuracy of real world material looks. This is what we use in both Octane and Vray in Rhino and Modo.

Please take a look at this video from @IgorK explaining teh limitation we have in Rhino right now:

Do you have a workaround suggestion for this at the moment? And is this something you can address with new features for materials workflows?



Looks like Octane isn’t honouring the box mapping applied. It is true that the box mapping is transformed along with the object. If it is box mapping that stays the same always you should use WCS Box instead. Then you can control the texture mapping inside the material.

Apply an OCS mapping for orientation control per object, without further touching the material. That way the WCS (world coordinate system) feature (moving object has texture stay in world coordinate system - gives sliding effect) becomes an OCS (object coordinate system) feature. The texture size will stay the same for all objects it is applied to, but now you can also freely move around the object, transform it as you will without losing orientation to the object.

Here is a short clip

1 Like

I agree “game” materials are not sure useful for product design or aec- do you have a specific list of materials you’d like to see developed? I’d be happy to start trying to get that put in place.

Thank you for creating this thread @theoutside !

As you know, the materials should be what is applicable to your core markets - jewelers, architects, product designers. (and yeah, shoot-em-up video game designers are not in the core group AFAIK, so no Blade Runner apocalypse stuff needed, IMO)

For ID, it simply starts with the usual manufactured suspects:

plastics (textures)
metals and metal finishes
textiles and hides
woods (real looking finished wood that is, just wood)

I concur with mentioned opinions on the Rendered viewport in that: real-time, accurate representation as possible, is where the low hanging fruit lies, perhaps. Designers benefit from ‘seeing’ what they are working on in as accurate a representation as possible WITH FLUIDITY. Fluidity, fluidity, fluidity! Rendered viewport seems fluid enough at present. How accurate can Rendered become with PBR??? (Accurate defined as - photorealistic) Of course, well done materials are key here.

I use the ‘wrong’ hardware for present Rhino Raytraced CPU rendering. Fortuitously, for stubborn dumb arses like myself, Keyshot, properly configured and on ‘wrong’ CPU only hardware, will raytrace with photorealistic ‘fluidity’ in about 3-5 seconds what Rhino Raytraced CPU is still chugging along at after 30-60 seconds on wrong HW (where I bail). So those efforts still happen in KS over here. But I am encouraged by progress and find myself exploring Raytraced when I want to have a ‘stretch’ and am too lazy to go over to KS. But, I think I see what you mean about SLOOOW PBR and Raytraced on your PBR_materials_tester.3dm file, hence perhaps MORE import supporting the Rendered viewport PBR idea?

Keep in mind the distinction between product designers and those creating assets for the product launch - the catalog/marketing campaign. The latter needs to be ‘perfect’ and those assets will be created by specialists with the best tools available for the job. Designers, on the other hand, don’t want to (can’t) invest too much time into materials for our WIP stuff. We need a library that works, that we can tweak. We’ll create the material if need be, and of course we crave (need) the ability to present our WIP in the best light. (pun intended)

Speaking for myself, I’d be happy with a Rhino library that simply approximates common plastic textures. (so I don’t have to figure out how build MT-11060 in Rhino!) Just grab a Standex Mold-Tech book and reverse engineer some approximations - bet you can do better than KS. Happy camper!


mold tech textures would be great! as would pms colors IMO-

Yes, absolutely. They come at a steep licensing cost I heard. I wonder if that’s the reason why Keyshot does not include them in their install, but they rather asks you to download them from Keyshot Cloud:

BTW, here’s what in that Moldtech library, you can zoom in and look at the detail

Also, like most large companies, they license their stuff to fancy customers, while they do their own work in Rhino:

source: https://www.mold-tech.com/architexture/