koobas.hobune.stream
How can I make prefabs that don't break when models change?
I have read a couple of questions regarding the workflow of prefabs and model assets. I still don't get it. Is it supposed to be this hard to work with models? I can't seem to get anything done and I consider myself reasonably experienced in Unity so it feels kind of embarrasing. All the time I get problems with models being changed and prefabs not picking up the changes. Sometimes it feels like I am a card house architect in a perfect storm.
Currently we're using the approach of creating an empty game object, placing the model as child of this and make a prefab of the whole. We then never add any components directly to the model but let scripts do the work runtime. This works for mesh changes but as new transforms are added to the model, they are not added to the prefab. I also respect the solution offered with post asset processing but it's is sort of backwards having the model become the code and responsibilities. It works for basic things but as soon as things get a bit complicated you'd end up with a programming language embedded inside model names.
This workflow is, in my own words, rubbish (sorry, but it is horrible to work like this). I dont understand if this is some flaw in how Unity is designed, or a flaw of our understanding of Unity. I find our approach highly error prone and unreliable. Bugs creep in as expected transforms aren't available, sometimes nested deep in hierarchy. How are you coping with these changes? Are you just accepting the reality or have you worked out a way to cope with changes unintrusively?
The "best" theoretical solution I thought about was to have a script that executes in edit mode (for visible model during editing), which during OnEnable instantiates and parents a model so it always get a fresh model each run. It is not without problems, because it still means we can't touch the model in design time and it becomes awkward to update the prefab since you have to remove the model to ensure you won't save it to the prefab.
- The bottom line question is: How can I make prefabs that don't break when models change?
Thank you very much for taking your time reading this.
Update about how to reproduce our current issues in response to comments:
I don't have a model to spare right now but I might be able to post a full reproduction tomorrow.
- Create a model and import it to Unity.
- Create an empty game object and attach model as child to this.
- Create an empty prefab and drag the newly created object to the prefab.
- Alter the model (add a cube or something) and reimport it to Unity.
- Now prefab won't have the extra cube, but if you drag out a new model, it will have.
This is a minimal reproduction but you can imagine it becomes a bit troublesome if you have several prefabs with several scripts all accessing several models. On a small scale it is manageable but as your scene starts to grow it becomes more and more painful to cope with the changes in prefabs.
I don't fully understand the question (or have a solution) but would it be possible to provide a model and to describe, in detail, a sequence of actions that will cause the behavior you're describing? I don't work with imported models that much so I'm not really the person to answer the question, but I think for those that could answer it, a clear, reproducible example might help.
Interesting question, hopefully you'll get an answer. As impressed as I am with many aspects of Unity, asset management appears needlessly awkward.I've just started using prefabs as it seemed to be the best method to deal with instancing numerous duplicates, but if they are going to break whenever I update the mesh, thats going to be annoying.
Noisecrime, it is still much better than other alternatives but it is painstaking still. With prefabs you only need to update the prefab once for a model change, regardless of how many instances you have so it's not all bad. A problem arise if you make a special alteration to some instances, breaking the link to the prefab - then you have to hunt those instances down manually. But I think that is a rare situation in practice.
Jesse, the question is now updated. I hope to update it tomorrow with an actual executing project.
Unity's behaviour is intentional - it allows you to select which structure from a model to use in a prefab, with subsequent reimports keeping the same transform hierachy you chose. A lot of the time this is desirable, allowing much easier customization for multiple prefabs of the same model. The problem is that the fringe case (for the majority of users) of adding transforms to the model doesn't include the new bones, making things a little awkward.
Unity can't handle prefabs inside prefabs. It only updates the 'highest level" prefab.
What you're doing is taking the imported object (already a prefab) and putting it inside a new prefab. Unity assumes you've made changes to the imported object (which is usually correct in my experience) and by extension it assumes that you don't want Unity to be changing your new prefab based on the old one. As far as I know, there's no way to tell Unity to update 'child prefabs'.
What I've done in a similar situation is to put my externally-changeable objects inside my Resources folder (they're used in every scene so there's no overhead), then use Resources.Load to always get the new version.
That is, my Actor objects (which can represent anyone, player or npc) have the following:
var ragdollResource : String = "Actors/Player/V1"; private var ragdoll : GameObject;
function Start() { ragdoll = Instantiate( Resources.Load( ragdollResource ), transform.position, transform.rotation ); }
Yeah, this is basically the theoretic solution I expressed in my post. While I appreciate your help, and I find it valuable, I see a problem with the object not being visible in the editor. It becomes counter intuitive with an invisible working set. Basically this go back toward more traditional development and it isn't that bad. It just feels like it's not the "unity way" of doing things. Also it becomes hard to add components (at least "visually") to the object. $$anonymous$$y $$anonymous$$d got excited thinking about editor script possibilities thought! Thanks a ton for your interest!
Yes, counter intuitive, misleading and not right... hopefully that will improve over time.
