Parenting/Nesting
-
If you mean this:
It seems a long ways off.
I can suggest a far easier and faster solution, a behaviour, in the Object category:
"Is Child of...."
Left side of this behaviour would default to the currently selected object, right side the user must pick an object to be the parent. DONE!
ADDITIONALLY, if you want fuller functionality:
"Attach as Child of..."
And
"Release from Parent"
-
We considered making a hierarchy system through behaviours only. But in the end decided against it. We figured the feature would be too hidden and difficult to use. So us investing the time to develop would not result in mass adoption.
Where as a visual approach could be use more widely.
Since our resources are limited we need to focus on doing things that will affect the majority of the community, and also avoid doing things over and over. If the behaviour routedisnt worknout, it would end up delaying the visual system even further.
That being said, maybe @Hamed can chime in and see if it’s an “easy” addition.
-
I beg to disagree:
The underlying code (in your engine/system) doesn't change, you simply have two ways of initiating and releasing parenting.
The first is much easier to implement, you simply add two behaviours, one to attach an object to a parent, the other to release it. For those that need it, it will be welcomed and understood in that manner.
For everyone else, you can now take your time figuring out the visual interface and interactions of a layers palette for doing the exact same thing...
-
Our physics engine makes this kind of thing tricky. So doing it through behaviours isn't as easy as it seems. We really want this feature soon.
@Hamed I understand that!
However, most of the time these sorts of things are done it's a graphical hierarchy that's being created, wherein the base (parent) might have physics, but the children are only visual adornments, without physics.
If they are physical objects, then they'll be welded or otherwise joined with physical relationships (joints).
Anyone trying to use parenting AND joints is going to get into a huge mess, so this shouldn't be permitted.
Does that make it easier?
-
It makes it much easier, however, I need to look into this a little bit further because I feel like there are other implications of doing it this way.
-
@Hamed No worries. Hit me on email and I'll lay out a look at how other engines deal with the problems of virtual parenting versus joints and physics.
@Deeeds Here's an initial attempt to describe the relationships between virtual and physical:
The best way to describe this problem uses the the lexicon “Scene Graph” and “Physical Structures”
By Scene Graph I mean entities and components in a hierarchy of relationships to each other (parenting) and in layers (which can also be parented to one another) as groups.
It should be (ideally) possible to move an entire layer’s contents by simply moving the layer. A layer is, ultimately, the parent object for all of its content. Moving a layer that’s a parent of another layer also moves that child layer’s transform accordingly, and all its content.
In this kind of world, there is nothing (so far) better than a layers palette similar to what we use in Photoshop or After Effects, for simply exposing this and making it all visually editable for end users.
Physics structures are made like bodies, their relationships defined through joints (ideally) performed in a live visual editing space in which it’s possible to make physical connections and experiment with the movements and effects that result from these connections. \
Whilst physics objects exist in the Scene Graph, their layers are defined by their top most object, their parent object. So a ball, for example, is an individual layer.
A Mickey Mouse character might have its torso as the parent, and therefore being its “Layer”, and within that layer is its head, legs, arms and neck.
The Mickey Mouse Torso Layer can be nested in a Scene Graph layer, since any movement of this parent SceneGraph layer will result in an equal movement of all child elements in terms of their relative transforms.
But that’s about the extent of relationships between the Scene Graph and Physical Structures.
Anyone wanting to parent a group of Scene Graph objects to a physics object must give up on the idea of the Scene Graph child and its children having any physical attributes, as this will create chaos. Or rigid joints prone to breaking and creating (very likely) unwanted physical activity.
-
Oh is this where multiple objects join together to basically make one? If so, this would be awesome if it happened, basically just a physics attach without the squishyness. The only way I get something similar to this is constantly having an object move to its parent on a 0 second timer and on an anchor, but obviously then the child objects don’t have working physics.
-
Oh is this where multiple objects join together to basically make one? If so, this would be awesome if it happened, basically just a physics attach without the squishyness. The only way I get something similar to this is constantly having an object move to its parent on a 0 second timer and on an anchor, but obviously then the child objects don’t have working physics.
@Aidan-Oxley Yes, that's the result.
What's actually happening is the passing through of the transform of the parent (world space) to the children.
So position, rotation and scale/skew of the parent always influence (or get passed through) the children.
In most engines the transparency is also passed through, too.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login