Blurry Decal Render In R7 vs. R6

Hi All,
Just noticed this tonight as I was trying out something else…I set up a simple subD shape on a ground plane with a decal on it. When I went to render the SubD rendered fine, but the decal was overly pixelated. So, I saved the file out as R6 and tried it there and it rendered fine. Strange. Anyway, the files (R7 and R6 ) are attached. Below are the images:

files:
The Blurry R7 render


The not Blurry R6 Render

My settings

Finally, a screenshot from R7 ( rendered setting on viewport) So, you can see that the viewport shows it right but it renders out wrong.

BlurRender-R7.3dm (1.4 MB) BlurRender-r6.3dm (1.4 MB)

Hi Again,
I forgot to say, that my renderer was the new Rhino Render Engine. When I did switch to the Legacy Rhino Render Engine, it rendered just fine as in R6, as I kind of expected it to do.
My hardware is: NVidia RTX Quadro 3000-Max Q
On a Win 10 system.
Cheers,

jeff

The new render engine is the same engine as what drives Raytraced. At the moment decals are being baked. With your object - an absolutely huge surface (v-ray infinite plane) - the tiny, tiny decal will end up as only a few pixels. This is because the texture is baked for the entire object. The decal is 22000mm² whereas the surface area is 100000000mm² that is 0.022% of the surface area. So the decal becomes just a few pixels in the resulting texture.

I am working on native decal support in the render engine (Cycles) where the decals will not be baked, but incorporated right into the shader for the object. But that will not be landing in Rhino WIP this month. Most likely end next month. The issue for this work that you can follow is RH-45742. The code work is in the native_decals branches of cycles, CCSycles and RhinoCycles.

Until then, if you need to do something like this I suggest you create an extra surface that is about the size of the decal you want in the place you need the decal to be, then offset ever so slightly (0.0001 or so). Add a custom material to the surface and set the decal texture to the color channel, don’t use decal for this.

Here a quick render at only 15 samples, leaving it for the 1500 samples for the final quality you set will give better results obviously. The render quality setting does not control the texture quality.

I am having the same issue (low resolution decals) in Rhino 7 Render in April, 2021. Has a fix been made or is one in the works?

If I use a smaller surface, then the decal renders at high resolution as you suggest. The issue is that I’m using a woven carbon fiber as the base material. Changing to a smaller surface also affects the weave size of my carbon material. So the new smaller surface needs to have a different scale to the carbon fiber material and it’s difficult to get the weaves to line up at the same size and position on the two surfaces.

Am I better off using the Legacy Render? Or I still have Flamingo nXt 5.5?

Thanks, Greg

Decals are now natively implemented in Rhino 7.5 for most cases. If you use unwrapping or custom object mapping then decals will still be baked - but any other case will work without having blurry textures.

The file BlurRender-R7.3dm (1.4 MB) from Blurry Decal Render In R7 vs. R6 - #2 by sculptn renders in Rhino 7.5 like this without any baking:

I’m using cylindrical mapping and the most recent full release which I think is Rhino 7.4.21078.

Will I have better luck using a newer WIP version? Or do I need to use planar mapping instead of cylindrical?

The next service release 7.5 is where the newly implemented decal support is. You can already use that by setting your update frequency to service release candidate through Help > Check for updates....

If all goes well it’ll be released next week Tuesday.

BTW - another solution in the short term is to change the “Texture Baking Quality” on the “Rhino Render Advanced Settings” (which is at the bottom of the rendering panel) to “Ultra”.

It will take a lot longer to start the rendering first time - but after that it will be virtually instant. And you will get a non-pixelated rendering.

Just out of interest, you should actually eventually get a non-pixelated rendering if you wait long enough…but in this case it does take quite a while.

1 Like

I updated to 7.5 and now the decals look great! Thanks for the quick response!

1 Like

I think the blurry decal issue may have come back with the 7.7 update.


The same decal was applied to both objects but it’s very blurry on the left one.
Decal_issue.3dm (8.0 MB)

@okeating you have a procedural texture in the roughness channel. That causes Raytraced to use the baked version instead of using high-quality decals. It is on my list to implement Rhino procedural textures natively in Cycles, but it will not happen soon. Best is to use an image texture for your roughness..

Never mind, I was looking at a different file and mixed up with this.

Instead in this case the problem is the use of custom object mapping. This type of UV mapping is not yet natively supported and causes Rhino Cycles to ask for the baked version. This means the less nice version of decals are used.

(This too is on my list to improve).

Hi @andy, and @nathanletwory,

