7/29/2012

Object Replacer Editor Script

In my last posts I talked about several asset workflow issues we encountered in our projects. Although Unity is quiet mature when it comes to asset (import) handling I showed some existing limitations and presented some editor script examples to solve these. In this post I want to address a "special case" asset handling problem which in the past has been dealt with manually or with a "quickly put together script for that purpose only".

As it happens we have to deal with huge assets from time to time which consist of dozens of child objects. E.g. consider a huge stardestroyer consisting of dozens or hundreds of elements attached to its hull like different laser cannons, antennas, cargo elements and so on. In our project these elements are individual prefabs (one per type) while the stardestroyer asset lacks all these elements on import. We handle the elements as individual prefabs to benefit from Unitys prefab instancing mechanism which allows us to centrally change object parameters of all instances. Furthermore it follows the divide&conquer principle.
The star destroyer asset has gizmos (e.g. empty object nodes or primitives) attached where a certain element should be placed. This is done during design phase so that the designer has full control over it. These gizmos need to be removed from the final stardestroyer in Unity and replaced by a new instance of the actual element prefab.
After doing this manually or in a quickly hacked script for some time I felt it is time to create a general "Object Replacer" script which allows to manage workflows like these. Hence I wrote an editor script which works as follows:
  1. The user opens the editor script window and selects a prefab (or scene instance) containing child objects which should be replaced.
  2. In a list below object transitions can be defined which specify:
    • an object name supporting wildcards to handle typical pre-/postfixes added along the pipeline automatically
    • the prefab which should replace the gizmo
    • the transformation type which should be applied, namely the *source* (gizmo), the *target* (prefab) or the combined transformation
Additionally the user can preview all matching objects of the current selection in a list at the right side. Although this might be a bit misleading sometimes because the actual replacement list might differ (see "Known limitations") this helps to quickly check if the intended objects are treated.
Finally following the workflow of the "Material Replacer" script the user can save and load the transition list to/from an xml file to streamline the process for reoccuring tasks.

I will uploade the code to UnifyCommunity as usual as soon as it gets online again (link will be updated) and think this class will come in handy for cases like described above.

Edit: The code is now located at UnifyCommunity.

Known limitations
  • The script applies each transition one after another from top to bottom. If an objects name would match with several of the transitions the uppermost transition in the list will be applied only.
  • If an object replacement is attached for a matching object it might be matched by following transitions and replaced again.
Solution for both is to use clearly distinctable object names for your source and target object(s)
  • If a matching object has children they are removed implicitly ignoring them for further processing.
Solution here is to ensure that the hierarchy is kept simple e.g. if you replace leaf nodes only

No comments:

Post a Comment