 |
Once the xmas contest map is done I can take a look and see which light/s or entities have the "r_useOptimizedShadows" on and remove it. |
 |
No difference on "dmap_compatibility 209" It is quite likely that the issue started happening long time ago... |
|
|
The issue happens on the kind of lights shown on the screenshot. It seems that it only happens in the starting area (maybe because it has larger coords). I flew around the map and did not find any more issues, even where seemingly the same lights are used. The problem here is the grid occluder, which consists of many thin wires very close to the light source. Dmap processing makes them slightly non-closed, which can have ill influence of the generated shadow volumes. It is still interesting why only precomputed shadows suffer from this problem. The runtime shadows are usually generated with another algorithm (turbo shadows), maybe it is more resistant to problems of occluding geometry. By the way, I saw similar problems on Painter's Wife in the sewers section (large round vertical room with lots of water) happening on the same kind of light source. I think we should get rid of it somehow... is it a prefab? I suppose several workarounds can fix the problem: 1) Convert the grid into model (or better create a brand new model which is perfectly closed). 2) Set "noPrelight" "1" spawnarg on the light entity to stop dmap from precomputing its shadows (runtime generation seems to work fine). nhat3_wrong_precomputed_shadow_volumes.jpg (184,840 bytes) |
|
|
Ok, the problem is in non-turbo shadow volume generation, not in dmap. Because if I set: r_useOptimizedShadows 0 r_useTurboShadows 0 reloadModels Then the engine regenerated shadows in runtime using the non-turbo algorithm, and I see the same issues. But with turbo algorithm (which uses the same model) shadow volume is perfect. |
|
|
Thanks for looking into this fella. |
- Anonymous
