How do we 'march' rays without missing geometry? With the aid of signed distance functions, geometric equations which take an arbitrary point in 3space and evaluate to 0 if that point is on the 'shell' of the geometry. For example, the signed distance function for a sphere:
float sdfSphere(vec3 p, float r)
return length(p) - r;
Approachable overview of raymarching & SDFs: [https://jamie-wong.com/2016/07/15/ray-marching-signed-distan...]
Learn more: [https://iquilezles.org/www/articles/raymarchingdf/raymarchin...]
I dunno if that’s how it’s done now, but the old CG end-of-semester assignment was a constructive solid geometry ray-tracer to render not-LEGO bricks. It was simple ray-intersection against simple geometry unioned/diffed together, and didn’t use any stepping along rays.
Classic raytracers never march or step: the ‘downfall’ is that the need to test every object in the scene for intersection, and the objects need to be easy to test for ray intersection.
This lets you avoid testing most objects for intersections but adds book keeping overhead so it only works really well for specific kinds of scenes. Aka not the classic single ball and a few walls.
Their are also multiple ways to handle chunks. For a space RTS game you might box up all the ships in a squad and first test the box around the squad before testing each ship. For Minecraft you can just split the world into arbitrary boxes that don’t change frequently.
Raymarching enables rendering objects/scenes raytracing can't readily handle (like procedurally generated fractals), and tends to be costly because of how the ray must be "marched" towards the surfaces rather than directly computing intersections.
The only form of raytracing I'm familiar with that employs anything resembling raymarching is the classical 80s-era KD-tree acceleration structure paper which stepped the ray at hyperplane boundaries, to confine the costly ray->object interesection tests to objects in the intersected axis-aligned bounding boxes.
- ray tracing refers to the general problem of finding an intersection between a ray and the closest scene surfacing. It is most commonly asociated with techniques that intersect discrete primitives like triangles and usually employ acceleration structures like bounding volume hierarchies or kd-trees to make that fast.
- ray marching is a related, but actually separate technique where the algorithm steps along the ray in discrete steps. It can accumulate values along the way, if needed. This is used e.g. for volume visualizations (e.g. 3D CT scan visualization or clouds in movies). You can also use that concept to find intersections with surfaces that do nit have/require closed form solutions for ray intersections. This is how you eventually arive at sphere tracing for signed distance fields and the stunning image by iq et al. that are created entirely from math expressions for the surfaces.
That’s the very first line of the source page. So why do you say it uses raymarching? Are these terms used interchangeably as in marching is a method to do tracing?
If anyone wants to see the SDF/rendering bits, it's all in this file: https://github.com/westoncb/under-game/blob/master/js/gameFr...
Looking forward to playing this a lot. I particuarly like the clever use of fractal mathematics to make accurate collision detection physics. Though it helps that he's using a sphere as the user-controlled object.
I spent many a weekend rendering hundreds of .tga files and throwing them into .flc files since that was the only way I knew how to make "videos". I mostly did renderings of planets turning with texture maps, trying to get something similar to what I saw in Star Control 2, and I told myself I was making them for my own video game, but I never got past fiddling around with povray. Anyway it looks like polyray has a lot of the same facilities. I wonder how I was unaware of it for the couple years I played with povray?
EDIT: bigger issue is probably that SFML apparently doesn't support wasm: https://github.com/SFML/SFML/issues/1494