Krzysztof Narkowicz

Engineering Fellow at Epic Game. I love games, graphics and lighting.

[Krzysztof Narkowicz @knarkowicz]

Together with @EpicShaders and @_pmkelly we are doing an in-depth talk on Lumen at #rtadvances. We'll cover (virtually) how we trace rays, reuse computations, solve the whole indirect lighting path and noise, and scaled all of this to "The Matrix Awakens".
https://t.co/eH9ve1uoHf

[Krzysztof Narkowicz @knarkowicz]

It’s early days. Lots of ideas on P4 shelves, algorithms to try and work left. Not ready yet to talk about tech details. Still, officially the cat is out of the bag, so it’s time to buckle up and deliver on the promise. Can't wait to see the first games shipping with this tech.

[Krzysztof Narkowicz @knarkowicz]

MegaLights release took me a bit by surprise. It was just a small prototype on a backburner, not planned to be showcased in UE 5.5. Now trying to catch up after the demo push, starting from writing the official docs which just went online: https://t.co/owM0S7al5V

[Krzysztof Narkowicz @knarkowicz]

2 months ago there was this crazy idea - could we dogfood the latest prototype using a demo and shape it into an experimental feature? It was quite a ride, but thanks to @TiagoCostaV joining MegaLights, help from other engineers and an amazing art team we made it.

[Krzysztof Narkowicz @knarkowicz]

@rianflo You can bake meshes into per mesh SDF with mips for LOD. Merge mesh SDF into clusters or global clipmaps for HLOD. Works reasonably well in UE, simpler than fitting analytical shapes to geo and provides a bound approx error.

[Krzysztof Narkowicz @knarkowicz]

@robcupisz It sounds like you did spend a lot of time investigating details like this one, and no wonder given the result. Thank you for the detailed explanation!

[Krzysztof Narkowicz @knarkowicz]

@volodXYZ @DylserX It's still in the research phase of finding the best solution (best tradeoffs for our use cases) and things may change, but at the moment there's no ReSTIR in MegaLights.

[Krzysztof Narkowicz @knarkowicz]

@HinodeCoder Yeah, GI is a rabbit hole. This is what I do at work for the last few years. But it's a fun one and produces nice pictures :)

[Krzysztof Narkowicz @knarkowicz]

@rms80 @ChristerEricson @tom_forsyth So while I understand your point, IMO instead of a worse technical solution the root cause needs to be fixed - tear down the barriers between specialized teams. As more engine code gets moved to the GPU side other teams need to be able to work on that too.

[Krzysztof Narkowicz @knarkowicz]

@rms80 @ChristerEricson @tom_forsyth It's a larger effort to maintain a CPU picker: build and stream in-editor only highres CPU geo, fast packet ray tracing to support drag/fuzzy select, emulate GPU code on CPU for alpha masking and vertex anim (and BVH for animated forest may not even fit in memory anyway)...

[Krzysztof Narkowicz @knarkowicz]

@rms80 @ChristerEricson @tom_forsyth I see. Still for cycling you could skip drawing previously selected objects or write out a full list of objects for a given pixel/region with their depths. BTW we had cycling in my prev job as a temp workaround for poor CPU picking precision before we switched to GPU picking.

[Krzysztof Narkowicz @knarkowicz]

@zeuxcg @meuns @sergei_am I think it's fair to say that we solved the top-most translucent layer :)

[Krzysztof Narkowicz @knarkowicz]

@rms80 @ChristerEricson @tom_forsyth In my prev job we started the engine from CPU picking by reusing physics code. Turned out to be a mistake, as you can't get robust selection due to the approx CPU geo, approx sorting (no zbuffer) and no fuzzy selection counting pixels. Switched to GPU later.

[Krzysztof Narkowicz @knarkowicz]

@DylserX AFAIK hit-lighting and path tracer work on Linux in ue5-main, so you may want to give it another try :)

[Krzysztof Narkowicz @knarkowicz]

@KostasAAA @Peter_shirley Interesting prediction that "baking will always be with us", when it feels like the entire industry is moving away from it.

[Krzysztof Narkowicz @knarkowicz]

@castano @guycalledfrank From what I remember general idea was based on your paper and I'm not a compression expert, so it will be interesting to see how you improve all of this in Spark.

[Krzysztof Narkowicz @knarkowicz]

@castano @guycalledfrank It was years ago... It's min/max line + least squares + some tricks to get "free" compression on prev gen. Partition mode is slower, but should be fine on current HW, though likely not a good tradeoff. Various AA/AAA games shipped with it for real-time probes, so it does its job.