pouët.net

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.

but you are obviously not an "average" person!

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:



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.

you are so not getting it :)

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)

you should know where the object lies in world-space (or whatever space you're in when you're raymarchin).

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.

(ignore the lowercase vs and vScreen of course means Pixel. I really should proofread when there's no compiler around, sorry.)

This is how it basically works.

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.

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.

las, nice diagram

las, but what if Faker lies to Widdy all the time?

Then Widdy shouldn't listen to Faker and replace him with somebody more honest ;)

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...

intersection = surface-circumference-intersection-point even

las - was your presentation recorded?

Yes - but I held it in german language.

http://hakim.se/experiments/html5/sketch/#33142cbf
I need a better drawing device than a mouse....

Don't miss lecture II & III:
http://hakim.se/experiments/html5/sketch/#331467b9
http://hakim.se/experiments/html5/sketch/#331484da

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 ;)

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.

It's really perfectly explained in iq's slide show, page 23-29. Which is the second of his related links.

CLOSED.