GPU VCM

A picture is worth a thousand words.
jbikker
Posts: 175
Joined: Mon Nov 28, 2011 8:18 am
Contact:

Re: GPU VCM

Postby jbikker » Sat Jun 11, 2016 6:25 am

I currently use the Microfacet BRDF from "Physically Based Rendering - From Theory to Implementation": Blinn-Phong, Schlick's Fresnel, G from the book.
The material model is from SmallVCM: sampleBRDF() to obtain a direction with a probability proportional to the BRDF; evaluateBRDF() to get a probability for a given set of directions, extended with bidirectional evaluation. This is used consistently and greatly helps to reduce code complexity.
The BRDF evaluation is hardly branchless though, and involves moving from world to local space and back, as well as a 'pow', a 'sqrt', a 'sin' and a 'cos'. As a consequence, switching to Lambert (with the same interface, of course) affects performance quite a bit.

koiava
Posts: 45
Joined: Thu Apr 24, 2014 8:18 am
Location: Munich, Germany
Contact:

Re: GPU VCM

Postby koiava » Mon Jun 13, 2016 1:39 pm

Great results as always :)
Thing which is strange for me in "vcm gpu" video is that photons are very noticeable.
Directly visible photons correspond to CD.*L path which should have much lower MIS weight then BPT paths. Am I right?
Also in last two videos "BDPT with directional regularization" and "directionally regularizated light transport", caustics visible in mirror(CSDS.*L paths) has much less noise then CD.*L paths, I'm not familiar with with that algorithm itself but it looks very strange for me.
Colibri Renderer

jbikker
Posts: 175
Joined: Mon Nov 28, 2011 8:18 am
Contact:

Re: GPU VCM

Postby jbikker » Tue Jun 14, 2016 2:02 pm

The directly visible photons should have a low MIS weight, but also carry quite some energy; perhaps this could explain their brightness?
I followed SmallVCM quite closely; the renderer converges to the correct image for 'easy' scenes (large light source, so that unidirectional path tracing can find it), so I assumed I got it 'right'.

Regarding the low noise levels in the mirror, and particularly in the caustic: I find that strange too; so I did some experiments:

- In general the mirorred caustic is not nearly as bright. This turns out to be caused by some clamping I am doing: paths carrying too much energy are normalized, then scaled to the maximum throughput. This greatly reduces fireflies, but introduces bias. Without the clamping, the caustic in the mirror converges slowly, due to the contribution of rare high energy paths. With the clamping, bias is significant for this feature.

- In general the floor viewed via the mirror is not as noisy as the floor seen directly. This effect goes away if I use a diffuse shader; for the microfacet BRDF the regularized bounces are actually less specular than the microfacet BRDF, which causes surfaces to converge quicker when seen in the mirror. After a few passes this effect goes away (the technique is consistent), but by that time, the noise is already low.

So... bias is affecting the renderer.

Does the above make sense? I'm trying to get a grasp on proper light transport so I'm not very confident it's all perfect. :)

I optimized it a bit since posting the video by the way: it runs at roughly twice the speed now. Looks like 16 samples is quite close to 'enough' for interactive rendering. It would also be interesting to see how some basic filtering would do with this kind of input.

ingenious
Posts: 273
Joined: Mon Nov 28, 2011 11:11 pm
Location: London, UK
Contact:

Re: GPU VCM

Postby ingenious » Tue Jun 14, 2016 11:00 pm

Nice videos!

I'd recommend using a smaller radius for vertex merging, something close to the projected pixel size, which would remove the nasty photon splotches. With VCM you can most often get away with using a small radius (unlike in PPM), because in the areas where merging is important the photon density is typically high, and in regions where it isn't important other techniques are better (and will be weighted higher). Ideally you'd want to determine the merging radius for every pixel from the pixel footprint at the first non-specular surface. A slight modification to the MIS weight computation is necessary in this case, which I've described in section 8.5.1 of my thesis. The nice thing is that this will remove the generally very sensitive world-scale radius parameter from your render settings. If you still want to retain some control, you can have a global radius_scale parameter to multiply the footprint-determined per-pixel radius.

