GetDynamicMeshElements and shadow passes

Hi,

Following my post Plugin FPrimitiveSceneProxy Billboarder - C++ - Epic Developer Community Forums
I hopefully began to implement the FPrimitiveSceneProxy::GetDynamicMeshElements with 4.6.1.

But GetDynamicMeshElements is still awful for translucent shadow passes:

I was hoping to be called only once per frame, receiving all views (camera’s views + shadow’s views). But instead, my GDME gets called once for all “camera’s views”, then gets called for each shadow pass of each lights !

It seems to me to be a “hack”: each shadow passes disgracefully overriding the ViewMatrix of an arbitrary View to get the job done (Engine\Source\Runtime\Renderer\Private\ShadowSetup.cpp:891).

Am I doing something wrong ?
Does GDME shadow passes will be improved before the deprecation of DrawDynamicElements for v4.7.0 ?
Or should I just stop trying to have shadows ?

When rendering shadows, each shadow is considered a different view (since we’re rendering from the POV of the light). It is indeed a hack that just the ViewMatrix and a few other things are overridden on one of the main views, then that is used for shadow rendering. We want to fix this but it has to be done carefully as a lot of functionality has built around it unfortunately.

The design of GDME is that it will be called once per frame per group of views. So the main views is one call, and each shadow pass is one call because that’s a new group of views (with just one entry).

That’s what I was afraid of, but I totally understand. Thank you.

GDME is still a great way to render dyn meshes. I’ll try few more ideas to render my shadows, but I hope you guys could come up with a better GDME shadow pass sooner or later.

I am curious of the origin of such a hack, as surely there was never a reason not to do it properly, do you have any insight?

Here might be an element of response:

I even realize that all SceneProxies that cast shadows take the full performance hit of those shadow pass’s GDME “standalone” calls (rebuilding all their render resources for each shadow pass).

Would the way that translucent shadows render be the reason why I am getting wierd shadows in my custom volumetric procedural mesh component @<a href=“https://forums.unrealengine.com/member.php?u=404” target="_blank">DanielW</a>? I am makeing the geometry to face the half angle between the camera (from the playerCameraManager n c++) and the light direction. If the translucent shadows are rendered from a diffrerent angle from the light vector (ie are the fourier opacity maps rendered from a different view/method?) then would the geo I’ve made be at the wrong angle for that shadow pass to make sense?

I’ve got ethe technique from here https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch39.html and it seems to be difficult in UE4 to do the renderbuffer rendering per slice. so I was hoping that the translucent shadows would help here.

[video]https://youtu.be/BlIXaF4FGVY[/video]

Any help would be appreciated :slight_smile:

Nice clouds !

Makes me a bit think of bugs I had when I had bad BBox. By default it will use your component’s BBox to compute shadow frustum, so you’re rendering off those bounds that could explain that.

Also, if you have a view (in-)dependent geometry, be careful with the FSceneView ViewMatrices: it will be the camera view for the first GDME, but subsequent GDME calls for shadows it will be the light source point of view. Also, last time I checked the InvViewMatrix was not properly patched for shadows GDME, and was still the last inv view of the camera (I even used this bug to detect that the current GDME was a shadow pass… (but now I use ViewMatrices.GetDynamicMeshElementsShadowCullFrustum != null)).

I’ve experimented with multiplying the bounds size up in the Calc bounds function of the component. Are you suggesting that calcing he bounds in the component is causing problems?

I have faced the geometry to face the half angle between the light and the camera with the idea that it should face both regardless of which view it is being rendered from. If the shadow map is being rendered from the camera view as you say in GDME then I guess that could cause cause issues.

I’m also unsure how translucent volumetric shadows are rendered into the opacity maps (ie are they don’t from cam view into shadow maps?).

Another cause might be that because I am doing the geometry generation in inverted camera space (because the slicing math is easier on a unit cube and it gets transformed by the actor matrix at the end anyway). The tangents could be messed or something. Also I would want to test using the shadow view.

You are welcome to have a loom at the coded here and see if anything looks wrong to you…

Thanks for the info! There’s no way I wouldve known that from documentation.

If you want “good” shadows, we should re-build your slices for each GDME to get your slices facing each time to current ViewMatrices. So for the camera view, slices would face the camera, and for shadows, slices needs to face the light source point of view (which is stored in ViewMatrices).

Shadow pass re-render the geometry from the light source point of view. For opaque object it will basically only get the depth, for translucent it’s more complicated, I think UE does something like that: http://developer.download.nvidia.com/assets/gamedev/files/sdk/11/OpacityMappingSDKWhitePaper.pdf

So if you have your geometry facing the camera while rendering shadows of a light at 90deg on the side, shadow pass will render all your slice seen at 90deg, only seeing the “cutting edge” of your quads, and nearly not shadow will be generated.

Maybe looking at your cloud’s shadow on a floor could help.

You got a rotating light, right ? this could explain the “back and forth” of the shadows while the light is rotating.

This technique stops the 90 degrees slice angle by facing the slices to the half angle between the camera and light. In fact its for that very reason. So technically the slices should be visible to both camera and light.

The rotating light in that video is a debug video to show the issue. It does look suspiciously that the light is leaking through the slices though. Or as the angle is 90 degrees and between cam & light (when the slices are 45 to both) then the shadows is wrong at that state. But I would expect a linear fade in and out as opposed to the increasing rate of spin on the shadow.

On the floor, the shadows fade in and out the same as the self shadows.

On approach im thinking of doing is to not use the translucent shadows and do the shadows in a custom node with tracing. That way I get the slices rendering the cloud opacity and the tracing doing the shadow. wouldn’t get shadows on floor though.

Cheers