the latter being the most interesting to get started as it’s part\u00a0of the\u00a0stackgl<\/a>\u00a0project and has support for\u00a0glslify<\/a>\u00a0(a modular set of shader\u00a0utilities), this is what I used to understand better how things work.<\/p>\n this being said, I thought I’d\u00a0use THREE.js<\/a> rather than the above\u00a0WebGL boilerplates because it\u00a0allows users to easily add\u00a0uniforms\u00a0and post process passes. it is on\u00a0a github repo<\/a><\/p>\n Ray Tracing (or rather Ray Casting<\/em>) is a technique used to render high quality 3D images. a\u00a0blunt\u00a0description goes like:<\/p>\n for each “pixel” of the screen, a “ray” is sent from the camera through the 3d scene and returns the color for that pixel.<\/p><\/blockquote>\n the oldest ray tracing\u00a0engine I know of is POV-Ray<\/a>\u00a0which allows this\u00a0type of\u00a0glorious render:<\/p>\n so\u00a0simple as it seems,\u00a0it displays some already complex behaviours such as shadow casting, reflections,\u00a0light bouncing and not fog<\/a>\u00a0but rather the Fresnel effect of the reflections.<\/p>\n ray tracing is\u00a0a well known and well documented technique.\u00a0it’s also computationally expensive, suited for pre-rendered images rather than real-time rendering\u00a0(even\u00a0though more\u00a0and more attempts are made to go towards real-time in games and architecture visualization).<\/p>\n Ray Marching is a variation of the ray tracing\u00a0; instead of evaluating if\u00a0a “ray” hits the\u00a0surface of a “model” of the “scene” in the direction of the ray and at a linear step size<\/em>, the “scene” will return the shortest distance<\/em> to the “model” in any direction and use this distance as\u00a0the “step size” along the “ray”.<\/p>\n a visual\u00a0explanation\u00a0may be better:<\/p>\n <\/p>\n the\u00a0“airquotes” around scene\u00a0<\/em>and\u00a0model<\/em>, are there to emphasize the fact that there is no geometry<\/em> involved but rather a mathematical description<\/em> of the geometry.<\/p>\n indeed, as the only goal of\u00a0the signed\u00a0distance function<\/em>\u00a0(or SDF<\/em> the function that tells us if and at which distance the ray has reached the surface of something in the scene) is to return the shortest distance to the\u00a0model<\/em> being computed, the only information we need is therefore a distance ; a float. as we only need a distance,\u00a0using a mathematical description of our scene is the way to go.<\/p>\n for instance, a sphere centered at (0,0,0) is described as:<\/p>\n where pos<\/em> is the position along the ray & radius<\/em> the radius of the sphere.<\/p>\n update:\u00a0<\/strong>after a spontaneous and much appreciated proofread by Hector Arellano<\/a><\/strong><\/p>\n the main difference between ray casting and ray marching, is the\u00a0fact that ray casting uses explicit\u00a0equations while ray marching uses implicit equations to\u00a0render the scene.<\/p>\n in other words, when rendering a scene, a ray caster will find the exact intersection point between the ray being casted and the explicit equation of the geometry while![\"povray\"](\"http:\/\/barradeau.com\/blog\/wp-content\/uploads\/2015\/12\/povray.png\")
<\/p>\n![\"difference\"](\"http:\/\/barradeau.com\/blog\/wp-content\/uploads\/2015\/12\/difference.png\")
<\/p>\nfloat sphere( vec3 pos, float radius )\r\n{\r\n return length( pos ) - radius;\r\n}<\/pre>\n