Digital Foundry Article Technical Discussion [2021]
- Thread starter BRiT
- Start date
- Status
ChuckeRearmed
Regular
Not to mention it is 5 times 24
Jawed
Legend
Doesn't Metro Exodus:Enhanced Edition use probes to accumulate global illumination?
It seems likely "old fashioned" techniques will live on, adapted into various ray tracing techniques.
I'm intrigued by texture space lighting driven by ray tracing. I suspect that beyond aliasing (solved with multiple samples per texel and denoising) it can drive importance sampling.
It seems likely "old fashioned" techniques will live on, adapted into various ray tracing techniques.
I'm intrigued by texture space lighting driven by ray tracing. I suspect that beyond aliasing (solved with multiple samples per texel and denoising) it can drive importance sampling.
Bounces after the first one trace back from the hit Position to World space probes in the area to see if they are lit by them. First bounce is full per Pixel to other objects. The probes are drive by ray traces like those in rtxgi.
What do you mean by “to other pixels” on the first bounce. Is it a screen space trace or is it doing one reflection bounce into the BVH before tracing into the probe grid. If it’s the latter then it’s not really to other pixels.
The grid itself of course is casting rays into the BVH and tracing recursively into itself to emulate infinite bounces and accumulating color into each probe.
phone typing - it is supposed to say objects and not pixels
What relationship / opportunity do you see from texture space shading and importance sampling?
I see a potential TSS advantage for denoising (if we can resolve all adjacent texture which is close in world space, but not in texture space), but it wont affect IS at all?
@Dictator
Nice video, but few things that bug me:
The illustration of the red rock doing color bleeding to the white floor is pretty bad. Making white red means to subtract lighting instead adding it, so making it darker. It would have worked to show a grey floor which becomes brighter and reddish.
What really feels wrong to me is the constant saying 'rays model how light behaves', or something similar. We hear this really everywhere currently, but it's not how it works. And if you later say 'rasterization has no knowledge about global relationships of scene or lights', the comparison becomes pretty much wrong.
We could say 'tracing a ray gives us the same result than rasterizing a 1x1 pixel framebuffer'. This is true, and because of that, we can not say RT includes a better model of scene or lighting. In fact we solve this with other methods like shading, but that's independent from RT or rasterization.
RT or rasterization both just solve for visibility and nothing else, and both give the same result. The difference is only about efficiency, so it's an implementation detail, which won't help us to understand what GI is or how it works.
I personal favorite explanation of GI utilizes image based lighting instead. I call it the 'mirror ball example':
Imagine we want to solve for the lit surface color of a point on the floor.
To do so, we cut a small mirror ball in two half spheres, and put it on the floor:
(image has a full sphere, but example works regardless - only the half we are interested in shows up in our photo...)
Then we make a photo of the mirror ball. We align the camera to be exactly above the ball, and it should point exactly downwards, in line with the surface normal. (We also try to limit perspective projection and make our image as orthogonal as possible, so we keep the camera distant)
After that we sum up all pixels colors from the photo and divide by their number. But only the pixels which are on the mirror ball. We ignore any background like the floor in the image.
Then we multiply the resulting average color (irradiance at our shading point) with the color of the floor and finally get the correct lit color (irradiance). Done.
Notice: This result is ground truth. A path tracer with 100 bounces and 10000spp would give us a very good approximation of that.
The example also allows to derive ALL math we need to write a working GI algorithm. No further explanations are necessary at all (within assumption all materials are simply diffuse *).
So the example is nice to form a mental image and understanding to a layman, but also keeps my primary reference for development.
To explain the limitation of 'direct lighting only', you could just tint all pixels in teh photo black, so only the lamp remains visible. Doing the summation again we would get a darker color missing all indirect lighting.
It also includes explanations of how penumbras in area shadows form, or even hints us of how to do importance sampling, which we just did because every pixel has a weight of 1 ans so proofs the spherical ball gives us perfect sample distribution.
I wonder why i never saw such example in text books or papers. I came up with it after adding spherical environment maps to my GI algorithm to model specular. And only after that i realized how simple lighting actually is
*) We can extend the example to model complex materials as well:
We already modeled perfect diffuse materials, which often is all we expect from GI solutions for games.
We can also do a perfect mirror, by just looking up the single pixel we get from the reflection vector.
We can also model any BRDF. Naively we could sample a cone to model blurry reflections of rough materials. But at this point it stops to be simple, unfortunately. Material shading will remain active research topic forever i guess.
... hope it makes sense and may be inspiring. And i guess i had posted this already some time back.
Sure you can imagine each ray being cast in RT is the same as rasterizing a 1x1 framebuffer with the camera at the ray origin. That would only require processing scene geometry a few million times
I'm sure you will acknowledge that this is nonsensical from any practical point of view. The standard explanation used by DF is perfectly fine - RT involves casting a ray into 3-dimensional world space while rasterization is a 2D projection of the scene onto a fixed camera viewport. On the other hand I find your mirror ball example not representative at all of how an actual GI implementation would work in practice.
Rasterization works under a few assumptions which are all about efficiency, it's good for rasterizing large triangles onto large planar surfaces, that's it.
It doesn't make a lot of sense to use it even for the rasterization of subpixel geometry (because it won't be able to beat RT here), not speaking of emulating secondary rays by projecting objects on triangles which is simply insane, so no, they don't solve the same problems because rasterization is a limited special case of RT that is good for large triangles and large planar surfaces, but is bad for stochastic sampling and subpixel geometry and everything else.
Last edited:
I would not say it's so efficient for that either, because basic rasterization lacks hidden surface removal. If depth complexity of the scene is high enough, heavy overdraw would make it slower than RT using acceleration structure. To add one more assumption.
My preferred assumption is: Raster is fast if we generate a image from a pinhole camera. But if we want to check visibility from different locations than just one, RT is likely the better idea.
To get subpixel detail form rasterization you would just increase frame buffer resolution and downscale. The pinhole advantage is still there, so likely it would still beat RT with primary rays for the same count of samples.
But that's implementation details, and exactly the stuff which won't help laymans to understand GI. Thinking of a single ray, showing a shadow ray to a light, showing a random reflection on hitpoint for indirect...
It's just a bad model to educate, because it completely misses the most important , which is integration of many samples. To fix that, we would start to explain monte carlo integration, and then people already throw would eggs at us claiming 'using randomness can't work, you liars!'
And that's why i bring up this IBL example. I do not propose to solve reflections using dynamic IBL in practice - it is just a nice and complete mental model of the problem. How we solve best in it practice is another question.
Read the many LODs paper for an example of doing just that, and surprise - it works.
Many LODs paper again would be an example of this being practical.That would only require processing scene geometry a few million times
But ofc. i don't mean we want to replace all RT with rasterization. I only said RT in principle does not give us more information than rasterization, and is not coupled to how light diffuses in all directions in reality, while RT or raster only allow us to do point sampling of such signal.
Thus an explanation of GI using some rays is incomplete an leaves the watcher with only a rough idea of how this and some magic might actually work to solve a loosely defined problem.
Agree, rendering at larger resolutions would certainly help (HW rasterization particularly), but what would be the benefits of downscaling the larger frame buffer without shading it in the higher resolution space?
Shading the additional pixels would have large negative performance implications (even if these are only samples on edges, i.e. MSAA style) and filling in higher res frame buffer would require more bandwidth (not good either) even if processing time is the same in the higher resolution.
Agree, explaining the monte carlo integration would be perfect, but this might be a tough content for a wide audience.
Unfortunately, there are always simplifications and sacrifices to be made so that material is reachable for a wide audience.
Oh, so you had some adaptive method in mind, like using RT to do AA only where needed. Agree then.
Assuming Moores Law can be kept upright and practical, i would hope the applications where raster is faster (so just the primary framebuffer) become so small in relation ROPs are no longer worth it and can be removed. Would simplify some things. And i'd like some fish eye for high fov but low distortion
But currently i'm afraid it's wishful thinking, and low power seems much more attractive than high end at the moment. Seems big ray budgets remain out of reach for quite some time. :/
That's something you can already try in Quake RTX for example since primary visibility is done with RT there.
I tryed cylindrical projection on curved 32 to 9 monitor and it looked great at 27 FOV, lol (for orthographic projection without distortion on cylindrical surface)
Would be awesome to properly scan the monitor surfaces and fit projection to them. "Especially if one would track viewer and create the 'window' effect."
Jawed
Legend
I view this as being able to drive IS via camera-to-texel distance. Informs sample density and bounce count.
- Status
Similar threads
