Hi @Krzysztof.N ,
Unfortunately I was using default Lumen settings. I have prepared a proof project for you:
PT one sided mat:
PT two sided:
Lumen one sided:
Lumen two sided (GI partially destroyed and, huge dependence on screen traces):
RT shadows 2 sided, nanite mode 0:
RT shadows 2 sided, nanite mode 1 (ray tracing not tracing against full mesh over distance; look at the patches at the center of the ceiling. Working fine when going closer):
Project download: Dropbox
Thank you
There’s a long standing bug with Nanite and two-sided. You need to either don’t use two-sided or disable Nanite on that mesh.
yeh. why would one do 2 sided on this concrete prop in the first place? it’s only ever visible from one side. makes no sense to use 2 sided.
to me, it only further proofs dude is just breaking things, to break things. maybe to get some “feedback” in. i smh tbh.
missing proper application. i’d use 2 sided only on foliage or thin fabric materials where the directionality matters.
the pt screenshot for sure looks f-ed tho. is that tracing using proxy mesh? shadow intersections? where they differ?
Thank you @Krzysztof.N ,
Understood. I hope it arrives in the future. In addition, it’s a pitty that RT shadows + nanite and + LODs (yes…) are also broken, with those distant patches. I know that this it not your field, but I have already reported it somewhere, but nobody cares.
EDIT: I have disabled nanite in that mesh, but I don’t notice any difference regarding PT nor RT. But it bypasses the error of lost Lumen GI when 2 sided mat.
@glitchered The original one it’s a marketplace asset so, sometimes, we need to adapt ourselves to what we get. I can’t remodel a hyper realistic 3D scan just to make it render correctly.
Unfortunately it’s quite usual that the active and innovative developers encounter tons of bug and/or challenges during our Unreal 5 projects; it’s not (obviously) intended. Only when making real projects, you discover how the things really work.
About the screenshots all info is in them, but that project it’s just straight fordware. Impossible to be more simple and standard. Anyone can also check the project by himself.
You do make a very good point there. ArchVis does love their white rooms and perfect mirrors, and the people I’ve talked to would probably love what you’ve figured out. The notion of reflecting unshadowed skylight with ‘painted-in’ DFAO is honestly very interesting to me, your results are pretty convincing.
To your point again, even a little bit of art direction goes a very long way. It’s very similar to the instructions epic gave in the old reflections enviroment setup page: Reflection Environment | Unreal Engine 4.27 Documentation
In a way, lumen doesn’t really change the rules on making good real-time reflections: non-mirror and non-planar surfaces produce far better results than anything perfectly smooth. and If you want genuinely perfect reflections, just use GPU lightmass and standalone reflections.
I’m speaking from Archviz and I say that the solution is not viable in production projects. The absence of GI makes the mirror a stranger to the total photorealism of the rest of the scene. With this LightMode 3 solution I also noticed a certain phantom doubling of some objects reflected in a particular camera/mirror angle. Beyond this aspect of the “mirror” object, there remains the problem of noise on reflective surfaces, especially if in dim light.
Mirrors are just not possible at the moment. There are a million ways to somewhat improve it a bit but nothing that really solves the issue. Somehow smoothing out the surface cache would probably get us much closer to a usable result.
in 5.4.2 lighting mode 3 works to some degree if an artist can handle the required tweaks.
i’ll see how 5.5 handles it (in a couple hours, cool speed compile day). i’ve seen some code changes to the indirect rays. hmm…
Hey,
I’m new here. Can I ask a few questions about Lumen Mesh Cards and the Yellow coverage area in the Lumen scene?
Since small slats with many quantities will be used in the interior space, in a few shots, they will occupy more screen space than in this example I have shared. I’m trying to get better lighting behavior out of these models when I work on the production. Is there any way to fix the yellow coverage area? I want to eliminate yellow at all in my scene with the selected objects. Some one in this forum have mention, Lumen tends to ignore smaller objects. Is there any way to tell lumen this value is smaller for my this scene instead picking a value for itself? Kindly note that FPS is not a priority here!!
Once the mesh gets a scale in one direction, the size has changed to a large one but still, no mesh card is generated for this model, why? To fix this what should I have to do except import scaled model?
In the Object edit window, the model has not scaled but in the viewport it does?
sorry for the basic questions, I would appreciate any help/advice on the topic.
Thanks!
Question - in pc-VR I see glitches in the left eye only when using Lumen (+Nanite +RT translucency). See video. Any suggestions how to fix that besides not-using Lumen?
Edit: its a VSM issue
Edit2: the issue is easily fixed by either settings the the lights that affect the surface to ray traced shadows OR disabling one optimization of VSM by r.Shadow.Virtual.OnePassProjection=0
that is a vsm issue not lumen.
Thanks for the reply. Sounds logical - will dive into VSM to find a solution
@Krzysztof.N
@BananableOffense
Hello, Please look into this issue and provide a possible solution for this, Thanks!
Last I checked, mesh cards are generated strictly upon import scale and parameters, meaning no matter how big you make the object in world space, if it doesn’t fit the minimum size necessary to receive cards, it won’t have any coverage. The only real solution you have is to import a mesh big enough to receive coverage.
i might wanna add: mesh distance fields play a lil role too. flat, thin or too small objects will not generate voxels either to fall back on.
(i’m slowly digginng into the lumen code. bit of an odd state right now. i wanted to check if i can fix the sample fog. volume tracing is in active progress, tho. hmm…)
Isn’t it possible to rescale/transform an object and then sort of “bake-in” the new transformation and force the new object to acquire cards for lumen again ?
Yeah. Only one addition: I think I remember something like if you enable in the static mesh the option Emissive Light Source, it would be included in the Lumen scene. Not sure, but @Error can try.
That is a good point you raise, but I don’t believe it will solve @Error’s problem. AFAIK, the Emissive Light Source tag forces the surface cache to not cull a given mesh’s cards, to stop emissive objects’ lighting from popping as the camera gets closer or further away. However, it can only stop the surface cache from culling cards if the mesh had cards to begin with, and if an object is too small to have cards it won’t be in the consideration at all.
Oh, I see @jblackwell ! Anyway, your post was the answer.
PS: Hi @Krzysztof.N , not sure if I mentioned this time ago (I don’t remember any reply), but hair under GI (no direct lighting hit), is quite terrible:
To reproduce: download the Meerkat demo. Take the Meerkat BP and place it into any new map with a floor and a ceiling. Check the scary result turning the camera around the meerkat.
Regards!
