Go to bottom

Raymarching Beginners' Thread

category: code [glöplog]
Tigrou, javascript!
added on the 2011-02-13 16:50:03 by msqrt msqrt
las: thanks, I'm trying to handle it entirely inside the shader though, feeding it camera position + direction. This way I can implement camera movement inside the shader later. Any suggestion?

Or does unc's scary cdak shader include this? I'll look at that a bit later.
added on the 2011-02-13 17:07:11 by psonice psonice
las: can you post the code that makes your noise cubes? i'd love to see how you did that.

oh, and btw what is the correct link to iq's 1k/4k packages? :]
added on the 2011-02-13 17:13:17 by vibrator vibrator
Pick one of the nice objects (See the toolbox thread)... take a noise and modify the size of your nice object with the noise, something like:

Code: ... d = min(d, toctahedral(p, 42.0, 2.0 + noise(p*13.37)*0.1)) ...
added on the 2011-02-13 17:30:55 by las las
BB Image

Getting there.. I now have camera rotation (found the rotation stuff in the toolbox thread :) except where it goes funky when looking up. Will fix later.

Also, easy animated objects:

Code:d = min(d, toctahedral(p, 42.0, 2.0 + sin(p + time)*0.1))

(probably looks like crap, but shows how to get it moving at least).
added on the 2011-02-13 17:54:11 by psonice psonice
Code: float f(vec3 p) { vec4 a = vec4(1., 0., -.577,.577); float d=0.,e=42.; p.y+=.5; vec3 q=p; rY(p, -t); rZ(p, -t); rX(p,p.x*sin(t)*0.3); d+=pow(abs(dot(p,a.xyy)),42.); d+=pow(abs(dot(p,a.yxy)),42.); d+=pow(abs(dot(p,a.yyx)),42.); d+=pow(abs(dot(p,a.www)),42.); d+=pow(abs(dot(p,a.zww)),42.); d+=pow(abs(dot(p,a.wzw)),42.); d+=pow(abs(dot(p,a.wwz)),42.); return min(q.y+2.0,pow(d,1./e)-1.0+sn(p*5.0+t)*0.05); }

This will give you a nice wobbling thing, sn is smoothnoise, t is time.
The working link to the isystem can be found here isystem (link found here)
added on the 2011-02-13 20:30:42 by las las
Oh god, awesome work.
added on the 2011-02-14 00:51:18 by msqrt msqrt
Thank you :)
added on the 2011-02-14 01:09:45 by las las
added on the 2011-02-14 01:10:04 by las las
That's so sexy... I want an intro!
added on the 2011-02-14 09:12:53 by xTr1m xTr1m
Cool stuff Las. :)
added on the 2011-02-14 10:17:09 by neptun neptun
las: nice one :)

Also, cleaned out my dropbox today, but I made sure to move the isystem to my ftp:

isystem link
added on the 2011-02-14 16:24:03 by ferris ferris
very nice, las.. almost looks like subsurface scattering..
Just attached some perlin noise to the extrusion fields position input... Whoa.
added on the 2011-02-15 06:01:10 by Mewler Mewler
Nice one mewler, I guess those lightrays are postprocessing? kkapture it :)
added on the 2011-02-15 10:49:46 by las las
Looks like an unfinished demo. Finish + release it, then kkapture it :) (And please do capture it, there's no way my machine will run raymarching at anywhere near that res :( )
added on the 2011-02-15 11:28:27 by psonice psonice
It guess this has been discussed something like 1000 times...
The correct "academic" name for the technique we all just call raymarching (in distance fields) is sphere tracing (zeno paper) - right?
added on the 2011-02-15 13:16:25 by las las
After much thinking and reworking, I now can a proper camera with full freedom of movement, zoom + perspective controls. \o/

But, lighting. I'm trying to add in some AO, and I've tried the various methods in the toolbox thread. They work, but they're far *too* ambient, to the extent that they look worse than SSAO. Best I've managed to achieve is extremely soft shadows (or extremely hard shadows with my own code, but lack of precision somewhere makes them hard and jagged - looks cool still with a point light in the centre of the scene :)).

So, question: what does the k factor actually do in the AO? And what might make shadows excessively soft? Oh, is it because I've not used an abs() on my function, so the first sample is too close/inside the object?
added on the 2011-02-15 14:30:30 by psonice psonice
No. abs() doesn't really play that major of a role, to be honest. The k factor scales the distance steps you're taking on the normal. So, a bigger k factor would mean you're taking bigger steps; hence getting farther away from the surface with each step. And since the distance is greater, and since you use the distance to the closest geometry to find an occlusion value it obviously has a major effect on the AO coefficient's intensity. Also, while taking bigger steps if you approach other geometry more it will also emphasise that geometry's effect.
added on the 2011-02-15 14:38:29 by decipher decipher
Ok, i see where i'm going wrong. I thought the steps were from the object to the light source, not along the normal. So in this case, static geometry + moving light + AO is going to give me static shadows and animated lighting. Which will look wrong.

So how about: Step along the light path from the light to the object. You can easily add light falloff with distance (I'm already doing this in the regular lighting) and add soft shadows based on the distance function. This should give a better look than AO, no?

I'll see if I can get it working later on.
added on the 2011-02-15 14:51:23 by psonice psonice
One should take the last version of the ao I posted - the abs thing will actually not compute "correct" ao... psonice: just play with the factor and the number of steps until you archive good results :)
For strange translucency and simple soft ao I use:
Code: a = ao(p,n, 0.5, 3.0); //ao s = ao(p,d, -0.3, 5.0); //sss // Magic combination of a and s... (maybe multiply them...)

But all those factors heavily depend on the scale of your scene and objects.

+ Maybe you want to share you camera control code via the toolbox thread? ;)
added on the 2011-02-15 14:56:41 by las las
psonice: If you step towards the light source you're already calculating the shadow factor. Just take slightly bigger steps. :) Stepping on the normal means you're calculating the ambient occlusion.
added on the 2011-02-15 15:06:59 by decipher decipher
las: yes, sphere tracing.
added on the 2011-02-15 15:10:24 by ferris ferris
Camera control is simply the code from the 'how to move the camera' link in the toolbox thread (is it from iq?), with trivial changes:
Code: uniform float perspective, zoom; varying vec3 v,EP; void main() { gl_Position = gl_Vertex; gl_Position.y = -gl_Position.y; v = vec3( gl_ModelViewMatrix*gl_Vertex) * zoom; EP= vec3( gl_ModelViewMatrix*vec4(0,0,-1,1) ) * perspective; }

I inverted y because it was inverted, and multiply the two terms. Using this in quartz composer, camera rotation is trivial (just put the shader inside a track ball, use mouse in viewer to rotate..) but there's no control over camera movement. It should be trivial to add in though. I'll fix that and add both versions to the toolbox thread.

AO: I did try your method too. Actually I think that's the only one that gave me shadows sufficiently tight that they looked like shadows, but that was after way too much playing with the factor + steps still. Possibly because I was stepping along the light path, not the normal.
added on the 2011-02-15 15:16:38 by psonice psonice


Go to top