clarify comments and todos

src/main/java/me/jellysquid/mods/sodium/client/render/chunk/translucent_sorting/TranslucentGeometryCollector.java

@@ -413,7 +413,6 @@ private TranslucentData makeNewTranslucentData(BuiltSectionMeshParts translucent
 
         // from this point on we know the estimated sort type requires direction mixing
         // (no backface culling) and all vertices are in the UNASSIGNED direction.
-        // TODO: don't attempt static topo sorting if BSP sorting works well.
         NativeBuffer buffer = PresentTranslucentData.nativeBufferForQuads(this.quads);
         if (this.sortType == SortType.STATIC_TOPO_ACYCLIC) {
             var result = StaticTopoAcyclicData.fromMesh(translucentMesh, this.quads, sectionPos, buffer);
@@ -434,6 +433,7 @@ private TranslucentData makeNewTranslucentData(BuiltSectionMeshParts translucent
             try {
                 return BSPDynamicData.fromMesh(translucentMesh, cameraPos, quads, sectionPos, buffer, oldData);
             } catch (BSPBuildFailureException e) {
+                // TODO: investigate existing BSP build failures, then remove this logging
                 System.out.println("BSP build failure: " + sectionPos);
                 return TopoSortDynamicData.fromMesh(translucentMesh, cameraPos, quads, sectionPos, this, buffer);
             }

src/main/java/me/jellysquid/mods/sodium/client/render/chunk/translucent_sorting/TranslucentSorting.java

@@ -17,28 +17,11 @@
  * sections for dynamic sorting to the trigger components.
  * 
  * TODO:
- * - many sections can be marked as needing an update but they are only actually
- * scheduled for sorting when the RenderSectionManager makes them visible. This
- * may result in many sections suddenly needing sorting when the camera moves.
- * Maybe it's better to schedule them to be sorted gradually even if not
- * visible, if there are idle threads.
- * - Movement prediction and preemptive task scheduling to avoid needing to
- * perform blocking sorts of close sections. Maybe not an issue? Might reduce
- * stutter in high fps situations. However, high complexity with regards to
- * processing the results of preemptive sorts.
- * - determine the right distance for angle/distance triggering. It seems just
- * the diagonal of a section is too small, angle triggering is broken at close
- * distances.
- * - Bug: adding a slime block onto one of the corners of the monster cube makes
- * it invisible. Is this because there's nothing else in this section than just
- * that one block? Might have something to do with NONE mode behaving weirdly in
- * that situation. Possibly related to index buffer reuse, since it only happens
- * after the block has been replaced at least once.
  * - Incompatible with rendering anything through Indium because it doesn't run
  * the translucent geometry collector properly. It doesn't run Sodium's
  * BlockRenderer which is required for lines 166-167 of BlockRenderer to work.
  * 
- * @author douira
+ * @author douira (the translucent_sorting package)
  */
 public class TranslucentSorting {
     /**

src/main/java/me/jellysquid/mods/sodium/client/render/chunk/translucent_sorting/bsp_tree/BSPSortState.java

@@ -73,7 +73,8 @@ void writeIndex(int index) {
     private static final int CONSTANT_DELTA_WIDTH_INDEX = 15;
 
     /**
-     * ceilDiv was introduced to the JDK in Java 18 but is not available in Java 17.
+     * ceilDiv was introduced to the JDK in Java 18 but is not available in the here
+     * used Java 17.
      */
     private static int ceilDiv(int x, int y) {
         return -Math.floorDiv(-x, y);