How to create a light source with a custom volumetric shape or how to make an object with emissive color cast physically accurate shadows? Here I mean correct interaction with lumen.
You must use an “Emissive Material” assigned to a mesh.
Use Noise Material
As far as I understand, such a glow will not create correct shadows for other objects in real time interacting with lumen, right?
Can you give examples?
Indeed this will be only indirect lighting (and as so achieve “correct interaction with Lumen”, which is the GI solution), but direct shadows will not be that good.
I don’t think it is possible to have an emissive material that cast direct shadows. What I’d test to approximate such effect is to use 6 rect lights located at the bounding box of the geometry. I think the result would be quite OK.
I think this is an incorrect state of affairs, a flaw. According to the logic of engine development, giving the ability to make a light source of arbitrary shape is the next stage of development. Can you tell me how I can leave a request to the developers to implement this functionality?
Unfortunately, unless you are a top-paying customer or very important studio, there is no such thing as Feature Requests in Unreal Engine… You could try to create a [Feature Request] post on the forum, but there is very few chance someone at Epic would handle it.
Apart from that, I can see why this is something not implemented actually: such feature is in reality quite complex to implement, because you need to sample light and compute shadow volume/map using all the mesh geometry, that would be quite computationally intensive for real-time application. I don’t think there is other engines that implement this in real-time.
Actually, the feature is implemented for emissive materials… in the Path Tracer render mode (which is not realtime), as well as probably with static Lightmaps. But definitively, in realtime with Lumen, this is not yet possible.
It works correctly with Lumen, as long as the material is not translucent.
I couldn’t achieve this result in real time interaction with lumen. Can you show me an example of the correct setup?
- Apply opaque emissive material to object
- Add to scene
Done.
Optional items:
- Use lumen in hardware raytracing mode for best results
- Don’t use it on small meshes if you want good results
- Enable “Emissive Light Source” on the actor to keep Lumen from culling the surface cache
1 Like
Wow, thank you so much! If it really works like this in real time and with light reflections, that’s awesome! Can you please answer a few more questions on this topic?
- You wrote that it doesn’t work with translucent materials. What’s the problem there? What other pitfalls does the technology have? What version of the engine did you use for the demo?
- Why does the engine itself only offer primitive light shapes like sphere, point, cone and square? Are there objective reasons for this? How do these light sources differ in properties from an object with an emissive material?
- Why does user GabUECV write above that this is not possible? And I myself have not found a single video tutorial on YouTube where shadows would work correctly in this scenario, maybe I am not formulating something correctly?
- Maybe you also know how to work with lighting scenarios for volumetric lightmaps technology? How to switch between different lighting scenarios not abruptly, but smoothly mixing their influence on the scene?
- As far as I unrderstand, in Unreal Engine 5.4. nanite generates fallback meshes for mobile. Maybe you know when the next version will be released and will nanite technology work fairly on mobile platforms?
In any case, I am very grateful for your time. I bow to the source of true wisdom!
I should clarify, it is the emission material that can’t be translucent. It will cast light onto other translucent materials into the scene. It actually may be possible to use translucency with hardware raytracing (I don’t recall and forgot to test, sorry), but this doesn’t work with software raytracing because translucent materials are not included in the mesh distance field representation of the scene.
It can be somewhat noisy/splotchy on small lightsources, especially in diffuse reflections.
5.4.4
Lighting from lightsource actors is computed directly (or more accurate to say, the first bounce is computed directly), rather than through numerical integration. In order to solve the incoming lighting from emissive surfaces, the engine needs to trace rays into the scene and return what it finds. This works, but it’s inefficient and can require a large number of samples which we cannot afford for realtime rendering which is why on small emissive objects the lighting can be unstable.
In a regular offline renderer you would just increase the ray count, but we can’t afford that in realtime, so we’re just sort of stuck with the noise.
I don’t know. As long as Lumen is functioning, the indirect lighting will be shadowed (except for translucent surfaces).
Lightmaps for lighting scenarios can’t be blended together unfortunately. There’s not really a lot you can do about this.
No idea if/when it Nanite will be supported on mobile but my guess is that it’s a long ways off, there’s still a lot of work to be done on feature support and performance for PC platforms.
Cool thing about unreal is you can create your own functionality for about anything, especially for those well versed in c++ and I detstand unreals documentation, also adding an emissive light to your objects material will make it glow, to cast shadows place a light component in the actor and bump up the source light radius
Am I right in understanding that lighting from emissive surfaces will be noisier than from light sources due to performance reasons?
What setting can I tweak to improve the quality or performance of the lighting calculation from emissive surfaces?
Could you please share a source where I can read more about the internal mechanisms of lighting calculation in Unreal Engine?
Yes.
There are a lot of them, the simplest to control is just increasing the Final Gather quality in the post process volume, and/or increasing the Global Illumination scalability to Cinematic. The quality can still be pushed further but you’ll need to do it by console variables. You can read all about this here: Lumen Performance Guide for Unreal Engine | Unreal Engine 5.4 Documentation | Epic Developer Community
A lot of it can only really be learned by looking at the engine code. Epic operates from the philosophy that the code is the documentation. That being said you can get a relatively high level view of how Lumen works based on the technical docs and the teams presentations at Siggraph and beyond:
This PDF is probably the most comprehensive summary of how it works:
Technical docs; much less detailed but more digestible:
Another Siggraph presentation about Lumen’s final gather:
Epic’s Livestream Presentation and Q&A about Lumen:
1 Like
Ok, I admit a mistake for me here. Realtime indirect shadows is indeed possible with emissive materials (which is a really nice job from UE engineers by the way), I thought they were only approximated.
Though, I don’t think emissive materials on complex meshes were designed to be used as the primary source of direct lighting / shadowing in a scene, as everything will be quite noisy.
Hi, I have a few more questions about emissive objects.
-
Why does the illumination from an object disappear as soon as it is behind the camera? And how can this be fixed?
-
Why is there such a strong inertia when recalculating the illumination from emissive objects? How we can speed up it?
Emissive lighting needs to be stored in the surface cache to appear offscreen, which requires precomputing card positions when the mesh is imported. Skeletal meshes can’t do this because they animate, and so they don’t have surface cache, so any emissive lighting from them will never be visible when the mesh is off screen.
Isn’t really a good way to fix this currently, a very convoluted way would be to attach static meshes to a socket on the legs, set them to hidden in game + affect indirect lighting when hidden.
The Lumen team has said they’re looking into alternative ways of generating surface cache that don’t rely on capturing from precomputed positions so this might be fixed in the distant future.
Depends on what you mean but that. Lumen gathers samples over multiple frames so there will always be some noise before it converges when surfaces are disoccluded.
Lumens surface cache is also updated on a budget, which doesn’t apply here because your emissives are skeletal meshes which don’t generate surface cache. But the way to speed the surface cache up, is to increase the lumen scene update speed in the post process volume.
1 Like