By default, the opacity mask for static shadows only works if texSample is directly connected to it. If you try to use ShadowPassSwitch or a custom function, light baking ignores it. Are there any ways to fix this? Any option works for dynamic shadows.
Not entirely sure I understand what you’re trying to accomplish but there is a lightmass replace node in the material editor
1 Like
Thanks for the reply, I didn’t know about this node. But unfortunately, it doesn’t work.
I create procedural surfaces based on ray marching inside meshes. I think the generated Opacity mask should work for shadows as well, but it doesn’t for static shadows.
it seems lightmass does not evaluate world position. so… you gotta think about how you generate your raymarch coordinates and alpha. it is able to use texture and texture coordinate based sampling to evaluate opacity and resulting baked shadows.
just tested it. engine version is 5.6.1.
also does pure function evaluation.
so… i guess your material setup isn’t correct.
For what it is worth, if you’re using CPU lightmass then you may have better luck with GPU lightmass, as it has better material support. I still have no idea if this will work.
My understanding of CPU lightmass is that it effectively collapses the material to a simplified version before computing the GI and so certain material effects may not work including, I assume, anything involving the camera position.
1 Like
well… the 3d space could be easy to get if you uv unwrap the cube or any shape as a volume. basicly copy the position into 2 uvs to sample. unfortunately lightmass seems to only uses a single texcoord pair for the opacity sampling, so… the z-axis (in this case) is lost. bummer. or some mods required.
the raymarch is a different beast anyway, tho. a direction is required. and i have no idea if lightmass would evaluate the “shadow march” loop.
Opacity masks with lightmass has always been a bit limited, in the past I’ve tried using vertex painting to control the opacity masking before baking with lightmass, and that’s not supported at all. Last I heard you’re expected to not bake lighting for those meshes/materials.
just to complete the thread. gpu lightmass does work with world position mapping, the bounding box mapping and discrete uv mapping without issues. it should handle all sorts of procedural material shadows. i didn’t test the raymarch, but that’s something the op can try.
so… the alternative would be to use gpu lightmass. the results are a lil different in shade but an artist can control that. : )
1 Like
Well, that’s absolutely true. I thought CPU Lightmass worked on a similar algorithm, just slower.
The other side of the problem is that UE5 GPU Lightmass doesn’t work correctly. Different versions have different issues. In 5.5, these objects don’t cast shadows. In 5.6, the light doesn’t bake at all. The beta version is a beta version.
In 4.27, GPULM works perfectly.
Yeah, Epic has pretty much left it to die. The original author put out an updated version which should address a lot of the issues, you can find it here: Epic's GPUlightmass - #668 by yujiang.wang
1 Like
You made my day. Yes, finally baking the light at 5.6. works as I wanted.
1 Like
Sorry for the question, I don’t want to create a new topic. Do you know why stationary directional light doesn’t bake static shadows?
stationary lights only bake light volumes and gi. the desired inbetween for dynamic character shadows.
Stationary directional lights do bake shadows, but if you are using Cascaded Shadowmaps for your dynamic shadows then they will replace baked shadows within the CSM range (probably also the DF shadow range if you’re using them)
Basically, if you’re using a stationary directional light then the static shadows are only useful for distant shadowing. It can allow you to use a much shorter CSM range though which will improve quality/perf.