Raymarching Beginners' Thread

category: code [glöplog]
A bit of a noob question, but any idea how to get a letterboxed 2.55:1 ratio fullscreen render in OpenGL? Everything I've tried has had some problems with it. I can get it to work for the raymarching buffer, but not for the postproccessing as well.
added on the 2011-03-11 04:52:58 by Mewler Mewler
Mewler: verbose please.
added on the 2011-03-11 10:30:42 by las las
msqrt: Do you multisample there?

The borders of these 'planets' look a bit weird
added on the 2011-03-11 10:37:56 by joooo joooo
msqrt: While people talk planets, am I the only one thinking that you've created the perfect setup for a huge snowball-fight? ;-) Looks really great
added on the 2011-03-11 11:15:00 by Punqtured Punqtured
msqrt: good start, now try to generate some more complicated geometry and materials!
added on the 2011-03-11 11:29:49 by las las
A bit of a noob question, but any idea how to get a letterboxed 2.55:1 ratio fullscreen render in OpenGL? Everything I've tried has had some problems with it. I can get it to work for the raymarching buffer, but not for the postproccessing as well.

Not sure hat you mean, but it might help to divide the height of the quad you render by 2.55. Then you also need to fix your aspect in the shaders.
added on the 2011-03-11 11:45:52 by raer raer
No multisampling there, if I wouldn't do so many small octaves of the noise it'd smoother :)

But yeah, more complicated materials would be good. Let's see if I can get something interesting out of this..
added on the 2011-03-11 16:07:28 by msqrt msqrt
glViewport(0, (height - (float)width/2.55)/2.0, width, (float)width/2.55);

Not that complicated.
added on the 2011-03-11 16:29:41 by xernobyl xernobyl
xernobyl: That code assumes both square pixels and a monitor aspect rate of less than 2.55:1. Both are relatively fair assumptions, but worth noting :)
added on the 2011-03-11 16:35:10 by kusma kusma
can we say that :

raytracing = complex ray / object intersection calculation stuff
raymarching = same but with more "brute force" approach (thus less precise but easier to implement and faster)

also , is there any nice raytracing feature (like reflexion, occlusion, phong shading...) which cant be reproduced easily with raymarching ? (in other words : what are the limitations of raymarching ? )
added on the 2011-03-11 23:49:39 by Tigrou Tigrou
as i see it:

* raycasting: when you get analytic intersections
* raymarching: when you get intersections by iteratively stepping (linear, distance based, newtown-raphson, binary search)

these are ray-object intersection methods, they have nothing to do with lighting. lighting (ir, reflections, occlusion, specular, diffuse) are a separate problem and independent of the fact that you use raycasting or raymarching.

"raytracing" is a more generic term, and usually refers to the use of rays to solve the rendering of an image as opposed to rasterization, reyes or point splatting (the other 3 relevant ways of rendering an image). the tracing of the rays could be done with raycasting or marching.

nothing official with these definitions, thought. "raytracing" is used very loosely most of the times, and in 99% of the conversations/papers, "raytracing" just means "not opengl/directx/reyes"


it is true that in the context of 4k scene, the use of a raymarching framework allows you to do some neat lighting fakery as we have seen (ao, softshadows, sss). in the other hand, a proper raycaster with kdtrees/bih/bvh allows you to do similar tricks anyway.
added on the 2011-03-12 00:19:22 by iq iq
ok, thanks for your reply iq, its more clear right now...
added on the 2011-03-12 08:59:33 by Tigrou Tigrou
Thanks xernobyl, but it doesn't work for post processing still, just makes each pass 2.55 * smaller.

So heres the another noob question. How do I move about the scene? I can move the camera but not rotate the view. I'm using IQ's 4k raymarching vertex shader without much modifications.
added on the 2011-03-14 09:07:14 by Mewler Mewler
Read the toolbox thread. There's camera functions where you can just use glTranslate() and shit.
added on the 2011-03-14 09:38:58 by raer raer
mewler: the single quad you're rendering IS the camera. Move that around and rotate it. Scaling it on Z (which would normally have no effect) seems to change camera perspective for me too. Scaling x + y seems equivalient to camera zoom.
added on the 2011-03-14 11:00:36 by psonice psonice
seems? how scientific of you.
added on the 2011-03-14 16:39:40 by xernobyl xernobyl
That's me :) Too much to learn here, I've not figured out how iq's vertex shader actually works yet.
added on the 2011-03-14 16:52:04 by psonice psonice
@psonice Doesn't work for me, rotating the quad only messes up my render. :/
added on the 2011-03-16 08:37:50 by Mewler Mewler
Works perfectly for me.
Use glRotate and such.
added on the 2011-03-16 10:14:25 by raer raer
yep, works here too. Translate quad to move camera, rotate it to rotate camera. What goes wrong? Are you sure you're setting the vertex positions in the vertex shader (exactly like in rare's link to iq's stuff) and passing the cam position + rotation to the fragment shader?
added on the 2011-03-16 11:07:41 by psonice psonice
Nice perlin simplex noise, no texture :)

Interesting, thanks. Any comments on the quality of the noise? The simplex noise I'm using can only do around 20M samples/sec on my card, an order of magnitude improvement would be welcome.
added on the 2011-03-17 16:42:53 by revival revival
PauloFalcao is it faster than this one?
Code: #define pi 3.14159265 float perlin(vec3 p) { vec3 i = floor(p); vec4 a = dot(i, vec3(1., 57., 21.)) + vec4(0., 57., 21., 78.); vec3 f = cos((p-i)*pi)*(-.5)+.5; a = mix(sin(cos(a)*a),sin(cos(1.+a)*(1.+a)), f.x); a.xy = mix(a.xz, a.yw, f.y); return mix(a.x, a.y, f.z); }
added on the 2011-03-17 16:51:58 by las las
And yes, I don't really care that much about the noise quality or whether it's simplex or perlin noise - as long it's "OK".
Speed is much more important.
added on the 2011-03-17 16:53:36 by las las