pouët.net

Go to bottom

Raymarching Tutorial

category: code [glöplog]
my very own attempt at a beginner's tutorial:
try to implement a basic ray marcher showing a simple unit sphere/cube while reading the Raymarching Beginner's Thread from the start. somewhere along pages 5 or 6 you should have everything you need to understand the basic principle and some more advanced ideas.

there you have your beginner's tutorial nobody seemed to care about (except everybody did, as it gets quite obvious from reading the actual content of that thread alone). also, that is how i learned it during half of a lazy afternoon, with no previous knowledge - even didn't know shit about raytracing before.
added on the 2011-06-29 17:54:17 by hcdlt hcdlt
but you are obviously not an "average" person!
added on the 2011-06-29 18:17:06 by quisten quisten
What is confusing me is the babble about computing the distance to the object, not the distance to the intersection point of ray and object.

I have understood that, as Doom says, it suffices in distance-aided ray marching to compute the distance to the object at each step in order to determine how far you can walk on the ray. But this does not change the fact that ray casting is all about computing the distance to the intersection point:

BB Image

If you take the middle ray in this image, you will see that it does not hit the sphere at the location that is closest to the point on the screen, but somewhere else; so the distance to this intersection point is larger than the distance to the object. In my understanding of ray casting it is this larger distance that determines the colour of the pixel. So you cannot simply compute |pixel-center| - radius, as kb_ says, but have to compute |pixel-intersection|.

I can imagine you could alternatively take each pixel on the screen and obtain its colour by computing the distance to the nearest object (with a sphere: |pixel-center| - radius). That would be an alternative way of rendering objects, but it would not be ray casting since the ray would, most of the time, not go through the camera.
added on the 2011-06-29 20:08:53 by Adok Adok
you are so not getting it :)
added on the 2011-06-29 20:21:18 by quisten quisten
so now you're admitting to both a) writing a "tutorial" and b) not understanding the algorithm? (hint: stop fumbling on about formal intersection points, that's what we somewhat want to avoid here)
added on the 2011-06-29 20:29:23 by superplek superplek
you should know where the object lies in world-space (or whatever space you're in when you're raymarchin).
added on the 2011-06-29 20:52:34 by rudi rudi
He has long admitted it, he just sucks at admitting that he admitted something.

But hey, let's solve that with math (note: vectors are capitalized, scalars are not):

let
Camera be the position of the camera, and
Pixel the position of the pixel of the virtual screen we hold in front of the camera.

The normalized direction of the ray is thus:
Direction := (Pixel-Camera) / |(Pixel-Camera)|

Now let's define a simple example distance function

F(Pos) := |(Pos-Center)| - radius ,

Center and radius being the center and radius of the sphere we want to hit with the ray. Note that this is an example, F(Pos) can get as complex as you want.

The whole point of sphere tracing aka distance field based raymarching is this:

We define a sequence vP[k] with the following properties:
vP[0] = vScreen
vP[k] = vP[k-1]+vDirection*F(vP[k-1])

You will find that this sequence follows the ray and will either converge at the exact intersection point of the ray and the sphere, or will shoot off into infinity when there's no intersection. Just test for F(vP[k])<epsilon for convergence, and use a maximum k or some outer bounding box for the divergence test.

That's all.

added on the 2011-06-29 21:03:23 by kb_ kb_
(ignore the lowercase vs and vScreen of course means Pixel. I really should proofread when there's no compiler around, sorry.)
added on the 2011-06-29 21:05:52 by kb_ kb_
BB Image
This is how it basically works.
added on the 2011-06-29 21:26:31 by las las
Quote:
So you cannot simply compute |pixel-center| - radius, as kb_ says, but have to compute |pixel-intersection|.


If you had to compute dist(pixel, intersection) then sphere tracing would be redundant.

Anyway, say you're at location P and you evaluate d = distance_function(P). Then you know that the minimum distance between all objects in the scene and your point P is d, or in other words, you can move P in any direction by a length of d without intersecting anything. The direction of the ray is a valid direction, so d is also a safe distance to march along the ray. Then you keep doing that until your distance is close enough to zero, or until it appears to diverge.

The point is that it's a simpler algorithm than solving the ray-primitive intersection for a bunch of different primitives. That means it's great for 4ks, and for pixel shaders. Also, you can render some funky implicit surfaces.
added on the 2011-06-29 21:29:52 by doomdoom doomdoom
Please stop explaining it further to Adok.
We have good resources here already - If he doesn't get it from the "raymarchers for complete ID-10-Ts guide" here - he just doesn't get it - maybe he's just too much below the average.

@Adok: stop asking, start reading and implementing - then come back. Now stfu.
added on the 2011-06-29 21:38:20 by las las
las, nice diagram
las, but what if Faker lies to Widdy all the time?
added on the 2011-06-29 21:51:51 by kb_ kb_
Then Widdy shouldn't listen to Faker and replace him with somebody more honest ;)
added on the 2011-06-29 21:54:35 by las las
oh, sphere-tracing, never seen that. is each sphere's center at the intersection of the previous sphere etc? is it a faster way to find the bounding volume of the object or...
added on the 2011-06-29 21:57:48 by rudi rudi
intersection = surface-circumference-intersection-point even
added on the 2011-06-29 21:58:54 by rudi rudi
las - was your presentation recorded?
added on the 2011-06-29 21:59:14 by shuffle2 shuffle2
Yes - but I held it in german language.
added on the 2011-06-29 22:02:00 by las las
http://hakim.se/experiments/html5/sketch/#33142cbf
I need a better drawing device than a mouse....
added on the 2011-06-29 22:19:20 by las las
las, your picture is the best tutorial ever.

If Adok understands that the distance function represents the whole scene and that it always returns the distance to the closest object, wether or not it's on the ray's path, then he should get it right ?

or not ;)
added on the 2011-06-30 07:35:07 by flure flure
so, what you guys are telling me is: if i want to learn how to do <insert technique> i should start by writing a tutorial on <insert technique> and post it to pouet and observe the comments? :)
Don't even think about it. Closed thread is closed.
added on the 2011-06-30 08:13:35 by las las
It's really perfectly explained in iq's slide show, page 23-29. Which is the second of his related links.
added on the 2011-06-30 08:20:11 by doomdoom doomdoom
CLOSED.
added on the 2011-06-30 08:22:26 by las las

login

Go to top