Please Fix the Texture System : (

Rendering
1

I love Rhino, but I am still not happy with the material application and mapping system.

1.) It’s too slow for large materials, going north of 1024px? Good luck.

2.) Frequently, Rhino duplicates materials, needlessly. I can delete extra materials, save the file, load the file, and they are back. This has been an ongoing problem. There might have been a regression?

3.) There is now a new texture scaling bug, even with Rhino’s own small materials. Set it to 200 box map. Save the file. Load the file–and the material application looks blank, but really the scale is set around 200000.

Oddly, the Decal system works pretty good. Kudos.

I wish that materials worked as well as Rhino’s modeling, and I wish it didn’t take me as long to apply materials than to model something.

3 Likes
2

WIP? latest V7? Both? More?

5

Hi @Brenda ,

  1. Can you provide a sample model and indicate what version of Rhino you’re on? Also, are you using the Rhino Renderer or a plugin? Screenshots are helpful in addition to a sample 3dm file. The UV mapping, object location, display mode settings and texture itself could be part of the issue you’re seeing.

  2. I believe some related issues have been fixed recently but again a sample 3dm file and series of steps would be needed to file another bug. In a quick test I haven’t been able to reproduce this here in an internal build of Rhino 7.25. My guess is it is related to imported geometry maybe?

  3. I haven’t been able to reproduce this one either. Do you have a sample file? When you say 200 box map, do you mean WCS box mapping for the texture in the material set to a unit of 200x200 size or do you mean the texture is set to mapping channel 1 with a repeat of 200x200 and the object has a mapping method of box? A sample file would be good here too.

You can email tech@mcneel.com or use Rhino - Upload to Support to send anything confidential or too large to email. Thanks.

6

Hi,
I’m sorry, but I was really upset by it yesterday.

For good performance, the texture disk cache has to go. I don’t mind adding more memory, Nand SSD writes will never be as fast as DDR dynamic memory.

At the time, I had reasonable to small sized materials in play, Rhino’s own birch wood. The mappings became corrupt, reading as over 20000 units. Yes, they should have been something like 200mm.

For the last year or so, my final renders have been 3840x2160. Humans are adapt to picking out repeats in seamless textures. Most 3D games now use over 1024s. For a presentation render, one that I won’t have to re-render, I often have an assortment of sizes ranging from 128s to 4096. Yes, I have tried to avoid the 4096’s. I try to keep the largest 2048s or smaller. Still, things get slow pretty fast. Once more, my request for a no-draw shader was met with heavy resistance here on the forum.

Rhino is a great modeler, the best I have ever used. It has been been the one program that has made me feel better after GTKRadiant, but except for the unwrap, Radiant still out-textures Rhino–which wouldn’t be an issue, but Radiant is over 20 years old. I am used to making applying 1000 materials to objects a month as well as making them be something, and I am slow compared to Camrom who worked on Alice (old game).

So, what does it matter? Well, it makes it worse because Rhino is excellent in so many ways, so it’s the dark cloud in front of the sunny day.

As for the file, I will have to find the corrupt one tomorrow, but if you care make some things and try putting medium and large sized materials on them. I’ve seen this kind of: cannot keep up, so must corrupt bug before.

The version is: Version 7 SR23 (7.23.22282.13001, 2022-10-09)
The renderer was cycles.
System information follows. Looking at the Aniosotropic filtering is getting shut off, and the AA is going to get lowered on this new install, but all of that is nothing compared to the disk cache.

Rhino 7 SR23 2022-10-9 (Rhino 7, 7.23.22282.13001, Git hash:master @ a931168ca9426920ae6aa97218710b662f17fc39)
License type: Commercial, build 2022-10-09
License details: Cloud Zoo

Windows 11 (10.0.22621 SR0.0) or greater (Physical RAM: 32Gb)

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce GTX 1080 (NVidia) Memory: 8GB, Driver date: 9-21-2022 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 517.48
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port #0

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 9-21-2022
Driver Version: 31.0.15.1748
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8 GB

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.23.22282.13001
C:\Program Files\Rhino 7\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 7\Plug-ins\IdleProcessor.rhp “IdleProcessor”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.23.22282.13001
C:\Program Files\Rhino 7\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.23.22282.13001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\Alerter.rhp “Alerter”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.23.22282.13001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.23.22282.13001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

7

i agree, on a complex file that is really messing up the overview and not only does it duplicate instances, but it also keeps losing them regularly.

