# RayCastMapper for SDF
**URL:** https://discourse.vtk.org/t/raycastmapper-for-sdf/16409
**Category:** Development
**Tags:** sdf, gpu, ray-tracing
**Created:** [May 5, 2026, 5:27pm UTC](https://discourse.vtk.org/t/raycastmapper-for-sdf/16409 "2026-05-05T17:27:40Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)
#### Post date: [May 5, 2026, 5:27pm UTC](https://discourse.vtk.org/t/raycastmapper-for-sdf/16409/1 "2026-05-05T17:27:40Z")
Hi Developers
We’ve prototyped a single-surface sphere-tracing mapper by forking
vtkOpenGLGPUVolumeRayCastMapper. The fork keeps all of the parent’s
pipeline plumbing — NDC→texture ray setup, depth-buffer composition,
clipping, picking, OpenGL state — and only diverges in the per-step
behaviour and the iso-hit write. The input is a vtkImageData whose
active point scalar is a signed distance field.
Three display modes are exposed on the mapper:
```auto
- Normals: the eye-space outward normal at the iso hit, encoded as
RGB. Useful as a quick correctness check.
- Color: per-voxel albedo from a sidecar 3-D texture, sampled
trilinearly at the hit. Multi-light Phong intentionally matches
vtkPolyDataMapper's output for the same scene lights, so the
volume render is interchangeable with a polydata reference.
- Flat: a constant colour read once per render from the volume
property's RGB transfer function.
```
The sphere trace handles truncated SDFs cleanly: voxels holding a
“no info” sentinel are skipped instead of being bracketed, so the
trace doesn’t fire on the spurious zero crossing at the truncation
boundary. The hit position is bisected to sub-voxel precision before
the gradient sample. Step fraction, bisection iterations, sentinel
threshold and eps tolerance are exposed as Set/Get knobs on the mapper.
We’ve validated visually side-by-side against vtkPolyDataMapper of the
same surface under both parallel and perspective projection, including
camera positions inside the model where the trace must hit a back-face
of the surface.
I made this for understanding the plumbing. Hopefully, I will soon move into the area of TSDF with fast updates. It is still in early development, currently adding C++ tests for validation agains rendering using vtkPolyDataMapper.
Would something along these lines be of interest as an option / display
mode on vtkOpenGLGPUVolumeRayCastMapper itself, or do you see iso
ray casting (sphere-traced, single-surface, opaque) as better kept in
a separate class? If a separate class, it could share the utilities using by the existing `vtkOpenGLGPUVolumeRayCastMapper`
Just a small example. Difficult to maintain sharp edges without increasing the resolution of the SDF, therefore the attempt for implementing a fast sparse TSDF.
---
### Author:  [@sankhesh](https://discourse.vtk.org/u/sankhesh)
#### Post date: [May 6, 2026, 3:31pm UTC](https://discourse.vtk.org/t/raycastmapper-for-sdf/16409/2 "2026-05-06T15:31:32Z")
Hi @Jens_Munk_Hansen, the volume mapper already supports an ISOSURFACE\_BLEND mode which, IMHO, can be extended to support SDFs (i.e. your changes). It could also be useful to compare this approach with other existing approaches like `vtkWindowedSincPolyDataFilter`.
---
### Author:  [@Jens\_Munk\_Hansen](https://discourse.vtk.org/u/Jens_Munk_Hansen)
#### Post date: [May 10, 2026, 8:15pm UTC](https://discourse.vtk.org/t/raycastmapper-for-sdf/16409/3 "2026-05-10T20:15:35Z")
I agree. It was quite an addition to support TSDF. Currently only support for dense TSDFs. I did a GPU euclidean signed distance field, where I followed an approach, where a new data type holding GPU data can flow in the pipeline. I have seen that in a development branch of VTK way back. The existing mapper hierarchy is quite polluted. Still working on getting things right before I figure out how easy it will be for extending the current mapper.