Prefab sub-objects orientation

[Josh]

Currently, the position, rotation, and scale of sub-objects in a prefab is stored for each scene. If you have a prefab that contains a door frame and door, for example, you can place the prefab and then make the door opened or closed, and that new orientation of the door piece will be stored in the scene. If you edit the original prefab file, other properties will update when the scene is reloading, but changing the position of the door piece in the prefab file will not affect the subobject in scenes where it has already been placed.

The other way of doing this would be to always get prefab orientations from the prefab file. This means if you have a prefab that is an assembly of parts, you would not be able to adjust the position or rotation of any sub-object in the editor, because it would be locked in place, relative to the parent. The only way to make the door opened, for example, would be to unlink the prefab, after which it will not refer back to the original prefab file, and will not get updated if anything in the prefab is changed.

Which do you think is a better design choice for the majority of the time?

 

[Monkey Frog Studio]

Why does it have to be either/or? In other engines with prefabs, you can change the children of a prefab (scale, position, and rotation) and things like doors can still be made to open/close. It seems to me (and I may not use the correct lingo here, so please forgive in advance) that a prefab should use some kind of 'local' coordinate for its children and any changes made to the actual (main) prefab would propagate to all instances based on that. 

If it has to be either/or (as you describe above), then I would opt for the second one. Then I would create prefabs only of static objects and individually place non-static objects, like doors.

[Josh]

 

7 minutes ago, Monkey Frog Studio said:

Why does it have to be either/or? In other engines with prefabs, you can change the children of a prefab (scale, position, and rotation) and things like doors can still be made to open/close. It seems to me (and I may not use the correct lingo here, so please forgive in advance) that a prefab should use some kind of 'local' coordinate for its children and any changes made to the actual (main) prefab would propagate to all instances based on that. 

Uhhhh, what? That sounds like two contradictary things:

1. Prefab sob-object orientations should be unique, stored in the scene. You move a sub-object of a prefab in the editor and it stays moved.
2. Prefab sub-object orientations should always be the same relative to the parent in the prefab hierarchy, and changes to the prefab file should show when a scene is loaded.

You have to choose one or the other. Currently, the first is what the editor does.

[Monkey Frog Studio]

Again, I don't have the proper terminology. But to keep it simple (I hope), in other engines, like Unreal, you can adjust the main prefab as you please and these changes propagate to all instances. You can still have moving doors as part of the prefab. In fact, you can attach the script there to the door in the prefab. 

[Josh]

Moving in the game is no problem, I am talking about moving the object in the editor.

[Josh]

Does that make sense?

[Monkey Frog Studio]

Thanks, Josh. I believe so. 

[Monkey Frog Studio]

I wasn't able to attend the Saturday live broadcast, so I wanted to add a thought after listening to it on YouTube:

Prefab instances should be treated like models or a single object in a level/scene. This means that, unless disassociated from the master prefab, the entire instance of a prefab is treated as a whole. The instance of a prefab gets moved about as a single item. In order to change sub-objects in all instances, you would have to access the master prefab and make changes there, including translation, scale, and rotation. This, then, would propagate to all instances in all levels/scenes. And, as you've indicated, you can disassociate any instance to turn the WHOLE into PARTS.

One use for prefabs like this for things like greyboxing (setting up temp objects to test a level's game flow). Then, once more finalized, the prefab can be changed to reflect finalized models, etc.  

I hope this helps.

[Josh]

Interesting vote results. I would have expected people would agree with you.

Usually if you phrase something in terms that sound like functionality is being restricted, people react against it.

[reepblue]

I still say we should still have something like the Source Engine instance system. 

https://developer.valvesoftware.com/wiki/L4D2_Level_Design/VMF_Instances

https://developer.valvesoftware.com/wiki/Working_with_instances

If prefabs are going to be left flexible, then I want a system where I can make objects as map files and expose the I/O and some entity values to the main scene. the flow graph communications should also still work from the instance. 

[mdgunn]

On 1/18/2026 at 12:44 PM, Monkey Frog Studio said:

One use for prefabs like this for things like greyboxing (setting up temp objects to test a level's game flow). Then, once more finalized, the prefab can be changed to reflect finalized models, etc.  

As MonkeyFrog mentions I think this greyboxing/prototyping subject could be a large part of  the issue.  This is my preferred way of trying to work and it feels like Leadwerks should support it well . Brushes can be effective as  simple objects. My winter game had 71 objects based on brushes and no 3d meshes. This SHOULD be where some of the Leadwerks FUN is, and it almost is, but then it feels like it doesn't work out and gets painful (...so...basically the opposite of fun).  However it feels like it SHOULD work and should only be a checkbox or menu item away but currently it feels like a bit of a battle.

There may be 2 broad sets of users. One set may be using more of a greyboxing/prototyping users approach. The other users probably use more predefined 3d imported models with well defined subobjects.  Prototypers are going to be composing objects with parts which are not yet set in stone as well defined subobjets and for whom it is more important that updates carry to children.  The other people have objects more often set in stone so want to retain sub object transforms. 

Would it not help if people could CHOOSE to pull the master prefab to the instance again. Part of the issue is that the manual way, which I suppose is the current 'solution' is to delete, re-add, reposition, which feel like no solution at all.

Seems there should be other options here.  Do neither of these work?.....

'REPLACE PREFAB' CONTEXT MENU ITEM: Allow a user to replace a prefab with another prefab. If it defaults to assuming the current filepath then it acts like an instance re-sync but you can change path to be a different object altogether if you want. Retains transforms that previous prefab has so it is same scale, orientation as before at top level node but actual sub-objects are reset (unless there is a way they can be matched).

'INSTANCE OUT OF DATE' UI INDICATIONA AND 'RESYNC ONE/ALL' CONTEXT MENU ITEM: There may be more complicated ways to do this but the basic idea is that Prefabs can tell when they are not in sync with the master and indicate this (by colour etc)  and the user themselves chooses if they want to take the parent again (they will lose transforms unless this can be carried through).  Couldn't there just be a guid or hash (based on file content or something) in the master prefabs and the instance get given that GUID/hash when created and when the master is resaved it gets a new GUID and the editor can check prefabs (based on matching filepath) and indicate in UI the prefabs where their GUid/hash does not now match the master prefab. Maybe when updating one there is additional menu item or checkbox to replace all. Hopefully this fits with UNDO system and you can step that action back should you notice you wanted only some to be affected and you can then do individuals.

Maybe a plugin script thing could do one or both of these but most users are likely to not know how to deal with that.

The source engine stuff sounds good too but initially maybe there is some simple option where you can just see an instance is out of date and pull again if you want to would help. Just flat out replacing a prefab with same/other seems useful to me as just a general option also.