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
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
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
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...
Post a reply to this message
Download 'hmm_v38.png' (12 KB)
Preview of image 'hmm_v38.png'