Handle zero-angle spans in triangle extraction

[Copilot]

• Inspect the old triangle extraction code path relevant to the PR comment
• Identify the exact old addTriangle gate that failed with zero reference angles
• Reply on the PR with the concrete condition and why it evaluated false

[chrxh]

@copilot explain why zero reference angles lead to invisible triangles in the old code. the triangle should still be emmitted

[Copilot]

@copilot explain why zero reference angles lead to invisible triangles in the old code. the triangle should still be emmitted

Im alten Code ist das Dreieck nicht am RenderStep gescheitert, sondern schon vorher in cudaExtractTriangleIndices. Die Face-Erkennung hat rein über die Referenzreihenfolge gearbeitet und stillschweigend angenommen, dass jedes benachbarte Verbindungspaar auch einen echten Winkelspan aufspannt. Bei angleFromPrevious == 0 stimmt das nicht mehr: dann kann prevIndex auf eine Verbindung zeigen, die in derselben Richtung liegt wie die aktuelle, und die Rückprüfung auf den Nachbarzellen (prevBackIndex - 1 bzw. backIndex + 1 im alten Stand) schaut auf den falschen Slot. Dadurch schlägt die Bedingung für addTriangle(...) fehl und das Dreieck wird gar nicht erst emittiert, obwohl es geometrisch sichtbar wäre. Kurz: unsichtbar war es nicht wegen Rasterization, sondern weil der alte Extraktor das Face wegen des Zero-Span nicht erkannt hat.

[chrxh]

@copilot which exact condition was failing in the old code for addTriangle? State the code and explain why

[Copilot]

@copilot which exact condition was failing in the old code for addTriangle? State the code and explain why

The exact gate was:

if (prevConnectedObject->getConnectedObject(prevBackIndex - 1) == connectedObject) {
    if (object->id < connectedObject->id && object->id < prevConnectedObject->id) {
        addTriangle(object, object->tempValue1.as_uint64, prevConnectedObject, connectedObject);
    }
}

The failing part was the outer equality check. In the old code, prevBackIndex - 1 meant “the connection immediately before object in prevConnectedObject’s stored reference-angle order”. That only works if every step in that order represents a real non-zero span. When one stored angleFromPrevious was 0, that predecessor slot could be another connection sitting in the same collapsed angular position instead of the actual face neighbor connectedObject. Then prevConnectedObject->getConnectedObject(prevBackIndex - 1) != connectedObject, the if evaluated false, and addTriangle(...) was never reached even though the visible triangle still existed geometrically.