| … | … | @@ -45,14 +45,15 @@ is that the attribute holds the coefficient rather than the colour. |
| 45 | 45 | Two of our three attributes were already correct by luck: `scale` is written |
| 46 | 46 | unlogged (activated) and `rotation` is w-first identity. The mismatch is opacity. |
| 47 | 47 | |
| 48 | | **Why `to_pointcloud` still does not write `color` by default.** That name is the |
| 49 | | one this project has already been burned by — as a POINT attribute it renders |
| 50 | | BLACK, which is why colour lives in `ifs_color` and why a test forbids the name. |
| 51 | | Blender's splat path requires exactly that name, so the two contracts collide. |
| 52 | | Nothing that ships reads the splat one (it is 5.3-alpha, on a branch, no |
| 53 | | milestone, no buildbot builds), so it is available as |
| 54 | | `to_pointcloud(..., splat_contract=True)` rather than imposed on the rendering |
| 55 | | that works today. |
| 48 | **`to_pointcloud` writes `color` by default** (`splat_contract=True`). It was |
| 49 | briefly opt-in, on the grounds that `color` is "poisoned for points — renders |
| 50 | black". That warning came from the volume work and had never been measured in |
| 51 | this context. It is wrong as applied: an A/B on a cloud that renders, same |
| 52 | material reading `ifs_color`, is byte-identical with and without the attribute |
| 53 | (lit=69, max=0.8157, mean=0.00103 both ways). `color` renders black when a |
| 54 | MATERIAL READS it — a different claim, which the codebase had collapsed into the |
| 55 | first. The invariant that matters is that our material reads `ifs_color`, and |
| 56 | test_points_operator pins it. |
| 56 | 57 | |
| 57 | 58 | **Other corrections from the same audit:** |
| 58 | 59 | |