When x,y or z nears 0.0, the scalar value wrinkles pattern works less 
well (shows artefacts). The effect differs somewhat between the three 
noise generators

To better make the issue visible I made two renders where I compiled in 
a slightly different internal lambda factor. Such a change should result 
in evenly distributed differences in a rendered wrinkles result.

All renders shown using the default noise generator (2).

The upper row of the attached image shows the issue. Near the origin 
there is little to no effective change in coordinate values and so 
little or no change in the result from Noise() as we walk through the 
(1/f) steps.

In the middle row I simply add 'translate +2222' to get the internal 
coordinate away from small x,y or z values - and all good.

In the bottom row is the change made in yuqk. A constant asymmetric 
translate is done internally to the three different values with a 
magnitude of 1e7 (this the +- numerical magnitude limit for POV-Ray). 
Yes, with the right, counter, spatial transforms a user could bring the 
'shifted origin' back into play, but it is very unlikely to happen in 
practice.

Bill P.

Aside: The normal{} block's wrinkle perturbation is still disabled in 
yuqk. The long standing perturbation moves relative to any surface on 
changes to the bump_size. In trying for alternatives, I've come up with 
other perturbations like 'concrete', but nothing acceptably wrinkles 
like. Using the value pattern above is still the best replacement.

Post a reply to this message

Attachments:
Download 'wrinklessmallvalbias.jpg' (202 KB)

Preview of image 'wrinklessmallvalbias.jpg'