Fix zero-angle connection insertion

[Copilot]

Zero-angle connections created during branch construction were inserted at the wrong connection index, leaving topology ordered unfavorably and causing triangle rendering artifacts. The fix moves the handling from rendering extraction back to connection insertion.

• Connection insertion

  • Treat absolute 0° as the end of the reference-angle loop (360°) when inserting by absolute angle.
  • Prefer the preceding span on exact angular boundaries so the zero-width span stays on the existing reference connection instead of the newly inserted connection.

• Rendering rollback

  • Removed the previous GeometryKernels workaround that skipped zero-angle spans during triangle/quad extraction.
  • Restored rendering to consume the stored connection order directly.

• Regression coverage

  • Added a test-only absolute-angle connection path.
  • Added coverage for inserting a 0° absolute-angle connection before the reference connection.

desiredAbsAngle = Math::getNormalizedAngle(desiredAbsAngle, 0.0f);
if (desiredAbsAngle < NEAR_ZERO) {
    desiredAbsAngle = 360.0f;
}

if (desiredAbsAngle > summedAngle + NEAR_ZERO && desiredAbsAngle <= nextSummedAngle + NEAR_ZERO) {
    insertIndex = i;
    desiredAbsAngle = min(desiredAbsAngle, nextSummedAngle);
    break;
}

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