Ray Traced Distance Field Soft Shadows and Instanced Static Meshes

First off, props for adding Ray Traced Distance Field Soft Shadows to UE 4.5 - it massively improves the visual appearance of our game!

That said, it appears to not properly handle Instanced Static Mesh components.

I’ve done some testing and found that if, in the editor, I add an Instanced Static Mesh component and give it some transforms, those render correctly with correct shadows.

Our game (a top-down strategy game), however, adds transforms to an Instanced Static Mesh component at runtime (by calling AddInstanceWorldSpace). Those meshes are rendered at the correct location - but the Ray Traced Distance Field Soft Shadows are all drawn at the origin.

I’ve just tried reregistering the Instanced Static Mesh component after adding instances to see if that solved the issue - but it doesn’t.

Is this a bug in the engine - or am I doing something wrong?

It works fine with Cascaded Shadow Maps - but they don’t look nearly as nice! :slight_smile:

Distance field lighting support was added for instanced static meshes just 2 days ago. Here’s the commit: https://github.com/EpicGames/UnrealEngine/commit/891d02089af42cd04356b129fb6c95ede624bdd8

I haven’t tried it yet, but maybe this solves the issues with instanced static meshes?

It looks like it might - thank you!

If you want to convert your reply to an answer, I’ll mark yours as correct once that change gets merged into a release branch. :slight_smile:

Hello! It doesn’t seems to be fixed in 4.6.1, I have the exact same problem of the shadow on Instanced Static Meshes being drawn at the origin.
Is there any ETA on a fix ?

It’s currently in the 4.7 branch on GitHub, I’m waiting for that to be released before switching us over to it.

I’m looking forward to it, there’s a lot of improvements around ISM components and Foliage in 4.7!

At the moment this looks like it will be pushed out with the release of 4.8. It’s definitely a feature I’m glad to see working now! :slight_smile:

I apologize if I come across as being a jerk but could we possibly not forcibly select questions as being answered that people can’t make use of unless they want to use potentially buggy unreleased versions? This problem remains an issue, certainly for my team and our project, until it makes it into a release branch.

It’s a little frustrating when I specifically said “I’ll mark yours as correct once that change gets merged into a release branch.” though, admittedly, I should have said “the release branch”. :wink:

That said, the commit that Chariots referred to is definitely in the 4.7 branch in GitHub so I’ll be a little upset if I have to continue waiting until 4.8 is released for it to work. The shadows coming from CSMs just don’t work well for our game (essentially a top-down strategy game) - something I’ve asked questions about in the past.

It may have been merged to the 4.7 build, but it’s not in the 4.7 preview 4 build I’m looking at. I know it’s in the 4.8 master branch though.

Answers are automatically selected when a staff member responds. Apologies for the confusion on that.

As for CSMs/BSP I’m not sure if that will see any action anytime soon. it may, but there are other priorities with distance fields that would be more beneficial such as Distance Field GI implementation. The recommended workflow for BSP is to convert this to a static mesh as it’s much more efficient.

Ah, understood about the automatic answer selection. It’s unfortunate - but I understand now. Thanks for the explanation!

As soon as I can switch to Distance Field Soft Shadows, I’ll drop CSMs and switch to DFSS faster than you could possibly imagine! IMO CSMs work well for games that are enclosed (so they’re great for a typical FPS) but just don’t in more “open-world” strategy style game where you typically always see a lot of the world with few obstructions. I’m looking forward to the fix making it into a release!

Just a heads up that this feature will likely be in 4.8 and not 4.7 after speaking with an engineer. The master branch currently is 4,8 and has features scheduled to be released with that. Can you verify that this is the master branch by looking at the About tab. It should say 4.8 - [CL number].

The 4,7 branch is not the previews that are provided by the launcher as the preview builds are not being provided there.

Sorry for any confusion or frustration this may cause.

That’s unfortunate… but I definitely appreciate you letting me know. Thanks!

I guess you guys must have a really complicated branching system then. :slight_smile: I was just hoping that the fix would be in the 4.7 release because commit “891d02089af42cd04356b129fb6c95ede624bdd8” is in the 4.7 branch. But now I know better!

Anyway, now I’m really looking forward to the 4.8 release because CSMs don’t work well for us - but DFSS does (and looks amazing too!).

Thanks for the update!

No problem. And you’re not alone with the confusion. From my understanding there are commits that will be added with a specified CL (in the case of the DFS for foliage it was 2372693), but this hasn’t been added to the preview builds that are only available through the launcher (The build on Git Hub is not updated like the Preview builds for the launcher, and the master branch is actually 4.8).

Although a commit may be added to what looks like an older build, the branch date may have happened before that preventing the feature from being added to the preview build that goes out and putting it with the next release. Once it’s added to the next build it will get a new CL in line with that next release that is available via the master branch. (see where the confusion sets in! o_O )

I’m excited for all the DFS features is working on. Actually been playing around with DF GI.

If I do notice any changes and this actually get pushed out with 4.7 I’ll make sure to update you with what I find.

Thanks!

Just to make sure I understand - Ray traced shadows work fine from pre-placed instanced meshes in your build, but not if you place them by calling AddInstanceWorldSpace in game?

As far as I can tell from looking at the code, it should work as long as you call MarkRenderStateDirty() after calling AddInstanceWorldSpace.

Hi ,

Thanks for your reply! Yes, you’re correct. Ray traced shadows work fine for either regular static mesh components OR instanced static mesh components that already have their transform instances set up when the world starts. But it does not work at all for instanced static meshes that add transforms (using AddInstancedWorldSpace) when the game is already running - all of the shadows appear at the world origin.

I just tested it again to be sure (calling MarkRenderStateDirty on the Instanced Static Mesh component after adding all of the transforms) and the behavior hasn’t changed - shadows appear at the origin.

It does make a little sense that it wouldn’t fix it though because calling ReregisterComponent() also marks the render state as dirty (apart from all of the other setup that it does) and that didn’t solve the problem either.

Bear in mind that I first reported this issue with 4.5 and we’re currently using 4.6.1 - perhaps the code you were looking at was for a later version that already has the necessary fixes?

The thing I don’t understand is that I did not submit support for distance fields from instanced static meshes until

Change 2372693 by .Wright@DWRIGHT-Z2430-UE4 on 2014/12/01 12:40:35
Distance Field lighting features now support instanced static meshes including instanced foliage

This will be in 4.7, it is not in 4.6. So there’s no way you could have had instancing support on the build you are on.

In 4.6 and before, only the first instance of instanced mesh components would appear correctly in the Visualize Mesh Distance fields (and therefore cast a ray traced shadow correctly).

Well, then perhaps I was only seeing shadows from the first instance then. That’s not what I remember seeing - but that doesn’t mean that you’re wrong! It HAS been almost 4 months after all. :slight_smile:

The pertinent part of my question was that it wasn’t working correctly with Instanced Static Meshes - thanks for getting that working! So that change WILL be in 4.7 and we won’t have to wait until 4.8? That is great news!

Congrats for your work on Distance Field lighting, it really makes our game look amazing.

This is from the 4.7 p6 that just went out yesterday.

That looks great - we’re looking forward to the official release!

True to my word, I’ve now marked your answer as correct. This is working now with UE 4.7!

Thanks!

It’s the Affect Distance Field Lighting option that does it. Thanks!