Realtime Graphics / Game Engines

[Darren S]

I feel like I've just been schooled.... 😁

Good post mate! I even followed the vast majority of it.

 

[SharkyUK]

I feel like I've just been schooled.... 😁

Good post mate! I even followed the vast majority of it.

It's easy when you know how... 🫣 🤥
(I haven't got a bl00dy clue!)

 

[SharkyUK]

 

[SharkyUK]

I haven't touched my path tracing project for a while and decided to upgrade it to use the latest version of CUDA this evening. It didn't work out so well, so it's now going to be a job for another time! 🤣 However, I did make a few tweaks and improvements in readiness for the forthcoming 50xx series GPU from nVidia and I'm looking forward to getting my hands on one or two of those. There are also one or two features that I want to introduce into the renderer to see if I can get them running in real-time and without too much of a hit on performance.

I've not got much to show and the changes I have made won't show up that well in the generated imagery, but here are a few more renders for shizzles and giggles.

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

 

[SharkyUK]

And some real-time Lego renders, because fun. 🤣

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

SIPT2 Render by Andy Eder, on Flickr

 

[SharkyUK]

I decided to spend a couple of days fixing some long-standing bugs with my path tracer. The main culprit has been causing me headaches for a couple of years now and has been a b!tch to debug. I found it after a 14 hour debugging session. I was using variable "nl" when I should have been using "n". But had only made this error in one place in the code. Every other occurrence was fine.

Feeling a bit happier now it has been fixed.

This first image was rendered using Blender (Cycles render engine) - which I use as a benchmark for my own stuff.

(Blender)

And this next image was rendered using SIPT2 - my real time path tracer...

(SIPT2)

I'm quite happy with that.

A few more random renders for good measure.

 

[Darren S]

As always - very impressive stuff that my brain would probably comprehend 1% of!

 

[SharkyUK]

As always - very impressive stuff that my brain would probably comprehend 1% of!

You'd have spotted the bug straight away, mate. It's quite obvious when you think about it. When calculating a ray's path at the interface between different materials (involving dielectrics - which are non-conducting and transparent and can both reflect and refract a light ray), and assuming the ray does not end up in total internal reflection, when calculating the probability of of either generating a reflection or transmission/refraction ray, you need to use the underlying geometry's raw normal. I was using a corrected normal based on microfacet theory by mistake. The corrected normal for microfacets should be used for shading and calculations in general, but not when it comes to deciding if the ray should be reflected or refracted. It messes up the probability distribution, adversely affects light radiance weighting, and breaks the law of energy conservation. And can muck up the rendering. The issue was that the messed up render is not too dissimilar to a physically correct render, hence why I kept missing the issue. Piece of cake, y'see.

 

[Matt Cup]

You'd have spotted the bug straight away, mate. It's quite obvious when you think about it. When calculating a ray's path at the interface between different materials (involving dielectrics - which are non-conducting and transparent and can both reflect and refract a light ray), and assuming the ray does not end up in total internal reflection, when calculating the probability of of either generating a reflection or transmission/refraction ray, you need to use the underlying geometry's raw normal. I was using a corrected normal based on microfacet theory by mistake. The corrected normal for microfacets should be used for shading and calculations in general, but not when it comes to deciding if the ray should be reflected or refracted. It messes up the probability distribution, adversely affects light radiance weighting, and breaks the law of energy conservation. And can muck up the rendering. The issue was that the messed up render is not too dissimilar to a physically correct render, hence why I kept missing the issue. Piece of cake, y'see.

Indubitably!

 

[SharkyUK]

With plenty of time on my hands, I've been updating and reworking a few bits on my path tracer project, as well ass adding a few new features.

The under-the-hood stuff for the path tracer operates in linear RGB HDR (high dynamic range) space (it's not spectral yet, but that's a HUGE rewrite). At some point, for display on regular display devices or saving to non-HDR file formats, the HDR image needs to be transformed (tone mapped) to LDR (low dynamic range). This can be quite a tricky process as you have to try and preserve image detail in dark areas as well as excessively bright areas, and then somehow map those extreme colour intensities in to a [0,1] range (or [0,255]) RGB.

TLDR; take the rendered image from the software and make it displayable on HDR and regular display devices by dicking around with the colour range.

This is done through a process called tone mapping. In the past, I used a naïve Reinhard Luminance tone mapper (or simply cut any values off that fell out of the [0,1] range. This didn't produce the best results. So, I decided to pick a few different tone mappers and implement them.

Implemented ACES (which gives a nice punchy look), AgX (which is more realistic and probably the best one for use in a render + vfx + post-production workflow), and in improved Reinhard.

Probably not the best 3D scene to show the differences, although they can be observed in the image below.

I also decided to rework my post-process bloom effect as I wasn't happy with my old version. It's a lot quicker now, and produces much better results. It is not physically realistic (far too expensive for a real time renderer) but it does the job and is user-controllable.

I also added a reworked "sheen". It's based on "Practical Multiple-Scattering Sheen Using Linearly Transformed Cosines" (Zeltner, Burley, and Chiang, SIGGRAPH 2022) that introduces a method for real-time, physically-based rendering of fuzzy or dusty materials. It models sheen as a volumetric layer containing fiber-like particles (using the SGGX distribution) and approximates the resulting multiple scattering using an LTC fit, replacing expensive simulation. Good for clothing and things like velvet. Quite happy how this turned out.

In addition, I reworked my transmission code that models light passing through a surface for things like curtains, or strong sunlight shining through leaves. Good for backlighting! Here is an example of a bright light under a piece of fabric.

And a bright light shining through stained glass:

Another area to update was the coat (clearcoat) processing; this is good for adding a gloss/lacquer layer on top of an existing surface/material. For example, the lacquer layer over car paint, or even moisture/wetness on skin. Or varnish on wood. That sort of thing. I gave the McLaren in the image below a dull Papaya Orange paint layer with high roughness - which meant it appeared diffuse with no highlights - matte orange if you like. I then applied the coat on top which simulates the lacquer clear coat, and suddenly the paintwork has reflections and gloss as you would expect to find in the real world.

A woman:

A sweaty woman:

Bored yet?

 

[SharkyUK]

A few more random images from the latest version of the project...

Ta muchly.

 

[charltjr]

Yes yes, but when are we going to get photorealistic real time AI p**n women? Chop chop man.

 

[SharkyUK]

Yes yes, but when are we going to get photorealistic real time AI p**n women? Chop chop man.

It's the best I can do for now. Will try harder. Promise.