Not everyone has/wants one but people like to be in the loop. Besides their productboard hasn’t been updated in months; systems like stochastic shadows haven’t been promoted anywhere I’ve seen, despite them being a potential game changer. Just making people aware of things.
And on a second lookthrough SampledDirectLighting looks like a rename of most of the stochastic shadows files with a few additions I’ll look at at some point. I’d assume by the name that it’s tackling direct lighting fully but obviously seeing a lot of active development.
yeh. i have one. i had to deliver a lil jab tho. i’d like some hands on with the tech, for testing. but i couldn’t get the editor to build, last time i tried. i’m aware it’s in development, but a stable marker should be somewhere. where is it tho? hmm
A bit late on this but this is an interesting technique, I wonder if there’d be some way to segregate the lighting process for emissives so they’d be able to use something like this? Or perhaps, reminding me of this paper I saw from a year ago, Clustered Voxel Global Illumination, It’s a very interesting paper and I was wondering if Lumen were doing anything similar, and if it weren’t, I wonder if it could be feasible as emissives replacement? I know a lot of the emissive properties I’ve been seeing are actually kinda similar to that old Nvidia VXGI thing from years ago, same with the area light functionality, so I’m sure there could be some overlap. If anything, I’m sure someone could make a plug-in for either of these techniques and we could see how they’d be able to compare!
Honestly I would ignore this dude when he says junk like that, he may not be as annoying as that other guy but he’s hostile for no real reason, don’t give him the time of day lol, you posting github snippets has been a big help as I don’t think everyone can really access it and I’m sure not really able to commit to downloading the whole main branch just to check the new stuff out.
don’t backseat. try the front seat. and yes… ~300 GB is a commitment. and when it doesn’t compile at the time, you’re kinda done. i’m still working in stable 5.3.2 and doing fine and trying to help others figure things out and not derail. you can eat your hostile read. /2cents
This is definitely an interesting one; I had no idea Enlighten was still around as a technology.
I feel like the presentation is a little hard to agree with if it’s making an argument that enlighten represents a better comprehensive GI solution over lumen; a cheaper dynamic GI solution would still definitely have its’ place alongside lumen, but that said:
The core reason lumen is so GPU-oriented is that CPU processing power is at a premium in the current software and hardware architecture paradigm- the more you can do on the GPU is usually better for performance, especially given how few thread-limited UE can be.
They don’t seem to mention at all that, in addition to dynamic lights and materials, lumen supports dynamic geometry. None of the test scenes I saw in the video seemed to show off dynamic geometry, or emissive objects. Enlighten only supporting scenes with static geometry is a big limitation in many ways, and it doesn’t solve the fundamental problem of trying to make worlds feel more alive. Perhaps I misunderstand how the probe system works, this is just to my understanding.
Particle effects don’t look correctly lit with the scene in enlighten- could be a bug or a settings issue, but supporting correct volumetrics and lit particles in lumen is a massive advantage.
There could be a use case for enlighten in games that want to support dynamic lights but can’t pay the cost of lumen, but as engine versions roll by and lumen just gets leaner and meaner, I feel like a much bigger advantage would have to be offered by a third-party lighting solution to really offset lumen’s utility.
Yeah, it’s not perfect. I personally think it’s not doing enough to prove useful in common scenarios.
lumen supports dynamic geometry. None of the test scenes I saw in the video seemed to show off dynamic geometry, or emissive objects.
I had similar idea but it’s basically volumetric lightmaps but time interpolable for directional and skylighting with multi lighting layers (including emissive) for mobility based destructibility. I was thinking interpolation between probes containing Path Traced diffuse and reflections but using Lumen instead would probably speed up the baking process.
Tested out the LoftOffice content pack for a project, and I discovered that it’s breaking lumen GI; in a radiometrically simple scene with nearby puncual lighting, there was an inordinate amount of noise. My only guess is that the high-frequency herringbone ribs on the wall are creating depth discontinuities that are stopping the screenprobegather from sharing samples spacially, but that’s only a guess:
The normals also look quite strange, but that could be the geometry itself.
In terms of real-world workflow, this herringbone geometry is almost a perfect use case for POM if the stepped effect was absolutely required, but it seemed like a problematic issue nonetheless. If you consider this inappropriate content to be @ ing you over, please let me know and I will gladly stop.
This is more a comment than anything else, but I am very excited to test out lumen and the lighting systems in general come 5.4. It seems like there has been a ton of optimization work, ranging from the broader work of thread parallelization and bindless resource support, down to more specific features like GPU instance culling for RT and the new light grid system, and new features like RT translucent shadows, SampledDirectLighting, and more. I don’t know what the actual performance delta might be 5.3-5.4, but I’m very excited to find out.
Few other features I remembered: lumen now supports translucent objects in reflections, true refraction and multiple refraction events, subsurface profile working in lumen hit lighting, better support of volumetric lighting, and better perf overviews.
If there’s anyone migrating from an offline DCC to UE, they’re going to find that lumen is competitive to an offline renderer in almost every use case, assuming use of the MRQ and cinematic settings.
If it’s not possible to play 4 players splitscreen with lumen i don’t care about 5.4’s performance ! lol By the way nobody answered my question, maybe it is already possible in 5.3 ?
Two player is now possible TMK, 4 player seems like a bad/challenging use case for lumen bc you’re already juggling a ton of extra CPU logic, and each scene would need to carry its’ own memory pools for the caches that couldn’t be overlapped.
Thank you very much for your reply !
I’m already using 2 players splitscreen in 5.1 and i’m happy with the performance, to my surprise with a gtx1060 6gb my gpu thread is around 25ms.
Lumen is so cool i can’t imagine to toggle it off. Many thanks to all the people at Epic for sharing your awsome game engine ^^
Additional bug (will report these via bug report as well) when using the instance overlap visualization mode for HWRT lumen, too-fast camera traversal has caused crashes. This has happened multiple times after engine resets, and without any warning.
That said, I’m not sure what the cause is. The crashes triggered consistently in CitySample_Small (default Wp grid enabled, no streaming), and yet I haven’t been able to trigger a crash in the Electric Dreams Demo (default Wp grid, no streaming). This is despite the CitySample having very well-managed and minimal instance overlapping, whereas electric dreams has massive amounts of overlapping geometry. Curious.
Lumen GI and Reflections don’t work on low and medium scalability settings. When I tried to enable Lumen in the editor, I couldn’t understand why it doesn’t work. The reason was that my scalability settings were on low and there is no information anywhere that it doesn’t work on low scalability settings.
It would be nice if the docs told us that we need to set scalability settings to high or epic in order for Lumen to actually work, and also the engine itself let us know that “Lumen is enabled but not really, the scalability setting is low, so it’s not active”.
question for the staff at this point: is there a plan to add atleast an approximate fog/height fog to raytraced reflections?
was just messing around with some stuff. screentraces do the trick, but they leak the foreground in water reflections, for example. i don’t like this at all. also… the cvars for raytracing heigth fog are not working.
btw… i’m impressed how well dlss manages a meager 33 % scale. lil noisy but i get to my target framerate, without roasting the hell out of the lil rig.
i gotta find another cloud display method for sure. and a baseline graphics quality is almost there. hmmhmm
