Raymarching Beginners' Thread
category: code [glöplog]
(or, more realistic, manual unrolling)
How don't whiles work? I've never encountered problems with them :o
Yeah, why wouldn't while work? It's getting around the 'gl_FragColor = ' that will be hard to not copy. And also, you're not allowed to use numbers we've used before.
mmmh actually figuring out how to raymarch a sphere is way easier than the same but for a cube...
yeah. A sphere is nice, you figure out how the raymarching itself works, and how to do normals etc., without worrying about the distance function of a cube. If you start with a complex object, you don't know if your distance function or the raymarching is the problem when it inevitably goes wrong :)
Yes, spheres are nice. After I spent a while reading stuff on iq's site and experimenting in visual studio I managed to write a raymarcher by myself and even got these spheres out of it. Oh well, more tweaking and maybe I can get a cube out of it too... :)
That's the one :) Now add a ground and AO, some more objects, and go wild with it :)
eimink: there's still something to do on these spheres, and you should do it now or everything you'll do will look weird : fix your image ratio ;) it's not very tricky, but higly necessary
Or you could go the easy way and use a squared viewport ;)
Flure: yeah, that viewport issue is one of the things that I have on my to-do list ;)
Ahh, that was quite a pause.
Image is clickable as last time:
Next time(soon hopefully) gonna try different lighting models. I wonder if anisotropic reflections will work. And I really have no excuse to procrastinate shadows any longer.
Image is clickable as last time:
Next time(soon hopefully) gonna try different lighting models. I wonder if anisotropic reflections will work. And I really have no excuse to procrastinate shadows any longer.
mobius :) Things like that are a good challenge I think, and the results can be surprising. That looks pretty good. Nice lighting too.
Nice but it looks a bit strange.
psonice: I'll give your acceleration approaches a try - the most expensive rays are currently hitting nothing, some precalc with some spheres and planes is a good idea - I want function pointers in HLSL/GLSL now.
psonice: I'll give your acceleration approaches a try - the most expensive rays are currently hitting nothing, some precalc with some spheres and planes is a good idea - I want function pointers in HLSL/GLSL now.
las: i thought of something before. Not sure how workable/useful it would be, but..
Imagine you're rendering to a grid instead of a quad, and you're drawing a scene that has no really small objects (i.e. every object will cover at least one square on the grid).
You could raymarch/trace in the vertex shader, and pass the distance as a varying. It'd get interpolated, giving the fragment shader an approximation of the distance field which you can use to accelerate you ray past a lot of the scene. It could be a pretty cheap way to do a 2-pass render, with a low-res first pass for speed and a high-res render pass for detail + lighting.
You'd have to step back slightly, and you'd still march the last inch which is the worst part, but there could be some major advantages to this:
- large parts of the screen might be unoccupied. You'd basically optimise these out, and just march maybe every 32nd pixel.
- you'd get much better accuracy where e.g. the ray passes through a hole.
Imagine you're rendering to a grid instead of a quad, and you're drawing a scene that has no really small objects (i.e. every object will cover at least one square on the grid).
You could raymarch/trace in the vertex shader, and pass the distance as a varying. It'd get interpolated, giving the fragment shader an approximation of the distance field which you can use to accelerate you ray past a lot of the scene. It could be a pretty cheap way to do a 2-pass render, with a low-res first pass for speed and a high-res render pass for detail + lighting.
You'd have to step back slightly, and you'd still march the last inch which is the worst part, but there could be some major advantages to this:
- large parts of the screen might be unoccupied. You'd basically optimise these out, and just march maybe every 32nd pixel.
- you'd get much better accuracy where e.g. the ray passes through a hole.
that's a sweet idea psonice.
we did that a couple of years back but using point sprites. the problem is that bit where you guarantee testing the low res and missing really means nothing in the tile. :)
Yeah, that's why I stressed the importance of having objects that cover at least one tile.
You could also increase the epsilon with distance, so the ray becomes a cone that covers the entire tile. That should guarantee the fish stay in the net :)
You could also increase the epsilon with distance, so the ray becomes a cone that covers the entire tile. That should guarantee the fish stay in the net :)
on ati to keep loop speed up I use something like this:
No variable dependent loops and no calculated whiles. Works very fast but on older cards (who multiplied stuff out) it had issues.
Code:
for (i=0; i<256; i++ ) {
// early temrination condition met...
i=256;
}
No variable dependent loops and no calculated whiles. Works very fast but on older cards (who multiplied stuff out) it had issues.
hard to guarantee with a moving perspective camera.
as you reduce the accuracy the quality and usefulness of the value drops.
anyway, go try it and get back to us. :)
as you reduce the accuracy the quality and usefulness of the value drops.
anyway, go try it and get back to us. :)
The sprites thing, didn't iq do something similar in that ambient occluded spheres 4kb a few years ago?
smash: if the angle between rays is constant, it's something you can calculate on the cpu side and pass in as a uniform, so not too bad. If you're doing funky stuff with the perspective varying across the screen all bets are off :)
I'll give this a go, but it'll be after i finish messing around with raytracers. The pure speed of raytracing has me hooked just now. And sheer volume of work is keeping me from working on the raytracer :/ (At least it's the kind of work that involves a shader editor and writing effects just now :)
I'll give this a go, but it'll be after i finish messing around with raytracers. The pure speed of raytracing has me hooked just now. And sheer volume of work is keeping me from working on the raytracer :/ (At least it's the kind of work that involves a shader editor and writing effects just now :)
psonice: You've reinvented the grid expander from 99% of mid to late 90s demos. Congratulations.
psonice: i've done that and used a similar technique since a year. it works perfectly, but if you don't get the subtle details of the algorithm, the rays can "go through". I've seen a lot of people getting in this pitfall.
I suggest looking back in the original paper, the zeno.pdf, well, you know :)
In the raymarching inner loop there's an epsilon. It's a subtle detail, which is more important than one thinks, because, it means that what we're raymarching is actually not a ray, but rather a cylinder of radius epsilon in the scene along a ray.
You can also raymarch a cone of a given angle since the eye: the distance to the neighbour pixel on the unit sphere gives a good measure of what type of epsilon you need. So it means your epsilon depends on t, it grows when you go forward in the 3d scene.
Then you can raymarch at a smaller resolution, with a larger epsilon (because the neighbour pixel on the unit sphere is a bit farther). Write the depth in a texture, and look it up when you wish to raymarch at "full resolution". It means you're actually marching a cone of larger radius first, and because it's a cone, you don't miss any "details". :)
It effictivelly skips most of the "empty spaces" at a small resolution, if you need to evaluate the signed distance function 60 times for a group of 16 pixels, it's like you've evaluated it 3,9 times for each pixel when looking up the result at "full resolution".
There you go :)
I suggest looking back in the original paper, the zeno.pdf, well, you know :)
In the raymarching inner loop there's an epsilon. It's a subtle detail, which is more important than one thinks, because, it means that what we're raymarching is actually not a ray, but rather a cylinder of radius epsilon in the scene along a ray.
You can also raymarch a cone of a given angle since the eye: the distance to the neighbour pixel on the unit sphere gives a good measure of what type of epsilon you need. So it means your epsilon depends on t, it grows when you go forward in the 3d scene.
Then you can raymarch at a smaller resolution, with a larger epsilon (because the neighbour pixel on the unit sphere is a bit farther). Write the depth in a texture, and look it up when you wish to raymarch at "full resolution". It means you're actually marching a cone of larger radius first, and because it's a cone, you don't miss any "details". :)
It effictivelly skips most of the "empty spaces" at a small resolution, if you need to evaluate the signed distance function 60 times for a group of 16 pixels, it's like you've evaluated it 3,9 times for each pixel when looking up the result at "full resolution".
There you go :)
and an important point is to use nearest filtering when looking up the depth from the previous pass. If you use d3d instead of opengl, you may additionally need to fiddle a bit with epsilons when you lookup because your texels are not "centered" somehow. maybe. i'm not sure there. :)
ksuma: i've never heard of grid expander, what is it? (And I know this is nothing 'new', it's just 'cone tracing' which is well known, and rendering a low-res image and filling in is well known since heaven7. I'm mainly suggesting that the combination of that and using a low res mesh + vertex shader to accelerate the rendering might help, I don't think it's been discussed *here* at least :)
nystep: that's *exactly* what I was suggesting :D (well, except using the vertex shader instead of rendering to texture - it cuts out a whole render pass, plus a texture sample).
Why do you need nearest filtering though? I would think linear would give better results as it's interpolated (this is why I thought the VS method might be good, you get this for free).
nystep: that's *exactly* what I was suggesting :D (well, except using the vertex shader instead of rendering to texture - it cuts out a whole render pass, plus a texture sample).
Why do you need nearest filtering though? I would think linear would give better results as it's interpolated (this is why I thought the VS method might be good, you get this for free).