Pull Request: Niagara Data Interface - RigidMeshCollisionQuery extension

Development Rendering
, ,
1

I’d like to highlight this pull request I’m opening: https://github.com/EpicGames/UnrealEngine/pull/13627

The RigidMeshCollisionQuery Niagara Data Interface holds lists of collision elements, grouped as Boxes, Spheres & Capsules.

This change exposes the index of the first element of each type, so we can access them by type, and loop over specific groups.

This change also exposes the Extents value for elements.

Both these changes, allow for custom collision handling implementation, like swept collision.

2

Steps to Reproduce

3

Hi Quentin and thanks for the pull request!

I think that at the moment I’d like to continue to hide the Extents values for the different primitive types. How would you feel about specialized functions along the lines of GetSphereRadius(), GetCapsuleSize() and GetBoxSize() ? Just allows for changing around how the data is stored under the hood if we want (pack all the spheres together rather than a float4 for each, …)

4

Yeah that works for me :slight_smile:

If you’d like I’ll update the PR I made to do that myself

5

that makes my life easier! and ensures that it continues to work with your other code changes…but I can always put it together myself if need be!

6

No worries - yeah I’d rather keep my code in sync with the one you adopt for future ease of integration.

I’ve updated the pull request with 3 distinct functions.

I thought I’d go with a float for Sphere Radius, float2 for Capsule (radius & length), and float3 for Box Size - hope that makes sense?

7

Yup, having the explicit values tied to the primitive type is good with me! Makes it easy to expand to other primitives/packing/metadata so that’s great. I do wonder though if those functions should now just take their primitive index rather than the global index (and likewise, that could make the GetBoxElementsStartIndex() implementations sort of unnecessary? i.e.

int SphereCount = 0; GetNumSpheres_{ParameterName}(SphereCount); for (int i = 0; i < SphereCount; ++i) { float SphereRadius = 0.0f; GetSphereRadius_{ParameterName}(i); // do work with the Sphere radius, ... }

8

At first glance, you’d think it simplifies things, as you’re now dealing with a concrete primitive type and reasoning about them like so… But I think there’s value in keeping functions like “GetClosestPoint” working in a generic way, and therefore not lean into the concrete primitive type indices too far.

Also the various Get Transform functions (like GetCurrentTransform_{ParameterName}(in int ElementIndex), use global indices. so we’d still need to know them to use those functions.

From a divergence pov, I think it’s generally better to go with global indices, as it will encourage licensees to write their code from a global index pov - probably reducing the amount of conditions.

But in special cases, where you want to implement your own collision algorithm (like I’ve done), and want to retrieve only a specific collision shape type, having access to these new functions is necessary.

Hope that made sense :blush:

Q

9

All good here! While I still have some concerns about the risk of footguns with people mixing indices or trying to interpret a sphere as a box, or whatever, I think there’s not a huge risk, and this does expand functionality. So…sorry for the back and forth!

Change has been submitted. Thanks for the contribution!