After watching this talk about collision data (https://www.youtube.com/watch?v=xIQI6nXFygA), I investigated hooking up collision profiles to the reference viewer. I had some success, but I wanted to see if anyone else has tried this before doing this on our project.
I made the following engine edits to FBodyInstance:
Added this function:
void FBodyInstance::PostSerialize(const FArchive& Ar)
{
if (Ar.IsSaving() && CollisionProfileName != NAME_None)
{
Ar.MarkSearchableName(FBodyInstance::StaticStruct(), CollisionProfileName);
}
}
Also added this to the enum in the struct TStructOpsTypeTraits<FBodyInstance>:
, WithPostSerialize = trueThis works, but as far as I can tell the reference information is saved into the asset, so an asset needs to be re-saved for its collision profile references to show up. This is concerning since it will affect every asset with a mesh, but as far as I can tell this is how properties are hooked up to the reference viewer. Has anyone tried doing this before? Does this seem safe?
Thanks for the help!
Hi Joshua,
I’ll reach out to someone with more knowledge of reference viewer than I do here. Can I check the concern you have for context please? - Is it that by adding a new collision preset, all the assets with a collision profile (ie mesh) would need resaving each time, or have I misunderstood?
Best
Geoff Stacey
Developer Relations
EPIC Games
Hi Joshua,
I think I’ve figured out the above. If you add the collision profile as a new property in the asset viewer, you need to resave all the objects with a mesh (since it uses that property).
One of my colleagues has suggested a commandlet we have which will make this far less cumbersome - ResavePackages.
This can be run from the commandline after you’ve made the change to update the assets with the new information.
https://dev.epicgames.com/documentation/en\-us/unreal\-engine/API/Runtime/Engine/Commandlets/UCommandlet
That aside, it seems a sensible change to make.
Geoff
Thanks Joshua,
I’ve pinged the dev side to take a look and find out if this is something which is sensible to take back to our mainline.
Geoff
Awesome! By the way, the PR was closed by a bot for not having a disclaimer about generative AI. I edited the description to include the disclaimer, is there anything else I need to do to get it re-opened?
Hi Joshua,
Apologies for the delay in response - I was trying to get access to the PR on Github!
Essentially this is a good idea in theory, but this has the potential associated data to change (ie profile names) out of the knowledge of this code, and create what would be dangling references for want of a better phrase.
It works well locally, but would end up creating a fair number of support requests if we did it.
Hope that makes sense!
Geoff
Hi Joshua,
Apologies, this fell into the wrong ‘bucket’. Essentially yes - the profile names are data driven from an external config class, and there is overlap with actual hard coded items within the source code. Either one changing will break the system which makes it quite fragile from a ‘Epic’ perspective, but is probably fine for local alterations since you folks will be able to handle any fragility issues internally.
Best
Geoff
No worries! To clarify, do you mean that it’s possible that with this approach, collision profile references could change without being detected? Is it possible to make this more robust?