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'