pouët.net

Go to bottom

Raymarching Beginners' Thread

category: code [glöplog]
It's just too tempting to steal post #1000...
added on the 2011-06-23 10:33:17 by kusma kusma
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.
added on the 2011-06-23 10:44:13 by psonice psonice
it's worth looking into the different post processing AA options out there - siggraph this year has a whole course on them. :)
added on the 2011-06-23 11:10:50 by smash smash
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.
added on the 2011-06-23 11:19:56 by nystep nystep
Seems you are doing it wrong ;)
added on the 2011-06-23 14:16:31 by las las
psonice: maybe rendering some other target at a different res would help with that.
added on the 2011-06-23 17:09:38 by xernobyl xernobyl
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 :)
added on the 2011-06-23 17:47:07 by psonice psonice
las, if you have any "better" way, feel free to share ;)
added on the 2011-06-23 20:03:05 by nystep nystep
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.
added on the 2011-06-26 16:17:17 by las las
what about the performance?
added on the 2011-06-26 16:20:35 by xernobyl xernobyl
It uses early exit and is only applied to a few pixels. It's supereffective!
added on the 2011-06-26 16:26:06 by las las
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)
added on the 2011-06-26 16:37:45 by kb_ kb_
kb what are you waiting for to update and upload a few of them? ;)
added on the 2011-06-26 17:49:00 by xernobyl xernobyl
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. :)
added on the 2011-06-26 18:29:48 by kb_ kb_
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 :)
added on the 2011-06-26 20:25:23 by smash smash
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
added on the 2011-06-27 02:53:39 by kb_ kb_
"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
added on the 2011-06-27 03:37:45 by shuffle2 shuffle2
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
added on the 2011-06-27 05:39:40 by T21 T21
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.
added on the 2011-06-27 05:52:26 by xernobyl xernobyl
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.
added on the 2011-06-27 09:02:55 by T21 T21
T21: looking at twitter it looks good enough for everybody.
added on the 2011-06-27 10:22:59 by xernobyl xernobyl
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.
added on the 2011-06-27 10:37:41 by las las
Should it be used before or after blurings (DOF, motion blur, ...)?
added on the 2011-06-27 10:52:37 by xernobyl xernobyl
That depends on your blurs. If you have sharp blurring artifacts (!?) then wait until afterwards, I suppose?

login

Go to top