:smile: indded…

9

Brenda

There was a limitation in V7 and previous versions of Rhino that meant that we couldn’t partial load textures. Now that users are using textures in excess of 4k on a regular basis, this is starting to be a problem, so I have added some tech in V8 that will allow us to do this.

It’s not actually working yet - so don’t get too excited.

Anyway - it is always very useful to get real world models so we can see what the real bottlenecks are. If we are just guessing (the disk cache, for example, has nothing to do with it, I’m sure about that) we will get it wrong 99% of the time.

So if you can send me a model personally to andy@mcneel.com I will look into it for you and we will see what we can do.

BTW - we have just added some massive improvements to V7 to deal with situations when there are thousands of textures / objects / materials.

  • Andy
10

I sent one of the bad files. There might have been another one or two before I figured out why the material had no detail: it was way too big.

The materials also multiplied like rabbits crowded in a dark elevator, on a Friday night.

I am sorry, but I just got going on this project. Once I discovered what had happened, I copied everything to a new Rhino file. At least I didn’t lose geometry.

The material in question was one of Rhino’s slightly modified. There were also 1 drawing that created about 1024px material, and one decal, about the same size.

The disk caching has to go, please!

Rhino or any program will always have speed and reliability problems if it’s using a form of memory that 1000 times slower than RAM.

Perhaps adding to the slowness is that the NVMe drive is caching shaders/materials/textures: at the same time the bus is also loading the textures into the card AND loading them onto/off the drive.

(Yes, of course I have it shut off for games, too. And why wear the SSD? I have over 30TB writes on a drive that was used less than my old laptop drive was.)

11

Brenda

The disk caching isn’t for what you think it’s for. Stuff on the disk is there for when we generate a bitmap on the fly (for example, if it’s color adjusted or baked). Then - next time we run Rhino, we can load the ready image instead of the original.

We do not use the disk cache to store stuff during runtime - we always use either main or GPU memory.

  • Andy
12

I am pretty sure I saw Rhino make disc writes, while I was using it. I am sure that it’s not virtual memory, because it’s off on both of my machines.

As a user, I don’t want any disk caching of textures/materials.

A no-draw material would increase rendering performance, as well as preventing Z-fighting for thin or co-planar materials/surfaces. Because Rhino can texture (but not map) per surface, the application would quick, with no changes to the UI, unless you wanted a user-toggle, per Display Mode, but in Cycles, it would speed previews and rendering.

It would also save on performance because a surface with a no-draw material needs no mapping coordinates. I should think that when rendering path hits it, it would extinguish that path at that point.

Ultimately, I want texture application to be as quick and painless as Rhino’s geometry creation.

I still owe you a video showing, quick per-surface texture mapping. Sorry, but my health hasn’t been too good.

1 Like
13

Those are likely the baking results if you use any procedural textures, or of you are using custom mapping objects. Work is done in Rhino 8ä(mostly by @DavidEranen ) to no longer use baked procedurals, but have actual Cycles implementations of all Rhino procedurals.

Some texture mapping approaches also need baking, but some of work by @Jussi_Aaltonen may make it unnecessary to bake all cases.

Those are the cases where (baked) textures are written to disk for Rhino Render and Raytraced.

Note that baked textures can be written for many objects if you use a material with a procedural on many objects.

14

@nathanletwory @Brenda We don’t use the disk cache for display baking anymore - just raytraced and production renders.

15

Aye, I’m naturally talking about Raytraced / Rhino Render here.

16

From the getgo, why use the SSD, when it’s so much slower than RAM?

As someone does 4K renders, maybe I’m the only person that when I launch a render, I don’t dare touch my machine until it actually starts rendering. Once it starts, the renders usually go pretty well–even if you antagonize the machine. Though, that baking to disk, yes, it’s noticeable. Why not try pestering your machine when you launch a 4k render. Click on the screen : )

I’ve seen memory usage climb at the start of renders, which is expected, par for the course. There’s nothing wrong with that. Though, on many people’s machines, Windows may also be indiscriminately pushing stuff to VM at the very moment you start a render. (I have VM off, have for years because once you run out of physical RAM, it’s all over anyway. LOL!)

17

There’s also a repeatable bug in:
Version 7 SR25 (7.25.22301.23001, 2022-10-28)

Where as if you create a duplicate material, alter it, and rename it, and try to apply it to various faces, Rhino cannot tell them apart, and seems to apply the same material.