If a Mutable Object has Child Objects, all of the parameters are added into the parent mutable object, even if the child isn’t set. This can cause problems if you have a parameter of the same name in two child objects. Because Mutable uses strings as parameter names, modifying or getting the value of a parameter with a non-unique name will cause the Customizable Object Instance to set the value of only the first parameter with a matching name. This can cause problems, as it may be the incorrect parameter - for example, an enum parameter with a different set of values. Additionally, the wrong parameter may be used when generating the object.
I tried to modify the parameter that had a Matching Id (Guid) to the one I wanted to edit. This worked, and allowed me to edit the correct parameter, but this did not solve my problem, as the generated skeletal mesh simply used the first parameter it found. Setting all parameters matching the name is also not a valid solution, as you may have two parameters of the same name being used simultaneously.
For now, my solution is to add an asset validator to ensure all mutable parameters in a Customizable Object (and its root) are unique.
Are there plans to change mutable to support non-unique parameter names? If not, should there be validation to ensure that all parameter names (including those included from child objects) are unique?
Create Third Person Project (for Skeletal Mesh), Enable Mutable Plugin.
Create the parent Customizable Object, with Mesh Component and Object Group nodes. Set the Object Group Type to “One or None”.[Image Removed]
Create a child Customizable Object, which is attached to the parent Customizable Object’s Object Group. Add Mesh Sections to the parent’s Mesh Component.[Image Removed]
In the child Customizable Object, create an enum Parameter. Here I set the Tint value of a Mesh Section from Color Constants according to a Color Switch on a “Color” Enum.[Image Removed]
Create a second child Customizable Object by duplicating the first. Rename the Base Object, keeping it attached to the parent. Ensure it’s enum Parameter’s name is the same as that in the other child Customizable Object, but give it more values.[Image Removed]
Compile and save the parent and children Customizable Objects.
In the parent Customizable Object, try and change the Parameters, watching for changes . The Children parameter will change, but the color parameter will have no effect. This is because the Parameters have the same name, when one is set it may not necessarily set the correct one, or the correct one may not be read from when generating the instance.[Image Removed]
Yes, there is an experience bug here where when you change the children, the index gets reset to 0, and the name displayed will not match the internal name of the enum. The primary design is that child graphs are intended to import properties from the parent or from sibling graphs. For each child graph that is setup, it’s best to setup the variable in the parent, export it, and then import it on the children.
[Image Removed]
I’ve logged a bug for this case, and I will also suggest some potential warnings or validations. In terms of what is the future intention here, this particular version of this case is interesting because you’re adjusting the enum list and basically blocking what is available for that body type case. Depending on your setup needs, I would suggest that you allow all options, but block those that are available in your UX for that particular character based on external data. However, hopefully, with the UX fix, you’ll be able to detect and read it through the customizable graph if necessary.
Thanks for looking into this issue and logging a bug, and thank you for the advice concerning importing child properties from the parent. It would be useful to have this mentioned in the Mutable Tutorials page.
Concerning the setup advice, the setup currently used is based on the Add Mesh-Based Cloth Pieces to a Character
I was treating the parent Graph as containing Object Groups for each clothing “slot”, e.g. character mesh with groups for shoes, trousers, and so on. I’d then treat the children Graphs as representing a specific skeletal mesh of clothing to fit in a certain “slot” (object group), e.g. sneakers. And then the child Instance would represent the values for a certain article of clothing, e.g. red sneakers. I would then use the Instance of the Child Object to set the appropriate values on the parent Object Instance, as we want the end user to chose between different clothing items as opposed to customizing the properties of each piece.
If I understand you correctly, then you’ll probably want to structure your data a little differently. First, if you intend to use Customizable Object Instances as an object that could be passed through a main Customizable Object, that is not possible technically. Typically, a Customizable Instance represents a full character graph with all the options set up in a specific way that you intend to reuse.
Suppose you mean it more as a representation of a specific configuration of data in a child object Customizable Object. In that case, you can do that, but it would be more like creating two customizable objects, a Red Sneaker and a Blue Sneaker. Inside the Red Sneaker, you build your graph, but instead of using a variable, you would use a colour constant for the colour red. Then, in the Blue Sneaker, everything is basically the same, but you would use a blue colour constant. The downside of this approach is that you’re not being efficient with your graph setups and planning for potential reuse with minor tweaks.
Now, which approach you take could depend on how you want to store your configurations. Are you storing the item as Sneakers that are Red, or the Red Sneaker?
“as we want the end user to chose between different clothing items as opposed to customizing the properties of each piece”
Because you’re suggesting the latter, my suggestion above should work well at the cost of code duplication. But if it might be beneficial for the future to be efficient and flexible with your graph creation, then use some other configuration technique to make your “Item Definition” of theRed Sneaker that can be referenced in UI and set up for optimal storage for a backend character system or inventory or something. Then that Item Definition is what creates the limitation of the Red Shoe and the Blue Shoe, but systemically, it pumps in the predefined parameters when generating your Customizable Object. If you are using an online service backend to store your players’ equipment choices and what is available to them, then more than likely, you are already preparing some version of data that looks like what I’m mentioning as an Item Definition that you would work well with.