Not too shabby, I suppose.

(Although, since SDS paths are not rendered, parts are missing. I.e. in lower row, areas behind the glass. And top right, the beam behind the glass.)

Statistics: Posted by dawelter — Tue Apr 24, 2018 8:49 pm

]]>

I'm trying to understand Veach's derivation of the adjoint of the specular refractive BTDF. It seems I hit a brick wall. Some of that stuff looks like black magic to me. Specifically, there is a relation for differential solid angle on the following page:

What is the underlined term in 5.3 mathematically? What confuses me is that there is a dsigma in both nominator and denominator. So it is unlike a regular derivative nor a Radon-Nikodym derivative?

Further down, we have Eq (5.4). Same thing. I read dsigma as a small patch of solid angle, which is determined by the spherical parameterization (*). So if (*) holds true, then how comes that for different values of (theta, phi) there is mysteriously a ratio of eta_i / eta_t appearing. Sure I get that Veach simply plugged in Snell's law in (*). But I don't get the meaning of it.

I should add that my knowledge of measure theory is practically non existent.

Statistics: Posted by dawelter — Mon Apr 23, 2018 6:33 am

]]>

Actually there was a bug. I wrongly assumed that pdfs for BSDF sampling are symmetric which they are clearly not. p(wi,wo) = p(wo,wi)? No! no! Ah well, how does one say, assumptions are the mother of all f'ups. I finally realized my mistake when ...

I implemented statistical tests (chi-sqr and t-test) for my scatter functions in the style of PBRT and Nori. I found it quite tricky. Because the chance to have at least one false alarm grows quickly with the number of tests. On the other hand, if the threshold for the p-value is made too low one runs the risk of false negatives. My solution is to change the RNG seed rather than lowering the p-value.

Still have trouble with the microfacet BSDF. I get bad number of samples at the edge of a bin where incidentally wi*h = wo*h = 0. At that place the pdf also seems to diverge because of a 1/|wi*h| term. I'm unsure if bug or not. Probably not. The material looks okay ...

Statistics: Posted by dawelter — Fri Apr 20, 2018 7:44 am

]]>

Statistics: Posted by beason — Wed Apr 18, 2018 1:07 am

]]>

I'm also skeptical about rasterization part, it calculates direct visibility with rasterization and then does ray tracing, but I guess it need good occlusion culling to avoid ray tracing of invisible shading points because that might kill all the performance benefits you get from rasterization.

Statistics: Posted by koiava — Mon Mar 26, 2018 11:51 am

]]>

Statistics: Posted by jbikker — Sat Mar 24, 2018 12:46 pm

]]>

Modelled in Stud.io and Cinema 4D.

677761 Triangles, most of them occluded due to the bricks being stuck in each other.

8700 SPP in 34 h

The scene is contained in a box with a scattering medium, obviously. Fireflys due to SDS paths? I'm not sure, but I suppose there can be paths from camera to mirror to volume scattering to mirror to sun. The sun spans a small solid angle, so there is a non-zero chance to hit it with a "forward path" like that and it would be the only technique in Veach's sense to generate the path. Makes sense?

There is also some sort of "light leak" on the first mirror.

EDIT: Hm .. after some testing the strange "leak" appears to be no bug after all. I'll write it off as caustic cast by the mirror behind the one with the "leak".

Here is another shot. Moved the rear mirror a bit to see more of the caustics. Tuned down brightness. Converges and looks like normal illumination.

Statistics: Posted by dawelter — Sat Mar 24, 2018 8:38 am

]]>

Most demos show only rigid motion, but deformation works well too. Here's an example with skinned characters: https://www.youtube.com/watch?time_continue=1&v=tjf-1BxpR9c (sorry for the music )

In the demos that used multiple GPUs, we don't actually get a full 3-4x scaling, just because of the way the engines distribute their work (it's all explicitly app-controlled in DX12). So yes while we threw as much hardware at it as we could for the GDC runs, perf on a single GPU is only 2-2.5x slower than what you see in the videos. And some demos (Remedy, Futuremark) don't use multi-GPU at all.

Statistics: Posted by martin — Sat Mar 24, 2018 2:40 am

]]>

Isn't this implemented in PBRT?

Hm, I quickly started implementing this for absorption only material and the results where even more noisy than spectral tracking (with history and no emission), which discourages me from going further in that direction.

Instead of this pdf you could probably mix the modified pdfs that "force" samples to lie within a given distance.

I think that is basically what closed-form tracking does.

Code:

`float3 closed_form_tracking(const Ray& ray, float3& transmittance) {`

const float d = ray.max_t - ray.min_t;

const float3 sigma_a = material.absorption();

const float3 sigma_s = material.scattering();

const float3 sigma_t = sigma_a + sigma_s;

const float3 tr = math::exp(-d * sigma_t);

