let's bump it right

[Alessandro Padovani]

As reported in the uber documentation, and also noted by @engetudouiti in #425, the bump height in iray depends on the pixel density. Until now we used a fixed 0.2 mm height that fits the G8F face. This also works fine enough for all the 4K textures having a similar density, that happens to be a common case for daz figures. But the 0.2 mm height may not work for geografts, outfits and props that may have very different densities. This is why we often need to fix the bump height with the material editor.

http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/interface/panes/surfaces/shaders/iray_uber_shader/shader_general_concepts/start

That said we're not hopeless.

Some time ago we implemented a function to compute a material area, that was necessary to convert the iray emission. We can use this function to compute the pixel density. Below there's the equation that I extrapolated in my tests and seems to work fine enough. We first compute the material area, then the pixel density, then the bump height.

material area [mm2] = sum of the surfaces using the bump texture
pixel density [pix/mm2] = texture width * height * horizontal tiles * vertical tiles / material area [mm2]
bump height [mm] = 2 / sqrt(pixel density [pix/mm2])

Below there's the test scene bump.duf that I used to get the equation. It's a 1 meter plane where I used the same bump texture scaled at 512 1K 2K 4K size. I also scaled the plane and used different tiles for testing. So below an example. First iray, then the default 0.2 mm height, then the height by pixel density.

‌

‌

‌

[Alessandro Padovani]

Now let's check the G8F face so we can see if the equation gets about 0.2 mm as expected. To get the material area for testing I used the 3d print addon that also happens to give the area information.

‌

area = 72472 mm2
density = 4096*4096 / 72472 = 231.5 pixel/mm2
bump = 2 / sqrt(231.5) = 0.13 mm

Below the G8F face at the eyes that's a sensible area for bumps. First iray, then the default 0.2 mm height, then the height by pixel density. This seems good enough.

‌

‌

‌

[Alessandro Padovani]

Now we test the G8F torso, that gets a lower density since the 4K texture covers a larger area. So it is expected for the 0.2 mm height to don't work so fine, and for the height by density to work better.

‌

area = 719998 mm2
density = 4096*4096 / 719998 = 23.3 pixel/mm2
bump = 2 / sqrt(23.3) = 0.41 mm

Below the G8F torso at the neck that's a sensible area for bumps. First iray, then the default 0.2 mm height, then the height by pixel density. This also seems good enough and we can see that the height by density is noticeably better.

‌

‌

‌

[Alessandro Padovani]

A last test with something completely different, the G1F magus jacket. We convert it to uber before exporting. The iray test is also rendered with the uber version, though iray converts 3delight to uber anyway.

‌

area = 926952 mm2
density = 2500*2500 / 926952 = 6.74 pixel/mm2
bump = 2 / sqrt(6.74) = 0.77 mm

Below the magus jacket. First iray, then the default 0.2 mm height, then the height by pixel density.

‌

‌

‌

[Alessandro Padovani]

As a last note we see in the tests above that the equation is not perfect. It seems to work very well with the test plane, but it seems a little weak for real figures compared to iray. At this time I can’t understand why, nevertheless it works better than the fixed 0.2 mm height.

We may use a bump factor in the general options, perhaps defaulted to 1.5, to improve the bump by density.

[Thomas Larsson]

Implemented in last commit. I get the same distance = 1.35 mm for the G8F face, so the equations seem right.

As a last step I resized the textures once in Blender. That tool isn’t aware of the pixel density, but the renders look the same with 4K and 512 textures, so apparently the pixel density is not important in cycles.

[engetudouiti]

Thanks Alessandro and Thomas, Now I think bump conversion is correct and really reliable . (I actually do not have knowledge to manage pixel density things,, so it was simply annoying just thought conversion miss something about bump, when I import cloth etc)

[Thomas Larsson]

As for a bump factor, I would prefer if the default value is 1. One could change 2mm to 3mm in the equation instead.

[Alessandro Padovani]

Thomas, commit 5df4fc4 gets 1.35 mm for the G8F face instead of 0.135 mm. As for the bump factor it’s because I’m not sure yet and it would allow to test easier, but I can change the code instead. Overall 3 mm seems to work much better so yes we can use that instead for the time being.

Fixing the equation as below in cycles.py should work fine.

height = 0.03/(math.sqrt(density)*LS.scale)

‌

@engetudouiti You’re welcome I hope this works fine finally.

edit. As a side note may be “limit bump strength” in the global options could be removed now. Or replaced with the bump factor.

‌

[Thomas Larsson]

A number of related fixes:

1. The height formula does not depend on the scale explicitly, since density has dimension 1/(length)^2 and height has dimension length. The new formula gives a 0.2 mm distance independent of import scale for the G8F face.
2. I added a distance input to the top coat group too.
3. Limit bump strength is replaced by a bump factor.
4. The material editor does not work well anymore. It replaces all values but not textures in the selected materials, and this is not good since all materials end up with the same distance. This is ironic since the original purpose of the material editor was to edit the bump distance. One could add an extra multiply node which computes distance * factor and then let the material editor edit the factor.

‌

[Alessandro Padovani]

Commit d02a5f1 works fine for me.

As for the material editor I never used it before, from what I see it seems very powerful. The actual version seems to differ from what explained in the blog though. Specifically, the blog version seems to get a factor for each channel that would solve the issue with bumps. The actual version seems to have lost such flexibility and it’s more a copy and paste of values from what I understand.

May be we could bring back the blog version that seems more flexible. That is, personally as a general approach I’d not change the material nodes to favor the material editor, I’d rather change the material editor if needed.

http://diffeomorphic.blogspot.com/2019/10/mini-material-editor.html

https://diffeomorphic.blogspot.com/p/materials-section-version-15.html

‌

[Alessandro Padovani]

As a side note the bump by density seems to work fine for the pbrskin too that I didn’t test before. There are issues with the fresnel effect but I’d open another discussion for that. I plan to improve the pbrskin anyway.

[Alessandro Padovani]

marking as resolved, since improving the material editor is not strictly related, and may also deserve its own discussion