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!