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 
problems.

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.

Bill P.

Post a reply to this message

Attachments:
Download 'tristory.png' (2 KB)

Preview of image 'tristory.png'