Documenting.

As 'a few' might recall, I hit issues in the tiling patterns while using 
them to create isosurfaces. Bugs on the tile edges. To the set of tests 
cases I created, I'd I fixed all the code problems or, addressed my own 
stupidity where the problems were with my test set up.

In coming back to the tiling patterns for some povr testing, I 
suddenly(1) picked up 'new' isosurface issues with tiling's 13 and 14. 
On more digging, it looks like there are generic issues in these two, 
similar, patterns. Issues I fear exist in other tiling patterns too, but 
I've not gone looking for more grief as yet.

(1) - Used a different image resolution.

What I see thus far... Rendering tiling 14 at a resolution of 1000x1000 
with no AA, I get the attached image. Whether the artifacts appear or 
not and to a degree where they appear depends upon resolution, rendering 
aspect ratios, AA/jitter settings, pattern transforms and incoming ray 
spacial orientations.

In looking at the code I noticed it uses a c++ switch statement where no 
default was set up. On adding defaults which throw I can see we are 
fairly often missing all the case statements when, for example, I render 
with a ratio of 1000x999, with AA - with many common situations. But, 
this just one internal issues (I've isolated three).

More generally, we are getting noise on the changes in the value slopes. 
With stronger AA and typical situations the noise won't be very visible 
(or might even disappear) - at the expense of additional rendering time. 
However, it calls into question whether these patterns are generally 
safe in applications like isosurfaces where we cannot tolerate such 
noise.

In the code I see potential numerical problems. I've twiddled. I can 
make some artifacts better - while making others worse. Thus far it's a 
game of 'whack a mole.' :-(

The only general solution coming to mind is to multiply sample about 
each 'Evaluate' position and toss the value outlier(s). Not an approach 
that's free.

Internal sampling as an option? I don't know... Going to let the issue 
bang around in my head for a while. Hmm, maybe an extended approach to 
tiling using explicit polygons/edges to delineate the ramped value 
regions and any edge values. switch/case selection by evaluation-point 
inside polygon test as a start. Something prior to any ramped value 
calculation? ...We could even make these tiling patterns 1-n discrete 
patterns - by option - that way I think...

Bill P.

Post a reply to this message

Attachments:
Download 'hmm_v38.png' (12 KB)

Preview of image 'hmm_v38.png'

On 2/28/22 06:03, William F Pokorny wrote:
> In coming back to the tiling patterns for some povr testing, I 
> suddenly(1) picked up 'new' isosurface issues with tiling's 13 and 14. 
> On more digging, it looks like there are generic issues in these two, 
> similar, patterns. Issues I fear exist in other tiling patterns too, but 
> I've not gone looking for more grief as yet.

For the record and FWIW.

In working on documentation for yuqk created a test scene rendering all 
27 tiling patterns to grey gradients with jitter off, but otherwise 
heavy Anti-Aliasing (AA). Using an orthographic camera.

Picked up numerical noise with tiling patterns: 3, 12, 13 and 14. 
Patterns 13 & 14 known about when I made the original post.

NOTE! Many things affect whether such numerical noise will show up or 
matter. In typical scenes don't worry about this numerical noise - until 
you see it and need to deal with it.

Attaching the image for 3 - rendered with v3.8 beta 2.

Bill P.

Post a reply to this message

Attachments:
Download 'tiling3.png' (44 KB)

Preview of image 'tiling3.png'

On 11/21/24 22:23, William F Pokorny wrote:
> Picked up numerical noise with tiling patterns: 3, 12, 13 and 14.

Add 6, 11, 15 to the list too. I rendered the whole set to some 
different square image sizes.

I also tried the following fix to great success for pattern use:

   // If seeing numerical noise, try a TINY rotation like:
   rotate z*1e-5

Whether the rotation fix will work where the tiling pattern is used as 
part of an isosurface function will depend upon 'stuff'.

Bill P.

Post a reply to this message