Raymarching Beginners' Thread
category: code [glöplog]
@las: neat! whats the purpose of the project if i may ask? fast path tracing? is it CUDA,OpenCL or Shader Code?
@Decipher: Shut up and drop your bomb finally ;)
The location of the arealight-source is left as an exercise for the viewer.
@psonice: Yes. :)
@flure: Yes we can, but it looks crap if you do it the "naive" way.
@toxie: That screenshot is PT, currently we are implementing BDPT and some more materials.
Currently BVH/intersection tests in OpenCL the rest is still on the CPU (due to some hard time constraints and a basic given CPU only framework - we are talking about university projects for the average (excluding adok) student here).
The SDF is simply surrounded by an bounding sphere and then integrated into the BVH.
It's a practical(right word?) student group project with 4+1 major tasks on raytracing, covering basically "everything" (you just can't cover everything in just one semester...) from simple intersection tests and whitted raytracing over to photon mapping, PT, bsdfs and so on.
Observations: Integrating SDF's into a proper raytracing framework is pretty simple and the intersection test is still faster than one would expect even OK on the CPU (in case you don't care about realtime rendering and currently at least that project is far from realtime).
The location of the arealight-source is left as an exercise for the viewer.
@psonice: Yes. :)
@flure: Yes we can, but it looks crap if you do it the "naive" way.
@toxie: That screenshot is PT, currently we are implementing BDPT and some more materials.
Currently BVH/intersection tests in OpenCL the rest is still on the CPU (due to some hard time constraints and a basic given CPU only framework - we are talking about university projects for the average (excluding adok) student here).
The SDF is simply surrounded by an bounding sphere and then integrated into the BVH.
It's a practical(right word?) student group project with 4+1 major tasks on raytracing, covering basically "everything" (you just can't cover everything in just one semester...) from simple intersection tests and whitted raytracing over to photon mapping, PT, bsdfs and so on.
Observations: Integrating SDF's into a proper raytracing framework is pretty simple and the intersection test is still faster than one would expect even OK on the CPU (in case you don't care about realtime rendering and currently at least that project is far from realtime).
toxie, psonice: thanks btw. ;)
I'll be back on the real-time stuff as soon as possible.
I'll be back on the real-time stuff as soon as possible.
but hitting the SDF in comparison to another (triangle based)object should slow down the rendering pretty much i guess? (as only a fraction of the SIMT units might hit the SDF, which should be pretty common when doing path tracing -> low utilization of the threads)
las: have you checked Intel Embree (open source project)?
It run decent on a q6600, my guess is that it might match cuda performance found in this work
http://www.pouet.net/prod.php?which=57321
but on a i7-2600k
another great source of source: http://www.toxicengine.org/
It run decent on a q6600, my guess is that it might match cuda performance found in this work
http://www.pouet.net/prod.php?which=57321
but on a i7-2600k
another great source of source: http://www.toxicengine.org/
psionice: just a bit larger of theta for the gradient based normal calulation, I like a bit of beveling. (rounding edges and thus darker color from back facing edges lit by headlight and highlights at the front facing)
At least on the CPU there's some performance impact - but it depends all on your SDF.
Of course sphere tracing an SDF with ~64 steps max is slower than a simple TIT.
But it might even be faster in comparison with the same model in a "similar resolution" triangle mesh representation - and it's much smaller.
Of course sphere tracing an SDF with ~64 steps max is slower than a simple TIT.
But it might even be faster in comparison with the same model in a "similar resolution" triangle mesh representation - and it's much smaller.
@t21: embree is pretty cool, but far from getting at CUDA performance, especially the mentioned techdemo.. its more targetted at producing halfway decent pictures, and not 101% performance..
@las: thats a good point, it might be better suited than actually having the triangle soup of a pre-tesselated triangle model, especially if one thinks about the dozens of 'random' memory reads necessary to traverse the hierarchy/intersect tris..
@las: thats a good point, it might be better suited than actually having the triangle soup of a pre-tesselated triangle model, especially if one thinks about the dozens of 'random' memory reads necessary to traverse the hierarchy/intersect tris..
toxie: doesn't that happen by design with photon tracing, no ray coherency ?
I think thats why Intel Embree perform so efficiently on the CPU.
I think thats why Intel Embree perform so efficiently on the CPU.
I think a i7-2600k is at least 3 time faster then my q6600.
the cornell box gets 2.6 mpps, and converge to what las showing in ~2 second. (With 10 update per seconds so its interactive)
So Embree should render the cornell box (with the light minus the spike ball :) at ~10fps on a i7-2600K
the cornell box gets 2.6 mpps, and converge to what las showing in ~2 second. (With 10 update per seconds so its interactive)
So Embree should render the cornell box (with the light minus the spike ball :) at ~10fps on a i7-2600K
Just for reference (I think I over estimated the FPS/quality on a 2600k)
2 second on q6600.
After 1/10 of a second (when you move in the scene it look like this)
2 second on q6600.
After 1/10 of a second (when you move in the scene it look like this)
las : what is the naive way ? :)
@t21: don't want to point out the obvious, but you know that the only reason why the noise vanishes so fast in this simple example scene is that the path length is limited to 2 (i.e. almost no indirect light at all), whereas the "rest of the world" uses unlimited length/russian roulette..
toxie: dont get me wrong, this was only to start a conversation about CPU vs GPU. I would expect the GPU crowd to pick the same scene as reference. I also picked this one because las gave use a great PT raymarched picture :) ... I'm curious to see what las think of embree and what the GPU crowd think in general.
But from what I gather, the more complex the scene the best the CPU do. So this scene being so simple should give a big advantage to the GPU.
But from what I gather, the more complex the scene the best the CPU do. So this scene being so simple should give a big advantage to the GPU.
Hey, had some serious success with layered raymarching. Allows for some nice fake DoF effects and lets you cheat and render the blurred layer at quarter res. About 50% speedup in the test scene. Also early exit is real easy to do. :)
Right now I'm needing some motionblur, not sure the best way to do it though. "Demoscene" solutions would be awesome.
Right now I'm needing some motionblur, not sure the best way to do it though. "Demoscene" solutions would be awesome.
mewler: what kind of layered? rendering the scene in slices by z distance? (guess that could give some interesting optimisation/effect opportunities!) Or layers with different objects? (Same!)
Mewler: Huge interest. --verbose. Demand code snippets ;)
You render at quarter res , but when the distance is < threshold you issue 4 ray that you write into the front layer using the distance-stepback to start? I'm guessing that this be done using MRT ?
So you endup with a fully rendered quarter res back layer, and an accelerated front layer.
So you endup with a fully rendered quarter res back layer, and an accelerated front layer.
That or do it in two pass.
First pass render front layer: bail when the ray distance > threshold,
Second pass start your ray (quarter res) at threshold.
First pass render front layer: bail when the ray distance > threshold,
Second pass start your ray (quarter res) at threshold.
@psonice Just different f() functions for different layers right now. :)
@las Right now its a very "Demoscene" solution, just render the parts of the scene you know is closest in the first layer, then render the rest in another pass at quarter resolution, then blur. Basically what T21 said.
For a free speedup, just use early exit on pixels in the second that are actually rendered in the first layer.
Overall, its great for bringing complex scenes into a descent framerate.
@las Right now its a very "Demoscene" solution, just render the parts of the scene you know is closest in the first layer, then render the rest in another pass at quarter resolution, then blur. Basically what T21 said.
For a free speedup, just use early exit on pixels in the second that are actually rendered in the first layer.
Overall, its great for bringing complex scenes into a descent framerate.
I'd like to see a simple fake dof for raymarchers src if anyone has had more luck than me with this?
weyland: do what mewler just described. Put near + far objects into foreground + background layer. Blur foreground + background. :)
For nice bokeh effects in DOF:
http://mynameismjp.wordpress.com/2011/02/28/bokeh/
http://mynameismjp.wordpress.com/2011/02/28/bokeh/
Question:
What's a good tool for viewing LUT type textures? I.e. something that can load RGBA images and view one channel at a time, preferably with adjustable brightness.
Reason being, I just wrote a tool that writes out RGBA textures as PNG or TIFF, but the values in each channel are generally in the range 0..10, meaning they're a) very dark and b) very transparent. Anything that premultiplies the alpha basically wipes out the image!
What's a good tool for viewing LUT type textures? I.e. something that can load RGBA images and view one channel at a time, preferably with adjustable brightness.
Reason being, I just wrote a tool that writes out RGBA textures as PNG or TIFF, but the values in each channel are generally in the range 0..10, meaning they're a) very dark and b) very transparent. Anything that premultiplies the alpha basically wipes out the image!
pfsview, use .exr.