I have been working on building out a modular weapon system utilizing mutable for the last several months in UE 5.5. While as a proof of concept I have the system working, there are a number of issues I would like to expose and see if there are fixes coming or suggestions for me to help mitigate these so that I can plan accordingly beyond proof of concept.
We get 100% crashes if a customizable object is in an actively open window while running the client in editor.
Any socket update made to an SK used in mutable requires a full editor restart to see the changes in game
Would love to have support in mutable that defined where child customizable objects would connect to their parent, rather than just being the object’s origin.
Think generic weapon attachments needing to be at the attachment’s local origin for consistency, but needing an offset per weapon depending on the weapon it is being attached to.
Right now I am solving this with sockets and ABP logic, but that is rather heavy handed and likely to have scalability issues.
Perhaps this is what Transform Mesh in Mesh will do, I just have not been able to get anything to happen with that experimental node yet.
I can’t always rely on a material index order to be consistent across all meshes, but the only way I see in mutable to override a material is by material index ID. Having the option for assignments by material name would make this less prone to errors and more flexible (particularly with the inability to change material index in editor).
The Table Material pin in the Mesh Section node does not appear to be reliable. I can override a mesh material with it, but often the required material entry in the Mesh Section node will still be used instead of the pin. This can also be seen performing different behavior based on the order multiple Mesh Selection names are connected to a Mesh Component node. By changing the order the Mesh Section out pin is connected to the LOD 0 array pin for the Mesh Component, the Table Material will be applied (or not), even though that should have no bearing on the results.
Thanks for any help or thoughts you can offer.
Best,
Matt
Context for the attached screenshots:
Modular setup struggles with shared assets between weapon types
Order of pin connection providing different results
Steps to Reproduce
[Creating and packaging a repro project for [Content removed] page is not loading for me.
“Oops! This is an invalid page. Please navigate back to your previous page, or use the site header to find what you’re looking for.”
This is for the socket issue listed bellow. Notice that if you change the location of the pelvisSocket on Quin that this will not be reflected in game by the cube location until a complete editor restart is done.
I don’t have a crash repro for vanilla yet, can keep working on that.
We loaded your project but we are unable to find the weapon. Where is it located? Is possible that it is not part of the project? In any case, here are some answers to your questions:
Can we have the callstack of the crash?
It should not require a editor restart. Are you compiling the root Customizable Object?
Any Customizable Object can be a child of another Customizable Object. Looks like you are not parenting them correctly. This is done on the child one, where you need to point to a parent + group node. If you do not want to use groups you can always use Import/Export nodes which give you more flexibility.
If you want to move the geometry you have two options:
Using the Transform node. This will only move the geometry, no bones will be moved.
Using the apply pose. This will move the geometry + bones based on the given pose
This is one of the limitations of Tables, you must make sure that the structure of all objects is always the same (in this case material index). If not you can always use a big Switch where each entry has its own structure.
We are unable to reproduce the Material issue since we do not have the weapon. The Mesh Section does not require a Material to be connected, it can directly be specified in the properties panel. That pin allows you to use a different Materials but you must take into account that they must share the same Material parameters as the one set in the node. If connected to a Table Node, make sure that all rows have a Material (no nulls).
Thank you for the response Gerard. I hope you had a pleasant two week break.
For my project, I didn’t load one with the same assets that my proof of concept project is using (no weapons). Instead you can find the same issues using nothing but the third person sample project assets. That is what I have attached for you. If you open CO_TestParent you will find the material issues example (Issue #6). If you move the pelvisSocket around on the SK_Mannequin skeleton you will find that the box that is attached to that socket in the sample file does not update to the correct position until you restart the editor (Issue #2).
I have attached the call stack for the crash
I am compiling the customizable object after changing the socket location. Please see the sample project for the issue as described above. Move the pelvisSocket in SK_Mannequin and notice the box does not move in PIE until a restart of the whole editor.
I can make the child objects work in the context of slotting in the parent just fine. But when the parent needs the child to be in different places depending on the parent being used, that is where it gets tricky.
Thanks for the information. From what you are saying it sounds like I will need to address the problem outside of mutable (or with the Pose Mesh node, I have not tried that yet), as the only Transform node I see in mutable is the experimental Transform Mesh in Mesh node that I have not had success with yet.
Understood, this sounds like a limitation I can work to address on the DCC side as much as possible, though being stuck with only using material indexs is not ideal and I hope is something that will get some quality of life improvements in the future.
I also ran into another snag over the last week as it relates to materials. From what it looks like, all meshes in a table must have the same number of materials in them as well. If there is a Mesh Selection node for a material index that does not exist it throws a warning with no way to check if that the mesh section is needed or not. This limitation is rather troubling, as if I would like to re-use my mutable COs for an entire set of character upper bodies for example, I am forced into every upper body I ever make having the same number of materials, or if I need to add an additional material to a group of meshes in the table I now have to add effectively empty/dummy materials for all previous meshes. It is not very scalable. Alternatively I could create a bunch of child COs that have one material each but as solutions go I really don’t like it.
I have attached new images for the material issue using Quinn from the third person project I have attached. Again just changing the order the pin is connected in will change the material output on Quinn.
Thanks for the help and look forward to hearing from you.
I just wanted you to know that we have been able to reproduce the socket issue. The issue looks like it only happens on PIE. We are working on a fix.
In regard to the issue with the Material Pin order. This has been fixed in 5.6. If you do not plan to move to 5.6 I can point you the exact commit that fixes it so you can port it.
My mistake, I got confused since the cube only moves once the viewport is focused. Ignoring this behavior (this is due to how the BP has been setup), I am unable to reproduce it. Tested with 5.5.4.
About the crash, “running the client in editor” do you mean Standalone? Could you provide more detailed reproduction steps? We are unable to reproduce it.
It will be closer to end of year that I expect to move to 5.6 so getting the commit for the material pin order fix would be much appreciated.
Thanks for the info about how to get sockets reflected in PIE correctly. I did confirm that after compiling the CO I was able to see the new socket locations reflected correctly in PIE. It is an extra step, but I’ll take it over restarting UE!
For the crash, I can get it to happen 100% of the time in my team’s project, however I have yet to get it in vanilla UE. I will report back if/when I can get repro in a way that you can see it.
This is an important concept to graphs. In Mutable, SKM and Textures has two modes (Passthrough and Non-Passthrough). You can see which one you are using because of the pin type and nodes (Passthrough Texture is a red pin with a arrow icon). Passthrough SKM/Textures do not allow operations (apart from switching) and use the original asset in the resulting SKM. In the other hand, Non-Passthrough SKM/Textures are compiled into Mutable format and allows you to operate on them. This is why you need to recompile the Customizable Object to see the changes.
Please, let us know once you have a way we can reproduce the crash. Unfortunately the callstack was not enough.