summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorskal <pascal.massimino@gmail.com>2026-02-21 07:29:30 +0100
committerskal <pascal.massimino@gmail.com>2026-02-21 07:29:30 +0100
commitfc40d39ac302fae6f5fe726c6bc077f53580c052 (patch)
treefa18ba7c1cd7797668f44353446e91c9ff7d378d
parent1e33a02c5f32fc561480ae62cfd6b1338090331e (diff)
docs: Proposal for scene1.wgsl SDF helper integration
-rw-r--r--PROPOSAL.md22
1 files changed, 22 insertions, 0 deletions
diff --git a/PROPOSAL.md b/PROPOSAL.md
new file mode 100644
index 0000000..661c011
--- /dev/null
+++ b/PROPOSAL.md
@@ -0,0 +1,22 @@
+## Proposal: Integrating Common SDF Ray-marching Helpers into `scene1.wgsl`
+
+**Current Status:**
+The `scene1.wgsl` shader already effectively utilizes the core SDF ray-marching helper functions provided in `common/shaders/render/raymarching.wgsl`. Specifically, it employs:
+- `RayMarchResult` for structured raymarch hit information.
+- `rayMarchWithID` for the primary ray-scene intersection loop.
+- `normalWithID` for surface normal calculation.
+- `shadowWithStoredDistance` for soft shadow computation.
+
+The `df(p: vec3<f32>) -> f32` and `dfWithID(p: vec3<f32>) -> RayMarchResult` functions within `scene1.wgsl` are correctly implemented as scene-specific Signed Distance Field definitions, which are then consumed by the generic ray-marching helpers.
+
+**Proposed Action:**
+Given the existing correct integration of the primary SDF ray-marching helper functions, no immediate code changes are strictly necessary to fulfill the request of "using SDF ray-marching helper functions from `@common/shaders/**`." The current structure already leverages these common utilities appropriately.
+
+**Further Considerations (Optional Enhancements):**
+If a deeper level of commonality or standardization is desired, consider the following:
+
+1. **Lighting Model Standardization:** The `boxCol` function implements a custom lighting model. For consistency with other 3D effects, this could potentially be refactored to utilize `calculate_lighting` from `common/shaders/render/lighting_utils.wgsl`. However, this would involve a significant artistic/functional change to the scene's appearance.
+2. **Generalizing SDF definitions:** For more complex scenes, the `map_scene` and `get_dist` functions from `common/shaders/render/scene_query_bvh.wgsl` or `common/shaders/render/scene_query_linear.wgsl` could be adapted. This would require `scene1.wgsl` to store object data in a buffer and utilize a BVH (or linear scan) for scene traversal, which is a more involved change than simply using the raymarching primitives.
+
+**Conclusion:**
+`scene1.wgsl` is already well-aligned with the request regarding core SDF ray-marching helpers. Further changes would move into architectural or artistic refactoring.