We did not change any of these settings. How can I adjust it? Adjusting the exposure would have the same effect?
Or adjust the global gamma value in the “color grading” section of the post processing volume?
I tried increasing the gamma in the post processing settings. It did get brighter, but the HDRI contribution to the GI is still missing I think.
I usually use 8 frames of engine warmup for the MRQ and I can see lumen kicking in around the 4th-5th warmup frame, lighting up the scene. In case of the panoramic renderer, I dont see this happening at all.
In these images, I can see that even outside it is not lit up properly in panoramic rendering (but it is when rendering non-panoramic images):
Maybe this one will help:
1 Like
Hi @Krzysztof.N ,
I tried these commands, unfortunately they dont improve it at all. (and the r.SkyLight.RealTimeReflectionCapture.PreExposure cVar is not showing up in the editor, I entered it anyway)
Does it work as expected when doing normal, non paronamic renders? Does it look as before in the editor viewport?
If yes, the maybe it’s related to a multiple view rendering bug, which causes some issues in VR and should be fixed in the next patch.
1 Like
Yes, it works fine with regular, non-panoramic renders. This issue arises only when creating panoramic renders. Okay, will be looking forward to it, thank you!
1 Like
hey, do you know maybe how to fix Dynamic Shadow Issue in Nanite Mesh without disabling nanite or shadows. Thanks in advance for any tip.
Disabling remove casting mountain shadow
Not a lumen problem, sorry.
1 Like
I am under the impression that using the typical masked textures for vegetation and leaves is detrimental to Lumen and Nanite. One should remodel all their assets and have fully modeled leaves.
But that might be inconvenient.
Redshift renderer has an interesting maybe unique feature, a special node in material editor - specially made for leaves - which uses the typical texture mask for leaves, and does some kind of hard cut so everything outside the mask is ignored. The performance is much increased, I think maybe in a similar way to having the leaf fully polygon like.
Can’t we do something similar in Unreal ?
you mean alpha clipping? that’s the default in unreal too.
you just delete any temporal dither nodes or the dither opacity setting in the material and set the alpha clip value as desired. you get that hard cut like that.
no clue if that increases performance. there is still tile and depth sorting involved to get occlusion and overdraw prevention to work.
Yes, but in Redshift renderer there’s a tremendous improve in performance / rendering speed. If I understand it well, it’s like the rest of leaf body is not there, just like they advice us to do with Nanite. Model the leaf so it does not need a mask.
In Redshift you can try with and without that node. Without that node the performance is bad, just like any other “normal” renderer.
I guess if in Unreal you could improve greatly the rendering speed just with a similar node, or method - like alpha clipping, someone would have found out by now.
Still, I think it could be a worthwhile idea, to try a method which would make the masked part of the leaves actually invisible to the engine. Because they say this part is one of the big problems with Lumen and Nanite.
1 Like
well… theroretically the general performance problem with alpha clipping or any texture bound technique is the render pipeline stage. it is executed in the pixel shader. means it runs for ever pixel. even overdrawn pixels. it may skip execution if there is an early “alpha out” codepath. that would be in the rasterizer stage, to skip the pixel shader code. but… usually every path is computed. using nanite you only compute the vertices, which are usually less in amount than pixels. you still compute the shading but it’s a straight line codepath without the alpha branches and stuff.
I guess what the Redshift devs did, sounds simple in theory - they just built an additional node for the material editor - which even though appears to work in the texture and shading department, it’s like the texture mask performing a “cut” on the geometry, like the mesh was virtually cut out at the mesh level.
But maybe it was not at all simple (even though you do it with a “simple” node), since other renderers like Arnold and many others do not have such a solution even many years later.
Maybe it could work similar to tessellation, modifying the actual geometry. Experts will say!
interesting idea. i think that could actually work. you’d have to sample the alpha texture in the tesselation stage to get the alpha values for the tesselated geometry. in the geometry shader you’d just omit aka not emit the triangles that are below alpha threshold. those would not be sent to the rasterizer and consequent not be pixel shaded at all. that would be a geometric cut off, indeed.
not sure about the performance. and… thinking about it… there are some complications with this approach. mainly the blending of neighboring vertex alpha for triangle clipping, vertex and execution order. and smoothing the edges. or you get just square holes.
(excuse the crude painting x)
you know?!?
3 Likes
The problem is - they advise you to build your leaves without masks, so modeled with polygons. And to leave the masks only for very low poly leaves. But not sure how realistic is that. Not because most of the models in libraries are already made with masks, but because the true contours of many leaves can be very complex. Very hard to imitate with geometry and to keep all the small details.
They say the new models from Epic or Quixel will be adjusted for Nanite, with geometry and without masks, but I wonder how precise such a leaf shape will be ?
Mmm, recently I tried to push few bushes and decorative trees to Nanite-only mode, for all its worth - even smallest branches are mesh + duplicated geometry for leaves (front side and back side are separated to have different materials on the backside). Results - visual quality was improved, but there are problems yet to be solved:
- In general procedurally generated foliage has issues with leaves and branches intersecting in non-realistic way, so for true realism there is a need for photogrammetry or maybe AI can generate non-intersecting geometry. Overall it can work very well with a lot of extra time & effort to adjust procedural generation (Plant factory 2024 is free now, with some limitations in EULA for commercial use).
- The biggest problem is that Nanite removing small leaves (5-8cm) at 10-20m distance, they just disappears. I created an ugly hack to make at least something green visible on distance (masked green blob, appearing at 15m+). Since UE 5.4 there is a way to control how aggressive Nanite will be reducing polycount for each static mesh (“Max edge length distance” parameter in mesh properties can be set to 3-2-1 or even 0.5 to make leaves stay visible longer), but performance cost is rising fast because Nanite is practically not reducing polycount of those foliage assets, so millions of polygons per tree/bush are tanking fps. And leaves will disappear anyway, just at 50+ m distance.
- As result performance cost is tremendous, especially if those trees/bushes are near the glass and high quality Lumen reflections are enabled (my mobile RTX 3070 drops to 20fps in those situations). I didn’t even tried to make wind animation for those foliage assets.
- Polycount with my double sided approach is ouch, up to 6M per 5m long bush 150MB+ VRAM only for geometry.
So I will return to masked geometry and rework all my foliage again to be fast enough and most importantly to keep leaves visible at distance (this is the main problem with Nanite foliage). Maybe there is a way to create material for leaves that can have separate properties for backside without using geometry for that (or just be less ambitious and use standard subsurface double sided materials), but this only reduces cost & size x2. Yet still, Nanite foliage is appealing - pure geometry is the best way, I can have twisted leaves and different roughness for backside of leaves, so even my half-decent procedural foliage looks noticeably better.
All those “Nanite-only” experimental foliage assets are available inside Uniblocks Lite, it’s free.
Thanks Lex4art, it would be interesting to test those nanite leaves.
I’ll also place some pictures in case my point was not clear enough. How realistic and feasible is to model with polygons such details ? And to preserve 100% of those details. Even if you would be able to do it, would it be easy ? Doable on a large scale ?
That level of detail for leafs in mesh geometry is very likely not compatible with traditional way of making assets inside 3D app to import inside UE later (gigabytes of mesh data per tree, very likely impossibly slow work process inside 3D app…). But if we have just few super detailed leafs to instantiate across tree branches using PCG inside editor - this should work, making tree lightweight (few MBs for leafs, dozen MBs for trunk, dozen MBs for large branches to randomly place on trunk) and easy to create tree variations; I’ve seen video with this approach - there is a limit of instances that PCG can handle before overflow errors will appear, so there is a need to have some kind of distance-based culling of individual leafs and replacement those with something. With upcoming UE 5.7 there will be that voxel solution for distant foliage - so all should work, very efficient and fast, voxels will solve Nanite removing small leafs problem; at least if there is a way to generate/photoscan detailed tree trunks to match those super leafs in quality…
When working with photoreal stuff it’s quite easy to run into weak chain link - maybe PCG can’t place leafs in nature logic way, so they will still feel off (like not facing up to catch maximum light) or generated tree trunk will be not real enough/have UV seams or how to realistically animate all this and so on. Tricky stuff, demanding full time effort, a lot of it… I’m still remember your experiments with super detailed foliage in Cryengine 2, so good luck finding best balanced solution and pushing limits ), Lumen can handle a lot of detail and still be fast enough.
2 Likes
Just wanna say that the last two posts the leaves/foliage looks good, espcially the pics just above this post, the leaves. Fine-detail pops and the lighting looks great.
Above that, with the architechtural, not quite ‘perfect’ with the lighting, but the shadowed parts look nice, leaves look ‘right’ if not the rest of the piece. The way the entire bush/tree blocks lighting, what’s left in shadow and how bright they look looks on-point.
1 Like