Please implement a fix for this. How I fixed this on our end is to call “BodyInstance.FixupData()” after the override descriptions are done.
For static meshes this can be done in “PCGMeshSelectorByAttribute.cpp” inside the for loop that applies the override descriptors (in Unreal 5.5 it’s at line 225).
`…
int32 AnyPointIndexOnThisPartition = Context.AttributeOverridePartition[I][0];
Overrides.Apply(AnyPointIndexOnThisPartition);
Descriptor.BodyInstance.FixupData(Context.GetTargetActor(nullptr)); // ← Fix collision
}
// Given partitioning is expensive, check if we’re out of time for this frame
…`
You’ll probably want to add a check to see if the collision profile is actually changed or not (I do that in the validation loop about 20 lines up, just do a string compare with “BodyInstance.CollisionProfileName” to see if the user is attempting to override the CP). But this will fix the profile. I can’t show the exact code as we also made a bunch of other customizations, but this gets the gist across I think/hope.
For spline meshes I essentially do the same thing, but because it doesn’t have a mesh selector it just looks a little different. In “PCGSpawnSplineMesh.cpp” it’s around line 140 I think.
... if (DescriptorOverride.IsValid() && !DescriptorOverride.Apply(0)) { const int32 Index = static_cast<int32>(&Input - Inputs.GetData()); PCGLog::LogWarningOnGraph(FText::Format(LOCTEXT("FailOverride", "Failed to override descriptor for input {0}"), Index)); } SMCBuilderParams.Descriptor.BodyInstance.FixupData(Context->GetTargetActor(nullptr)); // <- Fix collision ...
I think the nicer solution would be to have the overrides actually find the “SetCollisionProfileName()” function, instead of just setting the collision profile name. That function should set the profile properly as well (including responses), but since it seems like you automatically find the setter functions I don’t know how you could get it to find that function though.
Steps to Reproduce
When overriding collision profiles via an attribute the collision responses aren’t updated properly. Both the Static Mesh and Spline Mesh spawn nodes don’t set the profile correctly, so for repro purposes I’ll provide a description for both.
Static mesh spawner repro steps:
- In a PCG graph have a source of points (point grid/create points)
- Add a mesh attribute, soft object path type, set to a valid mesh (ie: “/Engine/BasicShapes/Cube.Cube”)
- Add a collision profile attribute, string type, set to a valid profile (ie: “BlockAll”)
- Add a spawn static mesh node
- Switch it to PCGMeshSelectorByAttribute if it’s a static mesh spawning node
- Add the collision profile attribute to the override descriptions, using “BodyInstance.CollisionProfileName” as the property target
- Set Attribute Name to your mesh attribute
- Make sure the collision profile set in the template is different from what you set in the attribute so you can see the difference (ie: “NoCollision”)
- Look at the generated result, you should see the collision profile name on the ISM set to BlockAll, but the collision enabled option set to No Collision.
- Note: the error on the node doesn’t seem to have much bearing on how this works. It comes from the validation of attribute overrides not being able to handle any property name with a period in it. The spline node does not produce an error and behaves the same.
For spline mesh spawner:
- Have a source spline input
- You can use a create spline node with a few points as input
- Add a collision profile attribute (same as step 3 from the static mesh version).
- Add a spawn spline mesh node
- Add the collision profile attribute to the the override descriptions (just like for SMs)
- In the descriptor, set a static mesh and make sure the collision profile is different again
- Look at the generated spline mesh component, you should see a spline mesh component with the same wrong collision response as on the SM
(I added some screenshots to show the issue and graph setup I tested with)
1 Like
Hi Jeffrey,
Thanks for reaching out.
I agree with you, it would be nice to be able to call “SetCollisionProfileName” directly, and we’ve actually have seen similar problems in other cases (e.g. setting a mesh on a Static Mesh Component for example).
I’ll talk with the team and we’ll see what we can do in the short term (namely 5.6, otherwise it’ll be either in an hotfix or in 5.7), but thanks for the suggestion!
Cheers,
Julien