I’ve been working on adding native GPU procedural texture support for Rhino. This means that Rhino’s procedural textures are evaluated on the GPU in real-time, which means they are always crisp, and updating the procedural parameters is much more responsive.
Previously Rhino needed to “bake” most procedurals into textures, which could often be slow and required large amounts of memory, especially if these procedurals were assigned to many individual objects. Baked textures could also sometimes look very pixellated, especially up-close. Native GPU procedural support aims to solve these problems.
Here’s a video showcasing the difference native procedural support can make:
In order to use the new native procedurals you don’t have to do anything differently - just create procedural textures like you’ve always done! Your old models will also automatically use the new procedurals.
In the currently available WIP, all procedural textures are evaluated on the GPU in Rendered mode, Raytraced mode and when doing production renders using Rhino Render, with the following exceptions:
On Windows, native procedural textures are currently only supported on NVIDIA GPUs. If you don’t have an NVIDIA GPU you can still enjoy native procedurals using CPU rendering with Raytraced and Rhino Render.
On Mac, certain older devices do not currently support native procedural textures.
When using Raytraced and Rhino Render, the following procedurals are currently not supported natively:
Gradient texture when using a custom gradient curve.
Check this link to see available procedural textures in Rhino.
Please test it out and let me know what you think!
Yes, it is pretty cool! You can use the procedural textures with a UVW planar map to create 3D procedurals (e.g. cutaway materials). The real advantage in v8 is that they show up crisp right away and there’s no waiting for them to bake in the viewport. This makes it a lot more fun to layer the possibilities.
it’s great to see some work is done in regards to procedurals finally. The crispness is useful for color textures but have you tried to use these procedurals for displacements ? To get usable results, each procedural would need some kind of blur. Would it be possible to add this parameter to each of the procedural textures to get what the Resample texture shader was capable of ?
Yes, that is something different. I don’t know what that would entail development wise to do in Rhino but it likely wouldn’t happen for 8. It looks like it uses an alpha image and then something else defining the mesh perpendicular to the visual holes. Maybe a separate post would be best so the idea doesn’t get lost within this thread. The closest approach possible now in Rhino would be by using PBR or object displacement but it would require a very dense render mesh.
Hi @BrianJ, yes the displacement modifier would benefit from it too. But i guess nobody is using this since it is somewhat slow even when you use the lowest setting and Refinement=0. It also does not weld properly…
The physical material’s normal displacement could benefit from a blur setting as well, but this is also unusable as it is impossible to control the displacement direction (it always displaces in both directions)…
Bottom line, we’re stuck with using images for displacement, blur them with photoshop and create the meshes ourself to displace them using custom code.
The color picker now has an Opacity value so you can make the white in say a dot texture completely transparent. That value will then not displace the objects render mesh.
I use object displacement myself but never set the refinement to 0, either the default on .5 or 1. You can alternately adjust it in other ways. I’d need to see the example showing the welding issues to help there.
Can you make a separate post for questions about displacement please? I may be able to help with some of the issues you mentioned but I don’t think they are connected to procedural textures not needing to get baked in v8.