const float r = rng_.random_float();

const float scatter_distance = -std::log(1.f - r * (1.f - math::average(tr))) / math::average(sigma_t);

const float3 p = ray.point(ray.min_t + scatter_distance);

const float3 l = direct_light(ray, p);

const float3 scattering_albedo = sigma_s / sigma_t;

transmittance = tr;

return l * (1.f - tr) * scattering_albedo;

}

I guess it is possible to come up with a weight to fix the amount of inscattered light. But I suspect that the way in which scatter_distance is calculated has to be adjusted as well.

Statistics: Posted by b_old — Fri Mar 23, 2018 11:02 am

]]>

And yet, we have changed.

I'm excited to hear that developers can now add some RT on the top of their rasterization via a standard api and that GPUs will be supporting it more and more in the future with special hw. Today we emulate FFP with shaders. In the future we will emulate rasterization via RT

Statistics: Posted by cignox1 — Fri Mar 23, 2018 7:59 am

]]>

so the good old times are over since years...

Statistics: Posted by mpeterson — Thu Mar 22, 2018 3:00 pm

]]>

Statistics: Posted by szellmann — Thu Mar 22, 2018 12:05 pm

]]>

- The good looking demos use 3 or 4 Titan V's.

- In all cases, it's rasterization as a basis with ray tracing effects added.

- All motion is rigid, i.e. no acceleration structure reconstruction, just a top-level BVH.

- Distribution effects are supported.

Looks like the tech relies heavily on scenes that 'play nice'. The SEED demo is rigid motion only and requires 3 Titans. It does however calculate AO and single-bounce diffuse indirect light, as well as glossy reflections. The Futuremark demo has more complex animation, but the comparison shots of 'with / without ray tracing' indicate that the dynamic character is reflected using screen space reflections; the character itself reflects static geometry and rigid motion. The Northlight demo is pure static geometry.

Any other insights or corrections?

Statistics: Posted by jbikker — Thu Mar 22, 2018 7:57 am

]]>

Do you think it is possible to modify closed-form tracking in such a way that it handles spectrally refined absorption/scattering for homogeneous media correctly?

For homogeneous media you have the analytic expression for the transmittance. So you have a lot of freedom with sampling strategies where you also have the pdf in closed form. I.e. you could make standard Monte-carlo estimators like transmission(x)*otherstuff(x)/pdf(x), x~pdf.

Using a "mixture" pdf would be a possibility perhaps: pdf(x) = pr_1*sigma_1*exp(-sigma_1*x) + pr_2*sigma_2*exp(-sigma_2*x) + ..., where pr_i are the probabilities to select the i-th wavelength for sampling. IIRC this is a special case of MIS weighting. Not quite the usual delta tracking. But still.

Isn't this implemented in PBRT? ... Yeah ... https://github.com/mmp/pbrt-v3/blob/mas ... eneous.cpp

Instead of this pdf you could probably mix the modified pdfs that "force" samples to lie within a given distance. Good for very thin media.

Statistics: Posted by dawelter — Wed Mar 21, 2018 1:26 pm

]]>

I actually wonder how you get your reference image so clear with jut 16 spp.

In this case I used closed-form tracking as described in the volume rendering course. (I think this is valid even for spectrally refined media, as long as there is no scattering. More on that below.)

Try the weighting scheme from "5.1.2 Incorporating Path History". It should reduce the noise somewhat.

Indeed. Massive difference!

"5.1.3 Reduced Termination Rates" also works well for me, but it is only suitable for non-emissive media.(This is not yet included in the images further down)

I spot one error:

- t is updated before calling direct_light. But p still points to the previous interaction point.

Excellent find! I introduced this error recently by shuffling around some things and did not even consider it anymore.

After fixing this problem the results actually already look very promising. Isn't the transmittance along the ray handled by probabilities already? The delta tracking as described in the volume rendering course also doesn't need this. There you multiply the incoming light by the scattering albedo. But this doesn't seem to be necessary in spectral tracking because of the weights?!

Anyway, here are some new images (16 samples per pixel across all schemes) and thoughts:

Spectrally refined absorption and scattering. The spectral tracking seems to converge to the same result as the ray marched reference. Closed-form tracking is slightly off.

Spectrally refined absorption with zero scattering. All three schemes seem to converge to the same result. Closed-form tracking converges much faster than spectral tracking. (Judging from my experiments, spectrally refined absorption with gray scattering will also be handled incorrectly by closed-form tracking)

Do you think it is possible to modify closed-form tracking in such a way that it handles spectrally refined absorption/scattering for homogeneous media correctly? Or would you end up at spectral scattering anyway, because of the null collision thing we talked about earlier?

Statistics: Posted by b_old — Mon Mar 19, 2018 10:53 am

]]>