Raymarching Beginners' Thread
category: code [glöplog]
It's just too tempting to steal post #1000...
xernobyl: it'll only reflect surfaces that are visible on screen, i.e. it'll fail badly if the reflection should show the rear of an object, and off-screen objects will disappear completely. Just like SSAO really, but much more obvious :) But yeah, could be ok in limited cases like water.
If we're raymarching though, why not just raymarch the reflections? Speed is the major downside, I guess.
If we're raymarching though, why not just raymarch the reflections? Speed is the major downside, I guess.
it's worth looking into the different post processing AA options out there - siggraph this year has a whole course on them. :)
So, does it means that this is the biggest coding thread evah on pouet? cool.
With all respects, i don't think that blurring really helps with hiding away "raymarching artifacts". There are many sins which end up producing the typical banding artifacts,
- we're missing the nearest object and continue ray-marching in a zone that suits a nonlinear curved shape: our signed distance function is then simply breaking the assertion that it should return in all points of the space the euclidean distance to the nearest point of any object in the environment. We're overshooting. It's a common problem with distance estimators/approximations.
- Artifacts can be due to the fact that you use ray-marching instead of cone-marching. It's not only faster, it also helps to reduce artifacts.
- Banding artifacts are also occurring when you lack precision in finding your intersection. You can fix this by using a bisectant search around your intersection. One can also use a linear interpolation for finding a more precise distance of intersection from the last 2 points evaluated. For shadows, the problem also occurs, it's merely just a precision problem, and the solution is the same: doing a local search to refine your results.
And finally,
- Banding artifacts can occur when you handle the LOD parameter in your signed distance function in a non-continuous manner. Good luck. :)
In conclusion, i'm not really a fan of the "hiding artifacts with blurring" solution, as they underline a larger problem with our code usually.
With all respects, i don't think that blurring really helps with hiding away "raymarching artifacts". There are many sins which end up producing the typical banding artifacts,
- we're missing the nearest object and continue ray-marching in a zone that suits a nonlinear curved shape: our signed distance function is then simply breaking the assertion that it should return in all points of the space the euclidean distance to the nearest point of any object in the environment. We're overshooting. It's a common problem with distance estimators/approximations.
- Artifacts can be due to the fact that you use ray-marching instead of cone-marching. It's not only faster, it also helps to reduce artifacts.
- Banding artifacts are also occurring when you lack precision in finding your intersection. You can fix this by using a bisectant search around your intersection. One can also use a linear interpolation for finding a more precise distance of intersection from the last 2 points evaluated. For shadows, the problem also occurs, it's merely just a precision problem, and the solution is the same: doing a local search to refine your results.
And finally,
- Banding artifacts can occur when you handle the LOD parameter in your signed distance function in a non-continuous manner. Good luck. :)
In conclusion, i'm not really a fan of the "hiding artifacts with blurring" solution, as they underline a larger problem with our code usually.
Seems you are doing it wrong ;)
psonice: maybe rendering some other target at a different res would help with that.
You'd have to raymarch this new target still, and you'd have all the extra complexity of matching the reflection to the new image. In a complex scene with lots of reflective objects, you'd end up with a nightmare really fast!
We're using a rendering technique that supports true reflections here, so we can avoid all that completely. Not to say that there aren't massive optimisations to be had with a bit of cunning of course :)
We're using a rendering technique that supports true reflections here, so we can avoid all that completely. Not to say that there aren't massive optimisations to be had with a bit of cunning of course :)
las, if you have any "better" way, feel free to share ;)
Actually I don't have those hard banding artifacts - I work around them without noticing it.
I fixed a little issue with FXAA3 (pixel centers in DX...) and the visual result went from "this is kinda cute" to "WOW. FUCK MULTISAMPLING". You want FXAA3 - really.
I fixed a little issue with FXAA3 (pixel centers in DX...) and the visual result went from "this is kinda cute" to "WOW. FUCK MULTISAMPLING". You want FXAA3 - really.
what about the performance?
It uses early exit and is only applied to a few pixels. It's supereffective!
Yep, added FXAA3 to Werkkzeug4 to see what all the hype is about and 2 hours later it looked pretty awesome and the framerate hit (tried it with past FR demos) was absolutely neglectible on my GF8800.
(also, aren't pixel centers like the first thing you try to get right when writing postproc shaders? :D)
(also, aren't pixel centers like the first thing you try to get right when writing postproc shaders? :D)
kb what are you waiting for to update and upload a few of them? ;)
http://timothylottes.blogspot.com/2011/06/fxaa3-source-released.html
You're talking about that, right?
You're talking about that, right?
Yep, that exactly. And sorry, won't release inofficial versions of our demos without the others' consent - but be assured, that little shader is absolutely worth it. :)
id be interested in seeing how fxaa3 compares to mlaa.. my initial thought from the screenshots ive seen was it looked more blurry than mlaa. guess i could just download the source and try it :)
fxaa is somewhat more blurry because it doesn't search as exhaustively as mlaa, and for the same reason it's also a little worse for very mild slopes. Also there's a "console" (for 360/PS3 level GPUs) and a "quality" version (GF8xxx and upwards) available, with the former being blurrier.
Then again it's simple, you can do it in one pass (if someone copies luma into the render target's alpha channel, should be doable in some color correction pass without overhead), and on both 360 and PS3 it's reported to take only 1ms of GPU at 720p if you're good. And even if it's a bit more it's still waaay better than the fillrate or mental health you waste on 2xMSAA :D
Then again it's simple, you can do it in one pass (if someone copies luma into the render target's alpha channel, should be doable in some color correction pass without overhead), and on both 360 and PS3 it's reported to take only 1ms of GPU at 720p if you're good. And even if it's a bit more it's still waaay better than the fillrate or mental health you waste on 2xMSAA :D
"In the preceding figure, both the triangle primitives would be rendered in Tile 0."
...what happens to objects covering more than one tile? o.O
...what happens to objects covering more than one tile? o.O
luma = weighted RGB. any reason why it need to be stored in the alpha channel ? (I didn't see an algo description)
BTW, link from his blog.. this is kick ass.
http://blog.icare3d.org/2011/06/interactive-indirect-illumination-and.html
BTW, link from his blog.. this is kick ass.
http://blog.icare3d.org/2011/06/interactive-indirect-illumination-and.html
T21: it saves a few dot(color.rgb, float3(0.299, 0.587, 0.114))... I haven't seen the number of samples it takes, but the guy seems to know what he's doing. He also suggests replacing luma with the green channel in case your alpha channel is busy with something else...
My probably wrong idea: the guy is nvidia biased and supposedly nvidia cards always have the same speed for textures with <= 32bits, so using an RGB, no alpha, buffer would have no advantage, and it would save a few DOTs. But I'm probably wrong.
My probably wrong idea: the guy is nvidia biased and supposedly nvidia cards always have the same speed for textures with <= 32bits, so using an RGB, no alpha, buffer would have no advantage, and it would save a few DOTs. But I'm probably wrong.
xernobyl: I looked at the shader and it makes sense, specially considering what kb_ said about most pipeline having some post processing and its cheap,just one extra dp(), to write RGBY
Also the code use gather4 alpha, so doing the dp() per sample would almost double the number of tex read instruction in the common case.
I'm going to try it out.. if it does remove the majority of objectionable cases, it might be good enough for me.
Also the code use gather4 alpha, so doing the dp() per sample would almost double the number of tex read instruction in the common case.
I'm going to try it out.. if it does remove the majority of objectionable cases, it might be good enough for me.
T21: looking at twitter it looks good enough for everybody.
Actually I wanted my .a channel for something else - but it's no problem - FXAA3 works even very well after some post-processing passes and I then just set the luma in the last combine pass.
Should it be used before or after blurings (DOF, motion blur, ...)?
That depends on your blurs. If you have sharp blurring artifacts (!?) then wait until afterwards, I suppose?
