Raymarching Beginners' Thread
category: code [glöplog]
yeah, i still like fractals too. They have to be presented in a fresh way though, and simple rotating bulbs/boxes are starting to get a little old.
las: Whoa now I see that it's really slow, about 10fps 800x600 on 8800gts. I wasn't working on it much since that was late night/early morning by-product of me plying portal. Now I see it is way to complex scene to approach with a brutforce. I think I'll come back to it later when I have decent lighting and shdows and some optimisation tricks(mentioned above) implemented.
Code is rather a mess of csg and those bendy legs. Well it was truly mindbending when I did it for the first time.
Clicky image.
And now I have no excuse to not march anything today ;)
Code is rather a mess of csg and those bendy legs. Well it was truly mindbending when I did it for the first time.
Clicky image.
And now I have no excuse to not march anything today ;)
I love the reflections on the red thing. Nice work.
10 fps is not so bad, but one can do better... I'll give the triangular thing a try for the first rays. Those are the most expensive and need high precision, I assume that one can lower precision and iteration count for secondary rays - hopefully nobody will notice - and go bruteforce there - maybe with some bounding volume speedup).
Anyways I decided to put the material decider in a separate function - doesn't hurt at all - you can use some mad macro magic in hlsl.
Basically it's one huge macro where you can switch things on and off - the compiler then takes care of kicking stuff out.
Another thing that should be a good idea... Hardcode a BVH.
10 fps is not so bad, but one can do better... I'll give the triangular thing a try for the first rays. Those are the most expensive and need high precision, I assume that one can lower precision and iteration count for secondary rays - hopefully nobody will notice - and go bruteforce there - maybe with some bounding volume speedup).
Anyways I decided to put the material decider in a separate function - doesn't hurt at all - you can use some mad macro magic in hlsl.
Basically it's one huge macro where you can switch things on and off - the compiler then takes care of kicking stuff out.
Another thing that should be a good idea... Hardcode a BVH.
Actually, that's kind of an important optimising point I wasn't aware of until recently, so I'll mention it incase somebody else missed it:
You can have blocks of shader code activated by a conditional, and trigger that conditional with a uniform bool. This lets you turn stuff on and off from outside the shader, which is useful, and it has negligible performance impact.
That's kind of handy for a bunch of stuff, particularly when experimenting (1-click to turn things like shadows + reflections on/off), but also you can build tons of stuff into the shader, and by turning things on/off outside the shader you can pretty much switch scenes, materials, anything else. Switching between distance functions is super useful for a start :)
You can have blocks of shader code activated by a conditional, and trigger that conditional with a uniform bool. This lets you turn stuff on and off from outside the shader, which is useful, and it has negligible performance impact.
That's kind of handy for a bunch of stuff, particularly when experimenting (1-click to turn things like shadows + reflections on/off), but also you can build tons of stuff into the shader, and by turning things on/off outside the shader you can pretty much switch scenes, materials, anything else. Switching between distance functions is super useful for a start :)
Not sure about that - but I think the driver might "recompile" the shader in situations like that - like some kind of "just in time" stuff.
what happens (at least on an imagination GPU, I'm assuming it's the same on nvidia/ati) is that the GPU checks this before scheduling the shaders. This way it knows which branches will be used, and it tells the shader units to follow that branch. The shader units don't evaluate the conditional at all during execution, and they ignore the branch they're not following.
So during the actual rendering, there is zero performance hit from the conditional in this case, just a pretty trivial hit before rendering actually starts. No recompile too :)
So during the actual rendering, there is zero performance hit from the conditional in this case, just a pretty trivial hit before rendering actually starts. No recompile too :)
what? recompiling shaders on the fly (just in time) or per permutation is the worst the driver could possibly do game wise. demoscene is left out there I guess. so I assume they don't. else this would be a major framebreaker on the cpu side.
as for breaking shaders per conditional it should usually take a jump to the code that should be executed after the break. this' where conditional shader syntax compilation usually sucks.
as for breaking shaders per conditional it should usually take a jump to the code that should be executed after the break. this' where conditional shader syntax compilation usually sucks.
yumeji: no recompile. I just managed to fuck up what I'm working on as it happens, causing it to recompile the shader per frame. Framerate dropped to maybe 3fps. Switching my bools to enable code blocks causes no framerate hit. It's definitely not recompiling :)
yeah. @psonice. I thought about it. the per object terms aren't really there for pure per FS frame marching. this's my fault I guess. sorry. ;)
Quote:
So during the actual rendering, there is zero performance hit from the conditional in this case, just a pretty trivial hit before rendering actually starts
....
no.
i'd try and offer some helpful advice based on the actual workings of shader compilers and the hardware in question, but it sounds like you've already made up your mind about how it works so im not going to bother. :) that, and it would probably breach an nda or two.
I didn"t make up my mind yet :)
I would enjoy having a private conversation on that issues and some other things I am not really sure about - you can find me in #ukscene. german invasion! :D
I would enjoy having a private conversation on that issues and some other things I am not really sure about - you can find me in #ukscene. german invasion! :D
psonice: And I guess drivers are not that dumb.
smash: ah, ffs! I based that 'making my mind up' on the sgx development recommendations for flow control, which described this as a performance win. You can hardly blame me for basing my opinion on that :D But, I just re-read it, and realised i missed the word 'not', as in 'not a performance win'. Fuck. I really need more sleep. Or more coffee.
Fuck, fuck, fuck. Now I have to totally re-write what I've done over the last couple of days, because it's performance critical. And it's basically a long list of effects that get turned on or off individually, so it does need flow control. There's not that many permutations, so I could just build a shader for each permutation and switch between them. It's a pain in the arse to code, but fast at least.. Any other suggestions?
And yeah, best to forget that helpful advice I gave above then ;) Sorry!
Fuck, fuck, fuck. Now I have to totally re-write what I've done over the last couple of days, because it's performance critical. And it's basically a long list of effects that get turned on or off individually, so it does need flow control. There's not that many permutations, so I could just build a shader for each permutation and switch between them. It's a pain in the arse to code, but fast at least.. Any other suggestions?
And yeah, best to forget that helpful advice I gave above then ;) Sorry!
psonice: see, that's what i meant about conjecture.. :)
the only way to work out the performance is to try things out, see what affects framerate, then use your profiling tools and *look at the compiled shader assembler output* to see why things are happening. if your choice of shader language / api doesnt support you in that, switch. :) gpus are a complex business, guesswork doesn't hold up.
the only way to work out the performance is to try things out, see what affects framerate, then use your profiling tools and *look at the compiled shader assembler output* to see why things are happening. if your choice of shader language / api doesnt support you in that, switch. :) gpus are a complex business, guesswork doesn't hold up.
smash: That wasn't conjecture, it was pure fuck up ;)
I have actually been profiling this, and the results did look very good. That said, I wasn't comparing the conditionals version to an empty shader (which is what it ends up as pretty much with everything off). The platform is iOS so there's not a lot of choice when it comes to APIs and shader languages.
Do you happen to know much about how it handles 1 & 2 channel rendering btw? That's my next bit to investigate. There's a choice of RGBA as the render target, no L/LA (I'm just processing a big texture, in either L8 or LA8 format) so I could pack 4 L values into the RGBA channels and process all as vec4s or mask out 3 channels and do it all scalar. The docs are a bit light on details for that one, so guesswork is all I'm left with. I take it vector isn't going to be 4x faster than scalar here, and the hardware is smart enough to vectorise it itself? Any idea?
Ferris: roughly what I was thinking, seeing your code for this is helpful :)
At first, I thought you'd figured out how to combine snippets of the compiled code.. now that would be useful! No need to store so many programs (I think 144 for me with some optimisation). Not sure if that's even possible though, and it would be a nightmare with anything more than one gpu + shader compiler, at least with glsl.
I have actually been profiling this, and the results did look very good. That said, I wasn't comparing the conditionals version to an empty shader (which is what it ends up as pretty much with everything off). The platform is iOS so there's not a lot of choice when it comes to APIs and shader languages.
Do you happen to know much about how it handles 1 & 2 channel rendering btw? That's my next bit to investigate. There's a choice of RGBA as the render target, no L/LA (I'm just processing a big texture, in either L8 or LA8 format) so I could pack 4 L values into the RGBA channels and process all as vec4s or mask out 3 channels and do it all scalar. The docs are a bit light on details for that one, so guesswork is all I'm left with. I take it vector isn't going to be 4x faster than scalar here, and the hardware is smart enough to vectorise it itself? Any idea?
Ferris: roughly what I was thinking, seeing your code for this is helpful :)
At first, I thought you'd figured out how to combine snippets of the compiled code.. now that would be useful! No need to store so many programs (I think 144 for me with some optimisation). Not sure if that's even possible though, and it would be a nightmare with anything more than one gpu + shader compiler, at least with glsl.
psonice, go and look at the new extensions introduced in iOS 5
the problem with combining compiled code would be that you would not get the benefit of cross-snippet optimisation
Whoa, R8 and RG8 formats \o/ If only I could wait a few months :/ But, come autumn, my life will get easier :)
Any good resources how to get the best out of HLSL (dx9 :()?
I've noticed something strange with my raytracer. There's an odd glitch in the reflections. Look at the reflected horizon in this pic:
Anyone else seen something like that? The sphere's normals look fine, and the reflection rays look fine (I've separated them out and cranked them up so any glitches would be obvious). I can't think why the trace function itself would cause this, as it's working fine elsewhere, and it's working fine for reflections unless it's causing this somehow.
Anyone else seen something like that? The sphere's normals look fine, and the reflection rays look fine (I've separated them out and cranked them up so any glitches would be obvious). I can't think why the trace function itself would cause this, as it's working fine elsewhere, and it's working fine for reflections unless it's causing this somehow.
Are you tracing with some kind of "max_t"? You are not raymarching at all, right? Source please.
yeah, it's pure trace. i just have a bunch of distance functions, and take the minimum, except it's returning the distance to the surface directly, plus normal + object id. I then take the minimum value, same as a raymarch.
What do you mean by max_t? The maximum trace bounces? I'm only using 1 bounce + 1 AO ray + 1 shadow ray, so no need for that.
No code for now at least, because 1. it's a mess and 2. i might end up using it for something commercial as well as a demo :)
What do you mean by max_t? The maximum trace bounces? I'm only using 1 bounce + 1 AO ray + 1 shadow ray, so no need for that.
No code for now at least, because 1. it's a mess and 2. i might end up using it for something commercial as well as a demo :)
It's a fucking chrome sphere on a checkerboard - are you serious?
yep :) Well, not the sphere on a checkerboard test scene, but the code behind it.
I'll strip out the extra bits i don't want to be public later, and post up a simplified version (it'll help plenty to figure this out anyway).
I'll strip out the extra bits i don't want to be public later, and post up a simplified version (it'll help plenty to figure this out anyway).