On 11/12/23 22:36, William F Pokorny wrote:
> I've already modified the yuqk aoi pattern to work with the full range
> -1 to +1 possible perturbed normals. I should try that now actually on
> the black ones... Ah, it didn't offer clue why things go black in the
> degenerate case - things are still black.
> I'll need to do some debugging I guess.
Alright. What is happening is the code marks degenerate triangles with
an internal flag setting that they are degenerate.
This flag setting gets tested during most operations including the
ray->triangle intersection code, where it immediately returns with no
intersections. (The bounding box intersections still happen, if those
are active with the active bounding)
Doing this where the specified normals are the only reason it is being
considered degenerate would be wrong for mesh inside testing - and I
think too conservative generally. Those mesh inside tests care not a
whit about normals, but dropping intersections will certainly create
The complication is the mesh / mesh2 parsing is different and I'm not
yet sure if things all work the same way there. I'll have to dig some more.
With respect to the smooth_triangle, what I've done in the yuqk fork is
modify the code so that, where the specified normals are the reason a
triangle is considered degenerate, we still get the warning messages
from the parser, but the triangle degenerate flag is no longer set.
Updated image of the new behavior is attached.
Post a reply to this message
Download 'tristory.png' (2 KB)
Preview of image 'tristory.png'