Unity works with Hierarchies of Transforms, these are 3d offsets from 3d root/branch points.
What if Unity has a soft or virtual transform link, where something can be attached to something else just as a normal transform but within a scene stored in a separate location?
This way related elements can be grouped in a scene by type for organisation.
It could also allow a soft or virtual transform link to inherit or not inherit it’s parents scale/rotation/position or elements of those attributes.
It might also give Unity a way to fix the nested prefab problem!?
I’m thinking he means something along the lines of the AfterEffects composition, which can be a partially composited scene. Imagine a space game where your encounters are saved as individual scenes, and then when you determine a given encounter goes there you just instantiate the scene.
But yeah. I’m not really clear on what he’s trying to accomplish, either.
I think he’s asking for a transform hierarchy that’s decoupled from the transform hierarchy. What he might really want is a way to organize a scene that’s separate from the hierarchy, but I have not had enough beer to even begin to make sense of an Arowx thread yet.
‘Soft attachment’. Make object b follow object a with a given ‘local’ offset relative to object a. Exactly like parenting does only they aren’t parented. This is useful in the case of using prefabs as it’s not always convenient to make things children of a parent that is a prefab, whenever you need to apply changes to that parent you end up combining the attached object into the prefab which is annoying.
Enabling GameObjects to only follow some parts of a ‘soft parents’ transform is something I do myself in a script. I get the camera prefab to follow the player prefab in x and z but not y. The camera also ignores the rotation of the player as my games is a 2.5D side scroller for the most part. The player can turn but the camera does not.
Organising objects separate from the hierarchy would be confusing but perhaps changing layers into 3 separate layer systems would be more useful.
Render Layers as used by cameras to figure out what to render.
Physics Layers as used by physics to collide objects
Editor Layers as used by developers to easily hide and show objects of an arbitrary group (not available in the engine at runtime).
Running out of layers or constantly battling to remember which layers should be used for physics and which for rendering is really annoying… And using layers to help with editing and level building is almost impossible as well because objects are usually complex and have many GameObjects in multiple layers to work correctly.
Edit:
One more use for ‘soft attachment’ is the ability to have the parent destroyed but the child remain. It’s often hard to make sure objects detach from parents before the parent is destroyed as doing the detachment in OnDisable or OnDestroy is too late and Unity won’t let you. An example of where I do this is with attached effects that I pool in order to speed the game up but the objects they attach to don’t pool so simply get destroyed. The attached effect checks if the parent is null and if it is then it automatically disables and returns to the pool.
He wants the scene hierarchy to be for organization, and be able to link transforms separately from the scene hierarchy.
We do this in our project to link rigid bodies with game objects. It’s a pretty basic script, just copy the position, rotation, and / or scale on late update. Scale can be a bit weird since it’s not possible to actual replicate the full scale hierarchy in all cases with out the full scale hierarchy… we actually just skip it. I also do it for character shadow blobs for our mobile games just tracking x&z and a forward axis with a fixed y height or traced position, kind of like @Antony-Blackett 's example.
Yup, he wants to parent the transforms but keep the objects separate. Sounds ok in theory (possibly? maybe?) but it would be an organizational nightmare imho. Too hard to identify and manage those links.
So… why not right-click your desired soft parent, create an empty GameObject under it, then drag the GameObject out of the soft parent and drag the soft parent into it? Now you can drag other objects into the same GameObject, organising them, and the objects aren’t really parented.
I mean, I do that all the time. Just for convenience.
OK say you do that for furniture in rooms and floors in a house, but darn it you need the house to be bigger or smaller.
With a soft link you could rescale the house keeping the relative positions within for the furniture and rooms but without scaling the furniture, just the rooms.
The traditional way you would have to remove all the furniture from the house, scale the house and replace and position all the furniture.
It would be even cooler if Unity had Binary Solid Mesh Operations, so you would not have to re-work all the doors.
Any game level or large enough game object to have sub-object can have similar scenarios in Unity.
IIRC (been a long time ago) borland delphi separated ownership and parentship. Worked more or less alright.
The idea was that objects that get destroyed when their owner is destroyed, but not when their parent is killed.
This has nothing to do with “soft links”, though. What you’re asking for is object not inheriting parent’s scale. Which can actually be tricky, depending on how transform hierarchies are organized.
You can also code “soft link” or “attachment to a point” via scripting in late update.
The issue here is circular link and position update possibly lagging behind if other scripts rely on Update().
Speaking of houses, I wouldn’t scale the house, but instead I would try to create wall-moving workflow, sims style. When you scale the house, you want furniture get bigger along with it, because scaling also changes wall thickness. When you move walls, scale of the house does not change, even though rooms get bigger.
Actually, in the proposed scenario, the obvious solution would be to script the house and make it manage furniture. It would be relatively simple.
You have to do that anyway. Like when you have a bed in the corner with a table next to it and a lamp on the table. Resize the room, the bed and table and lamp move. If you made the house bigger, the table is now too far from the bed which is too far from the wall and the lamp might not even be on the table anymore. If you made it smaller, they’re probably embedded in each other. Either way, all three of them now need to be individually moved.
If you had moved them out of the house first, they would probably still be multiselectable and you would just move all three at once until the bed was in the corner properly.
Personally, I’m not a huge fan of hierarchies and I personally prefer a relational approach. But the bestest place where hierarchies really kick ass is when a child’s position is relative to the parent… like ui and … tranform hierarchies.
Dealing with positional dependencies without hierarchy is really a pain in the ass.
OK Look at the RectTransform which was needed to allow flexible and proportional UI item placement. You could still have written a UI with basic Transforms and code but it would not have been as Artist and User friendly as the RectTransform is.
If you wanted you could even do UI without using the RectTransform and write the code yourselves, it would probably just take a few lines of code here and there.
My point is that a well designed and better name ‘Soft Linked’ Transform might make Unity easier and better to use.
The rect transform provides additional functionality for that specific component required to work in that context, information needed to facilitate layout. It is all necessary and used.
This other thing you are talking about is unnecessary, it is game feature material. It is too vague and broad, and obviously not critical. Adding unnecessary builtin overhead for a handful of developers who can’t or won’t write a couple of lines of code to handle trivial game specific functionality on their own, doesn’t belong on the engine level. It’s feature creep, tech-debt, and future dependencies. It belongs in the game, not the engine.
The single most valuable thing Unity does is cut through all the complexity so new developers can concentrate on making a game instead of understanding every last little thing and when or how they should use it.