i have a real problem with ATP under Rhino 6 and 7, but in the RenderedViewport using the Custom material (not Cycles Rendering). If i assign a texture to a polysurface, i first get the pixeled preview which, after some time sharpens and all is pretty. But if i assign the same Custom material to a mesh, the preview stays pixeled and never sharpens up.

Below is an example, it is a 4K map, left is a (very) high density mesh right is a polysurface. Both objects are using identical material and texture coordinates generated from the _Unwrap command:

To fix the pixelated appearance for the mesh, i always need to click on the button under the Mapping cathegory of the material “Display in Viewport”. Then it gets the preview right. But often this button is just grayed out, i don’t know why. Unfortunately, i have to click this button very often because as soon as i unselect the material in the materials tab, or switch to a different slot of the same or another material, the preview reverts back to the pixelated one for the mesh object. This makes working with multi layered textures really painful.

The above example is a material made from a blend texture slot, i use a black and white mask to multiply the actual texture with it. With the current implementation of the ATP in Rendered Viewport it is impossible to view the final outcome of the material for meshes (eg. a mask applied to texture).

I first thought this maybe a display or driver problem, but i can repeat this on 2 updated systems using Windows 10 and Rhino 6 and 7 (using a Quadro M2200 and a Quadro P5000). Is there anything you can do so the preview is not staying pixelated for meshes by default as it is for polysurface ?

Please let me know if you need an example file, i can send this via PM.

thank you,
clement

@clement, if this is with Raytraced/Rhino Render then two observations based on your description:

  1. uv unwrapping (and then fiddling around with the result) will cause Rhino to create a custom object mapping. This is currently not supported natively by Cycles and will ask for a bake texture
  2. using procedura textures (like blend) will cause Rhino Cycles to ask for baked textures, as Rhino procedurals haven’t been natively implemented yet - they are on the list to all get natively implemented, though.

If it is Rendered mode you’re looking for we’ll have to poke @Jussi_Aaltonen and @DavidEranen

Hi @clement

ATP doesn’t support mesh objects. This is known and discussed issue. The blurry image you see on the mesh object is a simulation of that procedural blend texture. Simulation is a fairly low resolution bitmap created by sampling the real texture. Simulation texture size can be modified from the Rhino Options - Advanced. But increasing it will affect the performance with more complicated models.

Hi @nathanletwory, thank you, there is (atm) no cycles involved. I hope i can just get the RenderedViewport right before i think about rendering.

_
c.

Hi @Jussi_Aaltonen,

that’s sad and very bad news imho. I’ve tried various things today and do not want to sound discouraged but the option to change the simulation texture size under Advanced Options is really a strong intrusion into a users system if it affects the overall performance (it does i can confirm, after some testing with small and large textures). I’ve tried these values:

Rhino.Options.Display.AdvancedTexturePreviewMaxResolution = 4096
Rhino.Options.Display.AdvancedTexturePreviewMinResolution = 4096

Only setting Max does not help. The result is that it shows a better preview after a long timeout, but still not comparable to the appearance if no Blend shader is used or if the same Blend shader and texture is used on a polysurface. Unfortunately i need to use Blend as it seems to be the only option to use a mask for a (displacement) texture (please correct me if i am wrong). I also need to use a custom mesh, using the polysurface’s render mesh causes gaps and irregular displacement.

Is there, or will there be a way in the near future to set above Advanced Option maybe per material instead of system wide ? Is there a way to change these values programmatically today (win and mac) ?

Apart from above problem with ATP and meshes, i found so many other hurdles today in Rhino 7, it gets frustrating.

_
c.

Changing those is a last resort and should only be done temporarily. And those settings have no effect on mesh objects, they affect the ATP resolution. If the issue is the blurry texture on the mesh then you can try setting
Renderer Development Kit.Settings.RendererSupport.SimulationTextureSize = 1024

Other option is to save the Blend texture as an image and then apply that image directly to the material.

Not possible at the moment but this has been discussed a couple of times.

@nathanletwory Do you know if there is a way to modify advanced settings from a plug-in or a script?

There are several old discussion that go into this, here is one post with code that works:

Hi @Jussi_Aaltonen, that is strange, i yesterday saw a difference when i changed the two but it was Rhino 7. I had not changed the Simulation texture size value, only the 2 values above. The funny thing is, it only shows it almost right after i reopen the file in Rhino 6. Once i make changes, eg. to the repeat values under mapping, it reverts to and stays pixelated for the mesh. The image is how it looks right after opening the file:

As soon as i make changes, mesh (left) stays pixelated, polysurface (right) becomes clean:

The video starts right after i cleared the cache to prevent it from using cached images. Is a restart required if the Simulation Texture size value is changed ?

_
c.