No, but lumen will scale and perform better. Megalights already improves performance and makes lumen more usable for interiors, IMO.
They did do that, yes, but reSTIR is not pathtracing. ReSTIR is a lighting integration method that can choke down an enormous number of lights, far more than lumen can currently support, which means the lighting approximation is more accurate.
All reSTIR is, is an algorithm that tells the renderer how to choose which lights will contribute to a given pixel or probe. It works in path-tracing, lumen, and basically any problem that boils down to stochastic selection.
That said, ReSTIR is also the algorithm that makes Nvidia’s real-time path-tracing possible, because without it, it would take way too long to get clean data to light a scene.
*This is where I am kinda mad at Nvidia, because they turned an algorithm into a brand.
So, the emissive material thing is strictly about how you’re able to sample a scene around you. Most lights in games are punctual, meaning they’re not made out of geometry, but out of equations that create shapes like cones and points and planes. The engine knows where they are at all times, so it’s super easy to send rays their way to trace. Emissive materials take more processing power to solve correctly because the engine has to guess at where they are in space to light them (rather than just knowing beforehand with punctual lights). Lumen can do the exact same thing.
Megalights can handle 1000s of moving lights too. Attenuation radius is too complicated a subject to get into.
I can guarantee it produces noise. It’s impossible for it to not produce noise, because the core of the algorithm is just taking a guess at lighting; when that guess is wrong, it’s noise.
Anyways, ‘realtime path tracing’ as Nvidia brands it performs definitively worse than lumen. It’s simpler algorithmically, and it can scale up to higher quality, but it can’t run better in like-for-like scenarios, or at least I would be truly stunned if it did.
restir is more lumen then megalights. but… yes… for any given pixel you gotta limit the amount of lights that are accumulated.
also… emissive materials are expensive cause you hit a surface pixel, detect that it’s emissive and have to gather more data/samples about the surrounding world. means… creating more rays to fire. that’s why emissives are rather expensive or noisy, cause you can’t shoot all the rays. or you’d get the polygon id. and track in which bvh clusters it’s also in and get the spread. this is pretty nuts tho. in the end all you need is the center of the polygon and some ray cones or an approximate probe and hack the spread to look good.
I have a GTX 1080 and was running the preview build without seeing this message, but in the release I’m getting this. Any ideas?
Here’s what the log says:
LogD3D12RHI: Ray tracing is disabled because D3D12 ray tracing tier 1.1 is required but only tier 1.0 is supported.
LogRendererCore: Ray tracing is disabled. Reason: not supported by current RHI.
LogUObjectArray: 43521 objects as part of root set at end of initial load.
LogUObjectArray: CloseDisregardForGC: 0/0 objects in disregard for GC pool
LogNNEDenoiser: Ray Tracing is not enabled, therefore NNEDenoiser is not registered!
EDIT: Seems the command “r.MegaLights.SoftwareRayTracing.Allow 1” fixes this. Now I can use it with a 1000 series.
2 Likes
Your card supports simulation of HWRT without actual HWRT hardware= that’s what the message is saying, and why you’re having the issues.
1 Like
you need atleast a 20 series nvidia or 7000 series amd gpu to get hardware acceleration for raytracing.
in your case it will fall back to screen tracing and distance fields. it’s not bad, but you gotta author your game graphics around this hardware limitation on your end. ez? ez, yep. lil hacks.
1 Like
Hi, as I understand, the default Megalights is visually the same as having lights casting raytraced shadows, only it is way more optimal internally on how it handles multiple lights.
This means that shadow casting on nanite objects won’t be precise unless the fallback resolution is tweaked to be more similar to the nanite mesh. No problem there since it is how I have worked until now.
However, since nanite tesselation was introduced, I was expecting light improvements to move in a direction that would make nanite tesselation usable and properly integrated in the light system. Megalights’ default shadows won’t cast any self shadow of tesselated forms, the same would happen with the newly anounced real time path tracer. With nanite coming to characters, and tesselation being such an important part of workflows, is there any plan to integrate tesselation in the shadow system? At least some way of baking tesselated detail into a lower ress fallback so it can have some self shadowing.
As if it is now, having teselated detail on a plane only cast shadows with vsm, it is a pitty that wanting to properly use tesselated nanite means loosing raytraced or real time path traced lighting and shadows. It feels like these two technologies that would tie perfectly for realistic projects are being separated into non compatible workflow.
Hope I explained myself, it’d be great to know if there are any plans of it in the future or if I should scrap again the tesselation that finally came back to us.
For what it’s worth, I have not found this to be necessary with megalights raytraced shadows, as screen traces appear to have entirely (in my case) resolved the self-shadowing issues of the original raytraced shadowing implementation.
2 Likes
Hey, thanks for the quick reply, really appreciated. The screen traces definitively help to some extent, you are right that it is a big improvement from the previous raytraced shadow iteration. Hopefully this also applies somehow for path tracing in the future, at least for the real time version. About these screen traces, obviously since they are screen space, the shadows dissappear as soon as the face projecting it is no longer visible. Same happens with some nanite mesh detail, I am guessing that this will happen with all details that differ from the fallback model, and the only way to bring shadow quality up is to change the fallback model resolution so to speak. This is not new, and it happened in the previous ray traced shadow iteration, with a different visual artifact coming from the same issue.
But for these instances we had a very handy command line " r.RayTracing.Nanite.Mode 1", this showed a very good shadow at a increased cost, without individually going through all the nanite meshes to tweak the fallback mesh. Does anyone know about a similar thing in megalights? That command line was really good, and could be added in the movie render queue so I could work with inaccurate shadows until rendertime, and then the render would apply the command to make the most accurate shadow possible.
Cheers!
The best solution is, probably, to bake the mesh as a Static Mesh (using the Modeling Tools, for example) without material tessellation anymore, as, anyway, it’s expensive. So you would gain detailed geo + RT shadows + performance.
I understand what you suggest, but at that point getting individual nanite pieces like they proposed originally “lumen in the land of nanite” is probably better since you have more artistic control. But creating dozens of high poly objects and importing them is super slow and very heavy on disk, not only in the the engine but out of it, storing gbs and gbs of highpoly fbx and zbrush files… Tesselation let’s you create more simple assets, less disk space and still have models that look high poly enough, with the poly displacement matching the rest of textures, and of course the benefit in ressolution of tiled textures. Processing individually all tesselated objects is a bit against the timesaving workflow of tesselation.
I am talking from a cinematic perspective, I am more into cinematic development than actual optimized realtime development. Tesselation displacement is the most similar tech to displacement in offline renderers, but I see that all the stuff that has been built with nanite is being less and less compatible with the new lighting tech, and the solutions like screen traced shadows are better than nothing, but the visual artifacts created in a moving camera on anything that is strongly enough tesselated are quite obvious. That is why I wonder if this is something that will be considered in the future or if we are getting further and further away from original nanite plans.
I would love if self shadow would just use VSM instead, the shadows are stable, even if most costly. But of course I don’t want to select VSM in megalight shadows because the full scene will look worse just to fix tesselation self shadow. Is there a way to just change screen trace shadows for vsm without changing the rest of the raytraced cast shadows?
Thanks for the suggestion anyway, I just hope I don’t need to resort to that, it is hundreds of hours on the long run.
Sorry, I didn’t mean to high-poly it in external softwares, but inside Unreal. If I’m not wrong, you can tessellate your mesh with a heightmap, as usual, but after that you can convert it in real ‘baked’ geometry, without the need to use tessellation anymore. I think this won’t get more space, memory nor resources than dynamic tessellation.
Yeah, I know what you meant, but I still think for a full environment this is quite tedious and kind of destructive pipeline. Tesselation in material allows for fast iteration and it is non destructive since it is almost procedural as per workflow goes. You also have the per asset nanite displaced geometry plugin, but again, it removes all the benefits that a material grants, since you input a texture file, not even a node you can modify. And even if this is very secondary for me, since is not how I plan to use it, nanite tesselation allows for animated surface deformation in an easy and cool way if you are not a programmer. For us coming to unreal from vfx industry, UE is just so close to perfect, but these tiny things… it is so close but not there yet, these confronting pipelines are a bit hard for us to tackle hahaha. Anyway, it will come, in the meanwhile I am just looking for these hidden checkboxes and commands, to find the most cinematic but flexible approach.
Hello
It seems like lighting channels don’t work with megalights
TextRenderActors always cast shadows even if CastShadow option is disabled and casted shadows don’t always look right (screenshots)
If you disable CastShadow on a mesh and place it close to the wall and fly to the place where the disabled shadow should have been there will be artifacts (screenshot)
Hey, not sure if this is the right place for this, but I have been experimenting in 5.5 and found that enabling MegaLights causes this crash:
Fatal error: [File:D:\build++UE5\Sync\Engine\Source\Runtime\RenderCore\Private\RenderingThread.cpp] [Line: 863]
Rendering thread exception:
Assertion failed: View.SubstrateViewData.SubstrateGlobalUniformParameters != nullptr || !IsSubstrateEnabled() [File:D:\build++UE5\Sync\Engine\Source\Runtime\Renderer\Private\Substrate\Substrate.cpp] [Line: 704]
This occurs during shader compilation, and I haven’t been able to narrow it down beyond it only happening when you activate MegaLights, as I mentioned.
Keep in mind that SWRT path has pretty bad quality at this point, this is why we have hidden it behind r.MegaLights.SoftwareRayTracing.Allow.
Yes, that’s something we will have to tackle at some point. Unfortunately most ray tracing bits are either inside hardware or driver, so proper solutions take a long time. For now we could bake a better RT proxy indeed.
It’s fixed in UE5-Main, but didn’t make it to 5.5.
If this is with Substrate enabled, then you should post in the Substrate thread. Guys responsible for it are quite responsive and helpful.
For sure. Is it possible that it’ll be improved?
i only tested it in one shot (which was foliage under a screen of 4 huge rect lights), but i guess you can author your assets to improve it. you need clean distance fields that can be traced against. it should work for not too many lights aka an ambient scene. the screenspace trace transition will always be visible tho. hmm
In which version we may see mega lights work on Mobile also.