Question: On that scene with the mirror, what's the improvement you see with directional regularization over pure BDPT? I'm asking because directional regularization was originally designed to render "impossible" paths from point light sources and is pretty much equivalent to enlarging your light source a bit. And your scene has a decently sized light source already.
Image Click here. You'll thank me later.

jbikker
Posts: 175
Joined: Mon Nov 28, 2011 8:18 am
Contact:

Re: GPU VCM

Postby jbikker » Wed Jun 15, 2016 9:06 am

If I use a radius close to the projected pixel size the number of photons arriving per pixel is going to be low, right? That would probably lead to fireflies for quite a bit longer than the first 16-32 samples, which is the time frame I'm trying to optimize for.

As for the improvement of directional regularization over BDPT: it's also in this small time frame; the light cast by the mirror shows considerably less noise early on.

dirreg.png
dirreg.png (833.02 KiB) Viewed 5007 times


This is without any clamping. If I let it run longer, the dirreg actually starts to produce fireflies, I suppose because many near-specular interactions are evaluated.

ingenious
Posts: 273
Joined: Mon Nov 28, 2011 11:11 pm
Location: London, UK
Contact:

Re: GPU VCM

Postby ingenious » Wed Jun 15, 2016 10:46 am

jbikker wrote:If I use a radius close to the projected pixel size the number of photons arriving per pixel is going to be low, right? That would probably lead to fireflies for quite a bit longer than the first 16-32 samples, which is the time frame I'm trying to optimize for.


Indeed, this will inevitably increase the noise in vertex merging and in the entire VCM as well, because the variance of vertex merging is inversely proportional to the squared radius.

jbikker wrote:As for the improvement of directional regularization over BDPT: it's also in this small time frame; the light cast by the mirror shows considerably less noise early on.


This above is a great view point. I'd be very interested to see how pure BDPT, dirreg and VCM compare with a slightly higher number of samples (without clamping, of course)!
Image Click here. You'll thank me later.

jbikker
Posts: 175
Joined: Mon Nov 28, 2011 8:18 am
Contact:

Re: GPU VCM

Postby jbikker » Wed Jun 15, 2016 11:46 am

Here you go:

VCM, ~4spp: Image
VCM, ~32spp: Image
VCM, converged: Image

BDPT, ~4spp: Image
BDPT, ~32spp: Image
BDPT, converged: Image

dirreg, ~8spp: Image
dirreg, ~32spp: Image
dirreg, converged: Image

VCM versus BDPT, raw difference:
Image

dirreg versus BDPT, raw difference:
Image

Sample counts are approximate.

ingenious
Posts: 273
Joined: Mon Nov 28, 2011 11:11 pm
Location: London, UK
Contact:

Re: GPU VCM

Postby ingenious » Wed Jun 15, 2016 12:08 pm

Thanks, very interesting!
Image Click here. You'll thank me later.

jbikker
Posts: 175
Joined: Mon Nov 28, 2011 8:18 am
Contact:

Re: GPU VCM

Postby jbikker » Wed Jul 06, 2016 7:55 pm

Made some progress:



Full quality video: http://www.cs.uu.nl/docs/vakken/magr/ma ... efront.avi

To be able to use BVHs instead of the hardcoded scene, I implemented wavefront path tracing. Took some time to get it efficient (and working ;) ), but right now for the hardcoded scene the impact is ~40% which seems reasonable considering the massive I/O to global memory. Benefit of this approach is obviously that occupancy is restored to 100% due to compaction at several points, most notably before BVH traversal starts.

Next step is getting rid of the remaining hardcoded scene parts.

beason
Posts: 47
Joined: Sat Dec 10, 2011 1:58 am
Location: Los Angeles, CA

Re: GPU VCM

Postby beason » Wed Jul 06, 2016 9:21 pm

Very nice! 500m rays/sec is fast.


Return to “Visuals”

Who is online

Users browsing this forum: No registered users and 1 guest