Raymarching Beginners' Thread
category: code [glöplog]
@SiliconLife: why are you using glXGetProcAddress to get function pointers? There's usually no need in that on Linux (and other *nixes I had my hands at) and the functions get dynamically linked to your program automagically.
Quote:
well, the program needs shader.h to run... and I'm in the need of motivation, in fact.
not sure a header file will fix your motivation problems...
why don't you code it by yourself, and fight lack of motivation that way?
@Bartosh: shader.h is the shader that I already posted in the post with the picture, but here it is again: http://pastebin.com/b0MJCp5A
@w23 : it was the only way I could get them to work... i wrote this on my work computer where I can't install any packages and dont have glew or glut.
@SiliconLife: strip ARB suffixes from function names and try to link it as is.
@Silly Con Life : thank you !
I may help me to look about shaders for opengl. as I told you I'm annoyed by silly people, at now, I can look without internet.
Moreover, those silly people just have bought a computer, I do not know if you understand the problem exactly.
But I've got some mental motivation problems that I'm tired before coding and I have cancer and I'm tired, but I would hope do something at now.
Really thank you !
Moreover, those silly people just have bought a computer, I do not know if you understand the problem exactly.
But I've got some mental motivation problems that I'm tired before coding and I have cancer and I'm tired, but I would hope do something at now.
Really thank you !
In polish but with code
http://logos7.pl/Anupadaka/sde_space_operations.php
http://logos7.pl/Anupadaka/sde_primitives3D.php
- webgl-version crashes my driver:
http://logos7.pl/
http://logos7.pl/Anupadaka/sde_space_operations.php
http://logos7.pl/Anupadaka/sde_primitives3D.php
- webgl-version crashes my driver:
http://logos7.pl/
I guess I'm a bit late to the raymarching party, having just got interested about a week ago, but I'm having a few teething issues that I'm wondering if someone can help with. Basically, my stuff so far is http://ranulf.net/webgl/minimal.html and http://ranulf.net/webgl/minimal2.html, both very cut down versions of iq's apple shader (I've cut out all the shading code to try to track down the problem I'm having).
If I modify his apple shader directly, it works but it's sloooooooow! (well, at least on my old cards at home). What I attempted to do was implement the sphere marching stuff in his rwwtt.pdf presentation, but it seems the shader compiler is totally breaking everything. Ironically, it works exactly as I'd expect on my incredibly slow Nvidia cards at home under Linux, but fails badly at work with high-end Nvidia cards under Windows with newer drivers. Basically, the offending code fragment is this:
If you comment out both the breaks, the windows machines produce the same results as the Linux machine - a shaded black-red image on a red background, but with the breaks there as shown, it's rendered green-on-orange - showing that the iteration count has reached the maximum 1000 and the break has been ignored, rather than breaking to the return. Forcing the return by uncommenting the first return line (as in minimal2.html) and you get a solid black on solid orange image - showing that for any ray that does hit a surface, regardless of iteration count, it always returns the initial conditions of t and c (both 0) and anything that misses, carries on until all iterations have completed.
Clearly, the shader compiler is doing something that is arguably wrong. However, I'm guessing this problem must be faced by everyone else too, and so I'm wondering how everyone else manages to do sphere marching from a single shader. Or is it the case that everyone is just ray marching and advancing by a fixed amount each iteration?
I'm half contemplating trying to approach this problem with OpenCL instead, but I'd kind of like to get this to work in a shader as developing with WebGL definitely seems easier for quick iteration times...
If I modify his apple shader directly, it works but it's sloooooooow! (well, at least on my old cards at home). What I attempted to do was implement the sphere marching stuff in his rwwtt.pdf presentation, but it seems the shader compiler is totally breaking everything. Ironically, it works exactly as I'd expect on my incredibly slow Nvidia cards at home under Linux, but fails badly at work with high-end Nvidia cards under Windows with newer drivers. Basically, the offending code fragment is this:
Code:
...vec2 intersect(in vec3 ro, in vec3 rd) {
float t = 0.0;
float c = 0.0;
for (int i = 0; i < 1000; i++) {
vec2 h = map(ro + rd*t);
/*if (h.x<0.0) {
return vec2(t,c);
} else*/
if (h.x<0.001) {
// return vec2(t,c);
// return vec2(t+h.x,c);
break;
} else {
t += h.x;
c += 1.0;
if (t>10.) {
break;
}
}
}
return vec2(t,c);
}Code:
col = vec3(tmat.x *0.2,(tmat.y/2000.0),0.0);If you comment out both the breaks, the windows machines produce the same results as the Linux machine - a shaded black-red image on a red background, but with the breaks there as shown, it's rendered green-on-orange - showing that the iteration count has reached the maximum 1000 and the break has been ignored, rather than breaking to the return. Forcing the return by uncommenting the first return line (as in minimal2.html) and you get a solid black on solid orange image - showing that for any ray that does hit a surface, regardless of iteration count, it always returns the initial conditions of t and c (both 0) and anything that misses, carries on until all iterations have completed.
Clearly, the shader compiler is doing something that is arguably wrong. However, I'm guessing this problem must be faced by everyone else too, and so I'm wondering how everyone else manages to do sphere marching from a single shader. Or is it the case that everyone is just ray marching and advancing by a fixed amount each iteration?
I'm half contemplating trying to approach this problem with OpenCL instead, but I'd kind of like to get this to work in a shader as developing with WebGL definitely seems easier for quick iteration times...
Quote:
developing with WebGL definitely seems easier for quick iteration times
imho: no. Better use a specialized tool (homebrew or something like Rendermonkey) and you have also more current GLSL.
Sounds like a angle compiler issue. Tell your browser to use "native-gl". That's unsafe but should work.
i was like "hm, that's weird, it shouldn't be doing that" until ou mentioned WebGL in your last sentence. Go OpenGL (Rendermonkey as las suggest or do your own on-the-fly-shader-reloading thing). WebGL sucks. Really, don't even try ^_^
Ah ha! Thanks for those pointers... it didn't even occur to me that it'd do something crazy like not passing GL shaders to the GL drivers!
Thanks to las, I found the webgl.prefer-native-gl setting which when set to true does fix my problem with the shader at work, but I also knocked together a small linux testbed yesterday which does provide a faster iteration time than a firefox page reload, so I'll do the same thing under windows too!
Cheers guys!
Thanks to las, I found the webgl.prefer-native-gl setting which when set to true does fix my problem with the shader at work, but I also knocked together a small linux testbed yesterday which does provide a faster iteration time than a firefox page reload, so I'll do the same thing under windows too!
Cheers guys!
iq: Awesome work on the articles and the live demo at beautypi... it's all very inspirational! :)
this one should do the job
It's using #version 400 shaders and glCreateShaderProgramv (which is not supported by Intel - I hope). If it does not crash - and works - you might have to press ESC for a while to make it quit - lazy code.
So this will crash either in case you get the Intel Device (currently not supporting GL_ARB_separate_shader_objects thus no glCreateShaderProgramv) or in case some random NV Driver fun happens.
It needs at least OpenGL 4.1 iirc, so be sure you have support for that on your given NV card (well you should have support for that... otherwise I don't think you would mind reading this thread).
Zoom: Please tell me that this works on your machine - which seems to be the "worst case machine".
It's using #version 400 shaders and glCreateShaderProgramv (which is not supported by Intel - I hope). If it does not crash - and works - you might have to press ESC for a while to make it quit - lazy code.
So this will crash either in case you get the Intel Device (currently not supporting GL_ARB_separate_shader_objects thus no glCreateShaderProgramv) or in case some random NV Driver fun happens.
It needs at least OpenGL 4.1 iirc, so be sure you have support for that on your given NV card (well you should have support for that... otherwise I don't think you would mind reading this thread).
Zoom: Please tell me that this works on your machine - which seems to be the "worst case machine".
Sorry, wrong thread
Yep, just to confirm. I knocked up a quick Windows port of my Linux OpenGL testbed at lunch and all the shaders I throw at it work perfectly! Stupid WebGL... :)
Way to go!
Two rather newbish questions:
1. I tried implementing a GPU tracer by just drawing a large rectangle over the screen with gl_Ortho enabled, which works. Is it ok if I calculate the direction vector from the camera to the screen in the vertex shader and then let it interpolate for all the fragments, or do I have to do this individually for each pixel? Does it even have any kind of performance boost?
2. Are distance fields in any way usable for terrain generations? I can't really imagine any way to combine perlin noise (let alone fractal perlin noise) with distance fields, but I've seen a lot of real-time demos around using terrains, and I doubt they all use rasterization.
1. I tried implementing a GPU tracer by just drawing a large rectangle over the screen with gl_Ortho enabled, which works. Is it ok if I calculate the direction vector from the camera to the screen in the vertex shader and then let it interpolate for all the fragments, or do I have to do this individually for each pixel? Does it even have any kind of performance boost?
2. Are distance fields in any way usable for terrain generations? I can't really imagine any way to combine perlin noise (let alone fractal perlin noise) with distance fields, but I've seen a lot of real-time demos around using terrains, and I doubt they all use rasterization.
@Orpheon: looking back at my old code, which to say is iq's old code, yes you can get the VS to interpolate it, as long as you normalize it in the fragment shader.
Not sure about distance fields for terrains (I'm sure it's possible, just that I'm not the one to ask), however there is an optimization for raymarching where you compute the maximum height of an area of cells and store it in the mipmap of a height texture. You can then skip large areas of the terrain when marching a ray that passes clear above the map. It's very fast, but I haven't managed to get it to interpolate the heights over a cell for a smooth terrain.
Not sure about distance fields for terrains (I'm sure it's possible, just that I'm not the one to ask), however there is an optimization for raymarching where you compute the maximum height of an area of cells and store it in the mipmap of a height texture. You can then skip large areas of the terrain when marching a ray that passes clear above the map. It's very fast, but I haven't managed to get it to interpolate the heights over a cell for a smooth terrain.
I did terrain in a raymarcher a while back, and yes it works.
I did pretty much what bloodnok described, using a height map. What I did was select the mipmap based on distance from the surface, so the closer the ray gets the lower the mipmap level. Because the landscape can't be any higher than the height of the heightmap you can trace to the plane representing the 'top' when the camera is above it looking down. That can save some early steps.
You can also take that a bit further. I added a 2nd height map as a detail texture, and also a normal map. That gets you a landscape that looks pretty good zoomed out, but nice and detailed when zoomed in.
There is a downside though: when the camera is just above the surface and looking out, it can see a long way and the ray is almost always close to the surface - that's kind of worst case for a raymarcher as the ray moves very slowly.
It might be worth looking up 'cone mapping' for this. I had an idea of using multiple cone maps for different heights within the heightmap to help accelerate rendering when the camera is inside the height map, but never got around to trying it.
I did pretty much what bloodnok described, using a height map. What I did was select the mipmap based on distance from the surface, so the closer the ray gets the lower the mipmap level. Because the landscape can't be any higher than the height of the heightmap you can trace to the plane representing the 'top' when the camera is above it looking down. That can save some early steps.
You can also take that a bit further. I added a 2nd height map as a detail texture, and also a normal map. That gets you a landscape that looks pretty good zoomed out, but nice and detailed when zoomed in.
There is a downside though: when the camera is just above the surface and looking out, it can see a long way and the ray is almost always close to the surface - that's kind of worst case for a raymarcher as the ray moves very slowly.
It might be worth looking up 'cone mapping' for this. I had an idea of using multiple cone maps for different heights within the heightmap to help accelerate rendering when the camera is inside the height map, but never got around to trying it.
I kind of know whats going on (the object deformation messup the ray marching), but can this be fixed where the FX look the same just without the artifacting?
http://glsl.heroku.com/e#6111
http://glsl.heroku.com/e#6111
I thought is was more because the ray is approaching the cylinder segment end-on and with the discontinuity it makes a good intersection harder to find.
Someone posted the fix...
You had the right idea, but the issue is from the sharp size transition.
To get the correct distance to the closest object you need to evaluate multiple section not just one.
Now, the remaining fringe happen exactly for the reason you stated.
(the raymarching loop bails out quickly if its close enough)
http://glsl.heroku.com/e#6123.1
You had the right idea, but the issue is from the sharp size transition.
To get the correct distance to the closest object you need to evaluate multiple section not just one.
Now, the remaining fringe happen exactly for the reason you stated.
(the raymarching loop bails out quickly if its close enough)
http://glsl.heroku.com/e#6123.1
Tonight graphics fun :)
704 Remake based on @P_Malin framework http://glsl.heroku.com/e#6254.0 Loved the results! Awesome framework!
704 Remake based on @P_Malin framework http://glsl.heroku.com/e#6254.0 Loved the results! Awesome framework!
That looks good enough to lick!