Rhino needs faster large-texture handing, it is routine to use 2048’s and 4096’s and a lot of them. From the start that means that present method of caching material mappings disk must go.
I doubt Rhino is never created for that purpose. Rhino is a NURBS tool while many video game applications require the soft to handle a lot of meshes.
1 Like
AFAIK, Rhino3D was used in the newer Blade-Runner movie to create the city-scapes. So, I am talking about 2 expanding markets here.
GTK Radiant, the Id engine family game map editor, easily worked with NURBS, back even in the late 1990s.
I am looking at creating a RAM drive, but I am not sure if I can get the mapping to be on there. Perhaps if I make the user/temp folder there? The issue is that even a NVMe drive is hundreds of times slower than RAM. Yes, it does make a difference.
While some computer games do use a texture cache, it needlessly wears SSDs. Texture cache is off on both of my machines. I have 29TB of SSD writes this computer. Why add to it? Texture caching to disk is so 1990s. I am surprised that any software uses it.
So many laptops have “Retina” display resolution that the term isn’t even pushed anymore in advertising. Others have 4k screens. 4K is the new 1080. The issue is: even for repeating textures, we need larger textures in materials. Larger textures have other uses, such as the Picture command uses.
From this article:
In the following test, my Windows device C drive registered an overall score of 77.63 Mbps with average read and write speeds of 40.44 and 37.20 Mbps respectively.
…
In comparison, the values for ImDisk RAM drive were off the charts with an overall score of 29675.8 Mbps, along with average read and write scores of 21615 and 8080 Mbps respectively.
Ref: How to Set up and Use a RAM Drive in Windows - Make Tech Easier
[I still miss Radient’s texture handling features, which allow fast texturing and tiling. You could assign a texture to a surface, and tile n-copies across, and down, perfectly, with just a few clicks. That and I could use a no-draw texture.]
I used to install Windows 8.1 on a RAM disk. It was fast but I still think the bottleneck is how Rhino deals with textures (the approach of pushing them into OpenGL’s display pipeline).
I find it difficult to believe that writing anything to even a NVMe SSD wouldn’t slow the whole material/texture handling system down.
As a thought experiment, please create or load some geometry. Apply one 4096 to the floor/base, and apply a liberal dose of 2048s to various things. Please report back.