Raymarching Beginners' Thread
category: code [glöplog]
(looking good tho :)
las: nice, but not spiky enough ;)
nice flab
my latest bit of fiddling about: http://www.youtube.com/watch?v=3myYrQZ0yUY. Nothing too special, just trying to figure out colour (it's easy enough with some objects, not so straight cut when you go beyond the standard min/max).
What I'm figuring out now: what to do in the main shader, and what to do in post process. Ideally, I'd like to output normal, tex coords, material, and depth in the main shader, then texture + light it in the second. Then there's shadows, they have to be done in the main shader. But that's already 8 items to fit into 4 components.
So I reckon I have to do lighting at least in the main shader. And if I want bump mapping or anything like that, texture has to be done here too. Maybe output colour + depth is the best option :/
What I'm figuring out now: what to do in the main shader, and what to do in post process. Ideally, I'd like to output normal, tex coords, material, and depth in the main shader, then texture + light it in the second. Then there's shadows, they have to be done in the main shader. But that's already 8 items to fit into 4 components.
So I reckon I have to do lighting at least in the main shader. And if I want bump mapping or anything like that, texture has to be done here too. Maybe output colour + depth is the best option :/
why not everything in the main shader?
deferred lighting/texturing/shading is nice for raster engines, where the same pixel might be shaded several times due to depth complexity. in a raytracer/raymarcher, however, every pixel gets shaded once and only once anyway. so i don't see the advantage of doing it in postprocess...? it is gonna be slower and use more code, in fact. or are you trying ssao or something like that?
deferred lighting/texturing/shading is nice for raster engines, where the same pixel might be shaded several times due to depth complexity. in a raytracer/raymarcher, however, every pixel gets shaded once and only once anyway. so i don't see the advantage of doing it in postprocess...? it is gonna be slower and use more code, in fact. or are you trying ssao or something like that?
Ssao in a raymarcher? :O No, I was thinking more like DOF, edge detection/fake AA etc. They're hard in the main shader, and I'm not worrying about code size at this point.
256! :)
las: Nice!
Nice indeed, but I still want to know 256 what :)
post number 256 in this thread ;)
ah. It was appropriately cool :)
Fantastic shading. Makes me want to eat it!
yep. looks yummy. like jelly.
@las can you put a lil sugar on it?
@las can you put a lil sugar on it?
@yumeji: what kind of sugar? :)
+ I have to admit that I instantly wanted to eat that fruit like thing when I saw it first :)
+ I have to admit that I instantly wanted to eat that fruit like thing when I saw it first :)
Looks radioactive though. Eating it would probably leave you with superhuman coding abilities, but a slightly lame lime-green costume with lumps in all the wrong places.
Radiation is BLUE, damn it! :D Stop watching cartoons with yellow colored fat guys.
http://en.wikipedia.org/wiki/Cherenkov_radiation
http://en.wikipedia.org/wiki/Cherenkov_radiation
(hmm btw don't those pictures in the wikipedia article remind one of using the iteration step for glow... seems real-life does raymarching too!)
Cool, didn't know about that :) Nice glow fx in those reactors!
las: No, they don't. They look like the integral over the distance traveled before a surface was hit, i.e fog.
iteration glow is for lamaz who cant raytrace properly! =)
kusma: except that it's the distance travelled from the object, not the camera.. which is more like iteration glow than fog :)
psonice: how is that more similar? fog just "assumes" that the radiation is constant, whereas iteration glow "assumes" there's more radiation close to any surface. Which is a bullshit assumption. But raytracing distance fields can be used to calculate this quite closely, but iteration-glow is NOT the solution. And no, it doesn't look the same. At all.
neither are 'right', but i think iteration glow is closer because the glow is more intense closer to the reactor (which is generating it, and it's spreading out with inverse square..)
Anyway, why the fuck are we discussing glow around reactor cores? :D
Anyway, why the fuck are we discussing glow around reactor cores? :D
I guess it's my fault ;)
KEEP MARCHING.
KEEP MARCHING.
You can add a conditinal to the raymarching loop to bail out when the ray is really close to an object. In my case I get changing, but a tad better framerates...
Code:
for(i =0.; i<1. && l>.00001; i+=1.0/maxSteps){
l = field(p);
p += (l * d * .5);
}
