Raymarching Beginners' Thread
category: code [glöplog]
30 seconds?! I just checked with chrome, and it's saying ~650ms, from the time when I click on the link to when it starts rendering. Most of that is network delay! Something is badly fucked :D
Just checked the shader in my own setup, and it works/reports no errors (it's quite fussy, so that's a good sign). Probably a driver issue on your machine at a guess?
A driver issue that amd and nvidia agrees on? ;) Maybe a browser issue if it only works on the macos version..
Startup time is also more like 30s here (still windows/nvidia).
Startup time is also more like 30s here (still windows/nvidia).
Haha, so somehow I've managed to code something that only runs properly on Mac, without even owning a Mac myself... Steve Jobs must have infected my texteditor with a virus or something!
Speaking of silly platform wars, maybe it's all microsoft's fault? Are the PC browsers wrapping the opengl es into opengl or DX? If it's DX, it might be some odd HLSL issue.
It runs fine for me in both firefox and chrome btw.
It runs fine for me in both firefox and chrome btw.
Win firefox' problem(probably), long start, normals effed up(much like on kusma's screenshot). Works fast and fine under opera dev build(same picture as psonice posted).
Hmmm... from a quick search of the net, it looks like chrome + firefox use directx wrappers for webgl. Opera uses opengl - but plans to switch to directx when it's final. There was some suggestion that chrome might use opengl if opengl 2.0 drivers are available on the system.
Might be something along the lines of an explanation anyway :)
Might be something along the lines of an explanation anyway :)
psonice: Ah.. Yeah, that sounds like a reasonable explanation.
So I guess I need to find some other "test-container" than WebGL to try out my little GLSL-raymarching stuff in then. Perhaps I'll look into setting up IQs framework again.
Too bad, just coding in a text-file and pressing "reload" in the browser was so damn quick-and easy.
So I guess I need to find some other "test-container" than WebGL to try out my little GLSL-raymarching stuff in then. Perhaps I'll look into setting up IQs framework again.
Too bad, just coding in a text-file and pressing "reload" in the browser was so damn quick-and easy.
I only tested it under ubuntu.
On windows chrome uses angle to transform the shader into HLSL and then compiles it and that often takes so much time that chrome thinks "this stuff crashed".
I'll take a look at it on my windows box now. Debugging GLSL code that is transformed to HLSL code you don't know is crap. Is there any simple way to intercept the HLSL code?
On windows chrome uses angle to transform the shader into HLSL and then compiles it and that often takes so much time that chrome thinks "this stuff crashed".
I'll take a look at it on my windows box now. Debugging GLSL code that is transformed to HLSL code you don't know is crap. Is there any simple way to intercept the HLSL code?
Great, so chrome/firefox tries to avoid opengl driver problems by using a more buggy translation :D
Sdw: Rendermonkey is great for that (too bad it doesn't support dx11)
Sdw: Rendermonkey is great for that (too bad it doesn't support dx11)
I think you can achieve pretty much the same experience with 1kpack(yes there is glsl support, never tried it tho) by creating batch for compilation and using outer file for shader( incbin ;). Just saying.
a13X_B: full ack.
Given that some guys already discussed moving the whole stuff to some wiki... We shouldn't move the whole discussion away from pouet - but having a wiki or something with basecodes for NASM, C, C++, WebGL for HLSL / GLSL + some basic tutorials covering beginners problems and the basic techniques (basic sphere tracing, csg, ao, step length, ...) could be a really great move.
Maybe a raymarcher mafia diskmag would be a very demoscenish way to accomplish that ;)
Now that I booted my windows machine, I'll take a proper look at the shaders...
Given that some guys already discussed moving the whole stuff to some wiki... We shouldn't move the whole discussion away from pouet - but having a wiki or something with basecodes for NASM, C, C++, WebGL for HLSL / GLSL + some basic tutorials covering beginners problems and the basic techniques (basic sphere tracing, csg, ao, step length, ...) could be a really great move.
Maybe a raymarcher mafia diskmag would be a very demoscenish way to accomplish that ;)
Now that I booted my windows machine, I'll take a proper look at the shaders...
Okay two words: BUGGY SHIT.
SHOW ME YOUR.
SHOW ME YOUR.
Sdw: You better use some real GLSL (maybe use one of iq's nice frameworks with C/C++ source) and not GLSL ES - by naming it webgl-experimental that are definitely not joking.
Hmm, seems one wants ff4: about:config -> webgl.prefer-native-gl true
Wohoo! Thanks las, that solved it nicely, now it runs fast and compile-time even with 50 iterations is instantaneous!
I might still look into RenderMonkey, seems like you have some nice possibilities to add mouse-controlled variables etc. with that.
I might still look into RenderMonkey, seems like you have some nice possibilities to add mouse-controlled variables etc. with that.
Oh my, I'm posting like crazy in this thread, bear with me!
Now with las fix I'm back developing at a nice pace again, managed to add some specular lighting as well and it looks nice.
My next thing was to try and use the magic of mod to create many instances of objects. First,of course I wanted cubes (There are fields, Neo, endless fields...of cubes). So I did a distance function like this:
But no endless field of cubes appeared, instead I got this.
Yeah, not quite what I had expected. I got the same thing when I tried it in Processing. Have I completely misunderstood how to smartly create many instances of an object?
Now with las fix I'm back developing at a nice pace again, managed to add some specular lighting as well and it looks nice.
My next thing was to try and use the magic of mod to create many instances of objects. First,of course I wanted cubes (There are fields, Neo, endless fields...of cubes). So I did a distance function like this:
Code:
vec3 cube1=vec3(0,0.75,0);
float dist(vec3 v)
{
return dist_cube(cube1,vec3(mod(v.x,1.0),v.y,mod(v.z,1.0)),0.3);
}
But no endless field of cubes appeared, instead I got this.
Yeah, not quite what I had expected. I got the same thing when I tried it in Processing. Have I completely misunderstood how to smartly create many instances of an object?
Think a minute.. your cube is at location (0,0,0) or so right? And your mod() function is repeating the geometry at 0, 1, 2 etc. If your cube is centred at 0,0,0 and is size 0.5, it's extending from -0.25 to +0.25. And you're repeating bang in the middle of it!
That really fucks up the ray march, because the ray thinks it's safe to march a certain distance, then it crosses the repeat boundary and it's bang in the middle of cube or worse still, it marches right through it. Put those two cases together and you get a nice glitch field like the one you just rendered :)
Simple solution: move the cube's centre to 0.5 and make sure the length of the cube's sides are no more than 0.99. This way it never crosses the repeat boundary.
Other problems you'll have to deal with:
- The marching step might need to be smaller, to avoid it jumping too far into the next repeated area and stepping inside an object. It REALLY helps here if you use signed distance functions, so if it does step into an object it gets a negative distance, and it steps backwards until it hits the edge of the object. Otherwise you move the point by distance * 0.75 or whatever works for your scene.
- It'll fuck up your AO, because the cubes outside the current repeat tile don't cause any shadowing.
- Complex objects. And trying to figure out if they'll hit the boundaries or not. Especially with repeats more complex than a straight mod. :(
That really fucks up the ray march, because the ray thinks it's safe to march a certain distance, then it crosses the repeat boundary and it's bang in the middle of cube or worse still, it marches right through it. Put those two cases together and you get a nice glitch field like the one you just rendered :)
Simple solution: move the cube's centre to 0.5 and make sure the length of the cube's sides are no more than 0.99. This way it never crosses the repeat boundary.
Other problems you'll have to deal with:
- The marching step might need to be smaller, to avoid it jumping too far into the next repeated area and stepping inside an object. It REALLY helps here if you use signed distance functions, so if it does step into an object it gets a negative distance, and it steps backwards until it hits the edge of the object. Otherwise you move the point by distance * 0.75 or whatever works for your scene.
- It'll fuck up your AO, because the cubes outside the current repeat tile don't cause any shadowing.
- Complex objects. And trying to figure out if they'll hit the boundaries or not. Especially with repeats more complex than a straight mod. :(
psonice show you his! (read carefully what he wrote, he's right!)
I consider Rendermonkey kinda useless for raymarching with heavy load (It renders all the time and makes coding horribly slow... and I can't afford a better machine).
Features one wants in a raymarching tool:
- Key for compile and render one frame (fast checking of e.g. magic color value changes)
- Key for compile without rendering (failchecking while coding)
- Key for compile and render animation + press of the same key pauses rendering again.
I consider Rendermonkey kinda useless for raymarching with heavy load (It renders all the time and makes coding horribly slow... and I can't afford a better machine).
Features one wants in a raymarching tool:
- Key for compile and render one frame (fast checking of e.g. magic color value changes)
- Key for compile without rendering (failchecking while coding)
- Key for compile and render animation + press of the same key pauses rendering again.
Quote:
managed to add some specular lighting as well and it looks nice
better add some spectacular lighting :)
psonice: Thanks, you were right, it worked when I moved the entire object to be within one repeat-area.
Takes some time getting used to this way of thinking of things, I still tend to revert to old "object-is-at-coord-x/y/z-so-it-should-work"-thinking, but that means diddly squat if the raymarcher "misses" so to speak.
Anyway, made some progress today, now I have a system so that I also get info from my distance calculator on which object was closest, so I can have different colors/materials on them.
Takes some time getting used to this way of thinking of things, I still tend to revert to old "object-is-at-coord-x/y/z-so-it-should-work"-thinking, but that means diddly squat if the raymarcher "misses" so to speak.
Anyway, made some progress today, now I have a system so that I also get info from my distance calculator on which object was closest, so I can have different colors/materials on them.
las: cough.. heavy load..
I would consider the property editors (colors, magic constants) essential in a raymarching/shader tool - much faster than entering values and recompiling.
And preferably some way to do multipass as in the screenshot above.
I also have a setup for using the preview camera navigation even in raymarching.
And yes, it would be nice to be able to disable the continuous opengl preview, but usually a sufficiently small preview window, maybe coupled with the hotkey to go fullscreen (on the secondary monitor) will do the trick if rendering is slow.
I would consider the property editors (colors, magic constants) essential in a raymarching/shader tool - much faster than entering values and recompiling.
And preferably some way to do multipass as in the screenshot above.
I also have a setup for using the preview camera navigation even in raymarching.
And yes, it would be nice to be able to disable the continuous opengl preview, but usually a sufficiently small preview window, maybe coupled with the hotkey to go fullscreen (on the secondary monitor) will do the trick if rendering is slow.
Psycho: that's no heavy load when compared to a high-resolution raymarcher. it might look simple setting up a quad with a single pixel shader tied to it, but for every pixel you're doing quite a heavy workload. also, editing colors, textures and multiple passes is near to useless with a raymarcher, because almost all of the data comes straight from the pixel shader itself.
i wrote a basic development environment for my raymarching shader (amazingly close to what las described), and having it render all the time made everything slow, even when the editor was running in an entirely different process. and yes - that included both linux and windows.
i wrote a basic development environment for my raymarching shader (amazingly close to what las described), and having it render all the time made everything slow, even when the editor was running in an entirely different process. and yes - that included both linux and windows.
hcdlt: I may be mistaken, but I think that is raymarched.
And why would multiple passes + texture etc. editing be useless with a raymarcher? If you're doing something really heavy, you render the raymarch pass once. That passes lighting + material data out. Then you render the second pass, which just applies material + texture to it, with no raymarching - this is lightning fast in comparison, and you can edit in realtime.
And why would multiple passes + texture etc. editing be useless with a raymarcher? If you're doing something really heavy, you render the raymarch pass once. That passes lighting + material data out. Then you render the second pass, which just applies material + texture to it, with no raymarching - this is lightning fast in comparison, and you can edit in realtime.
Uhm.. The first pass you can see is called 'Tracer' and using a 'ScreenAlignedQuad' as object - wonder what that is doing? ;)
And yes, the distance function (the full scene isn't visible from this alternative angle) is pretty damn big and slow - it's going like 1 fps on decent hardware in 800x600 (and 8x faster in dx11, but with 3 minutes compilation time..).
Not sure where the 'high-resolution' is needed for preview, especially when you can pan and zoom with the mouse... (and turn off parts of the function when working on others). But as said, when working with non-realtime scenes like this a render-once hotkey would be nice ofcourse, guess you can't have everything ;)
And I don't see how colors and constants are any less relevant when marching/tracing than when rasterizing.
And yes, the distance function (the full scene isn't visible from this alternative angle) is pretty damn big and slow - it's going like 1 fps on decent hardware in 800x600 (and 8x faster in dx11, but with 3 minutes compilation time..).
Not sure where the 'high-resolution' is needed for preview, especially when you can pan and zoom with the mouse... (and turn off parts of the function when working on others). But as said, when working with non-realtime scenes like this a render-once hotkey would be nice ofcourse, guess you can't have everything ;)
And I don't see how colors and constants are any less relevant when marching/tracing than when rasterizing.