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.
Mewler: verbose please.
msqrt: Do you multisample there?
The borders of these 'planets' look a bit weird
The borders of these 'planets' look a bit weird
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
msqrt: good start, now try to generate some more complicated geometry and materials!
Quote:
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.
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..
But yeah, more complicated materials would be good. Let's see if I can get something interesting out of this..
Mewler:
glViewport(0, (height - (float)width/2.55)/2.0, width, (float)width/2.55);
Not that complicated.
glViewport(0, (height - (float)width/2.55)/2.0, width, (float)width/2.55);
Not that complicated.
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 :)
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 ? )
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 ? )
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.
* 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.
ok, thanks for your reply iq, its more clear right now...
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.
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.
Read the toolbox thread. There's camera functions where you can just use glTranslate() and shit.
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.
seems? how scientific of you.
That's me :) Too much to learn here, I've not figured out how iq's vertex shader actually works yet.
@psonice Doesn't work for me, rotating the quad only messes up my render. :/
Works perfectly for me.
Use glRotate and such.
Use glRotate and such.
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?
Nice perlin simplex noise, no texture :)
http://www.opengl.org/news/permalink/drop-in-replacement-noise-for-glsl/
http://www.opengl.org/news/permalink/drop-in-replacement-noise-for-glsl/
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.
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);
}
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.
Speed is much more important.
