FastGeo does not trigger Chaos notifications

Development Rendering
, ,
1

Hi,

We’re having an issue that is blocking us from implementing the FastGeo plugin into our project using 5.6. Our project would benefit greatly from this plugin.

We rely on UPhysicsCollisionHandler.HandlePhysicsCollisions_AssumesLocked to process events on objects colliding in the world to play sound effects and create VFX on impacts. However, when actors have been collected into FastGeo containers they no longer appear to trigger any kind of collision events through this method. The parameter TArray<FCollisionNotifyInfo> PendingCollisionNotifies appears to always be empty when hitting into FastGeo objects in-game. We are able to test with FastGeo being disabled, we then see the events working as expected. I understand that actors are batched up into containers so cannot have their own local events. But we require to at least know an impact has happened to be able to react appropriately in the game. Given the FastGeo geometry we’re bumping into has collision, it seems like we should be seeing FCollisionNotifyInfo’s through this method.

Thanks,

Ben J

[Attachment Removed]

2

Steps to Reproduce

  1. Enable the FastGeo in your project.
  2. Create a class that inherits from UPhysicsCollisionHandler and implements HandlePhysicsCollisions_AssumesLocked
  3. Create a scene where you can create collisions between traditional Geometry and FastGeo geometry
  4. Observe TArray<FCollisionNotifyInfo>& PendingCollisionNotifies in HandlePhysicsCollisions_AssumesLocked being empty when colliding with FastGeo.

[Attachment Removed]

3

Hi Ben, and apologies this has taken a while to respond to. I’ll get this prioritised today and find out what is happening.

Best

Geoff

[Attachment Removed]

4

Hi Ben,

I spoke with a developer today, and we are in the process of getting this fixed up. Once it is in review I’ll ping you with a CL for you to take (and longer term I’ll be in the next release).

Best

Geoff

[Attachment Removed]

5

Awesome, that’d be great. We’ll merge it in as soon as it’s available and give it a test.

Thanks,

Ben

[Attachment Removed]

6

Hi Ben,

If you look at CL 50491879 that should fix up the issue.

Best

Geoff

[Attachment Removed]

7

Hi Ben. Chris Trewartha (Your Technical account manager for Maverick) asked if I could reopen this since there is an issue. Did that CL not work?

Best

Geoff

[Attachment Removed]

8

As Matt mentioned unfortunately the CL provided incurs many other knock on changes we can’t take in 5.6 without it spiraling out quite quickly. We spent some time trying to unpick it but were unable to get any further. Without carrying over many branching changes.

[Attachment Removed]

9

Hi Both,

I’m afraid we won’t realistically have the bandwidth to do that. My understanding is that you are in the process of upgrading to 5.7, that may be the best way forward. It is worth calling out that FastGeo will be in ‘experimental’ status still (and will be infact for 5.8 as well) , which means that our clients are free to use the tech, but that it isn’t fully productionised, and may have changes at the API level.

Best

Geoff

[Attachment Removed]

10

Hi Geoff. No - pulling that CL into our code (we’re on 5.6 at the moment) wouldn’t compile as a bunch of other stuff had changed. I tried to follow the path and pull in those dependencies too, but that led me down a path of having to pull in more and more. If we could get a version of the fix that works in 5.6 that’d be ideal for us.

[Attachment Removed]