Does anyone have experience with raytraced foliage actors?
I have a directional light set to stationary. The clover static mesh is from the megascans meadows pack
In the first image, the clover is generated via the foliage tool. But the shadows are behaving funny as if they’re being projected onto the meshes themselves.
In the second image I placed the clover static meshs as a non-instanced staticmeshactor. Giving me the option to check off Evaluate world position offset under raytracing. The shadows appear as they should by setting it this way. Is there a way to recreate this “Evaluate world position offset” under a instanced InstancedFoliageActor?
AFAIK mesh instances using WPO are still not supported. It’s very hard problem to solve, in both offline and realtime rendering. So if you have your mesh instances animated by WPO (shader effect), then the shadow maps are generated for static version of the mesh, in original pose without WPO, and then applied to moving mesh. This causes shadow map to randomly intersect through the animated meshes, making shadows appear sometimes in front, sometimes in back of the mesh.
When raytracing is enabled I noticed that translucent materials are being treated like opaque materials (using a stationary directional light). Am I overlooking something obvious?
I think it should be a high priority for Epic to fix the issue with raytracing + foliage + WPO. It’s currently impossible to get good looking raytraced shadows with foliage. If it would at least be possible to just let foliage use CSM and everything else RT shadows, then that would also be a fine solution, but it seems to be either “everything uses RT shadows”, or “nothing uses RT shadows”, and that means any scene that has any WPO foliage just can not use RT shadows at all. I would be happy with keeping foliage in CSM, and let all the rest use RT shadows.
It’s not an issue, it’s a bigger technical limitation no one in the rendering world has solved properly yet. Epic are probably closest to solving it out of everyone else in the rendering world, but it will still take a lot of time and research to get there.
WPO is just distortion of the rasterized buffers. It’s a postprocessing effect, not real 3D displacement like in offline 3D rendering engines. You can do that with rasterization, but not with ray tracing. You can not just simply postprocess/distort 3D geometry acceleration structure needed for ray tracing. That’s why no offline renderer has something like WPO that is fast and doesn’t cost any memory. So now, with introduction of ray tracing, Epic is crossing the line between rasterization and ray tracing, and these issues on the line between the two are becoming way more obvious.
I of course agree it would be great to have it solved. Just keep in mind that the reason this is not (properly) solved yet is not because they are not realizing how important it is, or because they are lazy or have different priorities. It’s simply because it’s a really, really hard problem to solve.
