Raymarching Tutorial
category: code [glöplog]
iq, have you ever posted source for that bridge? On your site, I believe you state it's you got bored with it (?), but WOW. A great image.
not for that one... i believe i have published Slisesix somewhere and perhaps Organix too (I might have to centralize this and put them all together next to the raymarching minitutorials at some point)
I made a simple distance field editor/modeller when I got bored of modelling in code. Can be found here. Improving this on a weekly basis. hf!
Quote:
I made a simple distance field editor/modeller when I got bored of modelling in code. Can be found here. Improving this on a weekly basis. hf!
Not bad!
I myself work in Rendermonkey for years by now...i have some test-values i can alter at runtime, generating objects made out of several basic objects is no problem this way also...but Rendermonkey is long deprecated, so no support for newer shader-generations! (ps3.0 is the best it covers!)
There are other programs one could use, like vvvv, but noone made a demoscener-tool yet! ;)
So keep on working on it, add obfuskation (see Shader Minifier and have a closer/deep look on this page by iq/rgba, maybe this inspires you to add more stuff! ;)
Thanks for the links! I was looking for similar tools but did not find one that is easy to use. I remember seeing a video or screenshot of a tiny-filesize demoscene tool that even allowed "modelling" by mouse (scale, translation, rotation) but I was unable to find it again! maybe someone here knows what it is called. could be that it was polygon based, not sure, I just remember that it used operations like union, difference and subtraction, exported models for 1 or 4k intros and had a tiny pixel font.
One of the next steps is to put all node definitions in an external xml file so that it is easily possible to change nodes and add custom nodes. minimizing and obfuscating is on my todo list too. also export packages for webgl (html, js) and whatever ideas we might come up with :)
@iq I also made a tool that loads all shaders from shadertoy for offline browsing/playback/screenshot/video capture (fixed fps, using ffmpeg) when I got tired of shader errors in my browser ... but i guess you would not be happy if I'd release this to the public, right?
One of the next steps is to put all node definitions in an external xml file so that it is easily possible to change nodes and add custom nodes. minimizing and obfuscating is on my todo list too. also export packages for webgl (html, js) and whatever ideas we might come up with :)
@iq I also made a tool that loads all shaders from shadertoy for offline browsing/playback/screenshot/video capture (fixed fps, using ffmpeg) when I got tired of shader errors in my browser ... but i guess you would not be happy if I'd release this to the public, right?
I dont understand what adok said about raycasting because when reading it, its more similar to raytracing. raycasting is much more simpler.
could someone please tell me if raymarching is closer to raycasting or raytracing? i hope to get an answer from someone who has done both raycasting and raytracing before. iirc raycasting came before raytracing in the demoscene, because raycasting didnt use as much processor and ram. well raytracing did more complex surface intersections than raycasting. but, raymarching also involves surface intersections but in another fashion or by some more clever technique, so is it possible to compare, and if so, how could one compare these two techniques against raymarching? and what elements are closer to either of the two? (i have never done raymarching before, just read a tiny bit about it)
could someone please tell me if raymarching is closer to raycasting or raytracing? i hope to get an answer from someone who has done both raycasting and raytracing before. iirc raycasting came before raytracing in the demoscene, because raycasting didnt use as much processor and ram. well raytracing did more complex surface intersections than raycasting. but, raymarching also involves surface intersections but in another fashion or by some more clever technique, so is it possible to compare, and if so, how could one compare these two techniques against raymarching? and what elements are closer to either of the two? (i have never done raymarching before, just read a tiny bit about it)
According to scientific literature, raycasting means to cast rays and trace them till they hit a surface for the first time only. Raytracing means to reflect the ray and continue tracing it more times.
But yeah, they are used in various interchangeable ways. We used to call 2d wolfenstein a raycaster, and more advanced and heavy ray through every pixel raytracing, even if you hadn't implement reflections yet.
About raymarching I don't know. It must be just a subset of raytracing or raycasting. Another way to do it, small increasing steps in rays instead of purely analytical.
But yeah, they are used in various interchangeable ways. We used to call 2d wolfenstein a raycaster, and more advanced and heavy ray through every pixel raytracing, even if you hadn't implement reflections yet.
About raymarching I don't know. It must be just a subset of raytracing or raycasting. Another way to do it, small increasing steps in rays instead of purely analytical.
raycasting steps alongside a ray with fixed length steps, while raymarching has step size that is the distance of the current ray position and closest surface. raytracing doesnt steps in a loop on the ray, it uses equations to find the intersection.
raymarching (ray goes left->right):
raymarching (ray goes left->right):
not just raytracing, also raymarching may reflect rays to create mirroring surfaces, or may to shoot back ray towards light source to find if its obstructed, then the found surface is in shadow. etc.
I generally agree with those definitions too. Yes, you can reflect with any of these methods.
Raycasting as making small same length steps makes sense sometimes, we use to hear voxel raycasting which is usually done this way, but the term raymarching for this makes more sense, marching means steady steps. What you call raymarching I would call distance tracing or sphere tracing.
But anyway, the thing is that the whole industry and science is mixing those terms in conflicting ways. For example, in some game engine like Unity you have a raycasting function. All it does is cast a ray and tell you if it hits and what distance, that's doing testing solving analytical intersection equation (aka what we call raytracing) with your polygon surfaces I think.
Raycasting as making small same length steps makes sense sometimes, we use to hear voxel raycasting which is usually done this way, but the term raymarching for this makes more sense, marching means steady steps. What you call raymarching I would call distance tracing or sphere tracing.
But anyway, the thing is that the whole industry and science is mixing those terms in conflicting ways. For example, in some game engine like Unity you have a raycasting function. All it does is cast a ray and tell you if it hits and what distance, that's doing testing solving analytical intersection equation (aka what we call raytracing) with your polygon surfaces I think.
afaik:
* raycasting simply means "finding an intersection".
* raytracing is a technique to render images by means of raycasting (casting rays into a scene, with or without secondary effects, monteralo or not)
* raymarching is "steping throuh space", in any form. usually raymarching is done with constant sized steps, as when you do somple volumetric visualization. steping trhough space is also a way to find intersections with solid objects when there's no an analytical ray-object intersection. often this is done in constant steps, or following some root finding algorithm such as newtown-raphson. if there exists some distance field or distance estimation to a primitive, then distance based raymarching can be used.
On the casting side of things (intersection finding), you an also cast other things besides rays, such as cones, boxes or spheres. Cones are casted sometimes to implement antialaising or soft shadows/reflections, although it's imho wrongly called "conetracing",it should be "conecasting". Boxes and spheres are also often casted in order to do collision detection of boxes/spheres with the world, in which case one should talk of you speak of "boxcasting" or "spherecasting".
"Sphere tracing" would mean one renders by using spherecasting, which would make sense for collision detection, sound propagation perhaps and orthographics cone tracing. But people use the term incorrectly to refer to distance based raymarching (the confusion seems to come from the fact you construct unbounding spheres at each step in the marching process).
So, basically, ramarching is one way to implement raycasting. Analytical intersections would also fall into raycasting. Raymarching is also a one way to render volumes. Raycasting is necessary to implement raytracing. Raytracing can be extended to do pathtracing.
* raycasting simply means "finding an intersection".
* raytracing is a technique to render images by means of raycasting (casting rays into a scene, with or without secondary effects, monteralo or not)
* raymarching is "steping throuh space", in any form. usually raymarching is done with constant sized steps, as when you do somple volumetric visualization. steping trhough space is also a way to find intersections with solid objects when there's no an analytical ray-object intersection. often this is done in constant steps, or following some root finding algorithm such as newtown-raphson. if there exists some distance field or distance estimation to a primitive, then distance based raymarching can be used.
On the casting side of things (intersection finding), you an also cast other things besides rays, such as cones, boxes or spheres. Cones are casted sometimes to implement antialaising or soft shadows/reflections, although it's imho wrongly called "conetracing",it should be "conecasting". Boxes and spheres are also often casted in order to do collision detection of boxes/spheres with the world, in which case one should talk of you speak of "boxcasting" or "spherecasting".
"Sphere tracing" would mean one renders by using spherecasting, which would make sense for collision detection, sound propagation perhaps and orthographics cone tracing. But people use the term incorrectly to refer to distance based raymarching (the confusion seems to come from the fact you construct unbounding spheres at each step in the marching process).
So, basically, ramarching is one way to implement raycasting. Analytical intersections would also fall into raycasting. Raymarching is also a one way to render volumes. Raycasting is necessary to implement raytracing. Raytracing can be extended to do pathtracing.
I thought that raycasting = sending rays for rendering a image, but only one ray per column, as it is done for games like wolf3d, doom or duke (for performance reasons).
Doom and Build (the rendering engine of Duke3D) use forward projection, they are not raycasters.
@iq: Great explanation. That makes it more clear for me for some terms I was misusing (like sphere tracing).
Both french and english wikipedia pages for raycasting cites theses games as example. I know wiki is not a reference but ...
In their implementations they do not cast rays from the camera into the scene to find intersections for rendering. They transform surfaces from the space they are defined in, onto the viewport and their areas in the viewport are filled via rasterisation. They both use a sorting structure (in Doom it's a BSP tree, in Build it's a more flexible cell-and-portal scheme) to perform hidden surface removal.
http://doom.wikia.com/wiki/Doom_rendering_engine
http://fabiensanglard.net/duke3d/build_engine_internals.php
http://doom.wikia.com/wiki/Doom_rendering_engine
http://fabiensanglard.net/duke3d/build_engine_internals.php
Disclaimer: I do not claim any correctness of the following (!) - it's somewhat derived from a day to day use of the terms and while still knowing what we talk about - we sometimes just use the wrong and incorrect words.
There is great potential for misinterpretation, since there are many different understandings and uses of these terms in the wild.
I tend to use/understand these terms as follows (it's pretty similar to IQ's use of the words, but differs in some nuances):
ray tracing: No concrete technique - more a large field of techniques/methods/approaches. Not necessarily image rendering related (e.g. sound propagation)!
ray casting: Just the act of casting rays. This is really often used as a finding the intersection of the primary camera rays with a scene (maybe it shouldn't).
ray marching: Class of algorithms that step along a certain ray (direction) through some kind of space to do something. This is often (ab)used on pouet in the meaning of the next item on the list.
sphere tracing: Here I seriously disagree with IQ.
What's incorrect here? It's the widely accepted academic term for what most people do here to distance functions to find intersections (albeit they call it "ray marching [distance functions]", but this is more or less demoscene only). The method is called sphere tracing since (most probably) John C. Hart decided to call it so in 1994.
cone tracing:
First - I never heard of cone casting in CG - even if that might be an appropriate term. Cone tracing is for me again a larger class of algorithms/methods. I think this is really a bad term which only works in a given context (Do they do intersection with the cone only? Multiply bounces? Integration along the cone while doing something?).
To conclude, the bad thing: Casting and tracing are often used somewhat arbitrarily, e.g. tracing is not necessarily meant to be tracing a path of a ray through the scene (multiple bounces) but can also refer to a single ray more in the sense of "marching" (simple example: sphere tracing).
Just from the words without context you most probably don't know what exactly is happening (e.g. are they tracing paths through the scene or just one bounce?!).
There is great potential for misinterpretation, since there are many different understandings and uses of these terms in the wild.
I tend to use/understand these terms as follows (it's pretty similar to IQ's use of the words, but differs in some nuances):
ray tracing: No concrete technique - more a large field of techniques/methods/approaches. Not necessarily image rendering related (e.g. sound propagation)!
ray casting: Just the act of casting rays. This is really often used as a finding the intersection of the primary camera rays with a scene (maybe it shouldn't).
ray marching: Class of algorithms that step along a certain ray (direction) through some kind of space to do something. This is often (ab)used on pouet in the meaning of the next item on the list.
sphere tracing: Here I seriously disagree with IQ.
Quote:
But people use the term incorrectly to refer to distance based raymarching (the confusion seems to come from the fact you construct unbounding spheres at each step in the marching process).
What's incorrect here? It's the widely accepted academic term for what most people do here to distance functions to find intersections (albeit they call it "ray marching [distance functions]", but this is more or less demoscene only). The method is called sphere tracing since (most probably) John C. Hart decided to call it so in 1994.
cone tracing:
First - I never heard of cone casting in CG - even if that might be an appropriate term. Cone tracing is for me again a larger class of algorithms/methods. I think this is really a bad term which only works in a given context (Do they do intersection with the cone only? Multiply bounces? Integration along the cone while doing something?).
To conclude, the bad thing: Casting and tracing are often used somewhat arbitrarily, e.g. tracing is not necessarily meant to be tracing a path of a ray through the scene (multiple bounces) but can also refer to a single ray more in the sense of "marching" (simple example: sphere tracing).
Just from the words without context you most probably don't know what exactly is happening (e.g. are they tracing paths through the scene or just one bounce?!).
I'll just call it "globe strolling" from now on. Or maybe "ball pounding".
How about projecting a SDF to the screen?
