Scene Graph

Post reply
2 favourites
From the Asset Store
Destruction Scene Elements
$10 USD
3D Rendered, High Resolution elements to create an apocalytic scene or war zone
sbucci's avatar
sbucci

  • Introduction

    As some may be aware of, the latest beta introduced the first pieces of Construct's own implementation of a scene graph.

    Some people are excited, for good reasons. But I read from quite a few that have no idea what the fuss is all about. Allow me to explain...

    First, what is a scene graph?

    Scene graph is a fancy name for a tree structure, in which a root parent object can have children and then those, children of their own. A quick search in Google let's me find an image to convey this, here it is.

    In the context of Construct, this new feature allows you to establish that kind of relationship between plugin instances (at the moment only Sprite instances).

    With that hierarchy created, it is possible for the runtime to calculate translations, rotations and scaling of a child based on that of it's parent.

    • Example 1: a parent is translated in X for 100 pixel, all it's children will follow to ensure they maintain their relative position to the parent.
    • Example 2: a parent rotates then all children will adjust their positions to rotate around the parent's origin as well as adjust their own rotation.
    • Example 3: a parent changes it's scale, all children will adjust their positions as well as scale in response to the parent's changes.

    The most common case would we for any of this things to happen at any given point and Construct will calculate the correct position, rotation and scale for all the instances involved.

    Keep in mind that all child transformations occur around the parent's origin. I think this is better demonstrated by this small example project.

    https://www.dropbox.com/s/etwun316sox4lne/SceneGraphExample.zip?dl=0

    New runtime actions

    The latest beta introduced 3 new actions, Add Child, Remove Child and Remove From Parent. To make things easier on ourselves, at the moment these are only supported on the Sprite plugin, as the feature matures and we iron out bugs and implement user feedback more plugins will be supported.

    • Add Child: This one is used to add a child to another instance. It's pretty straight forward. When an instance is added as a child of another one there is no immediate change, it is only when the parent is modified that the child will respond accordingly.
    • Remove Child: This is pretty straight forward as well, remove the specified child from the picked parent.
    • Remove From Parent: This is similar to Remove Child, but allows you to remove the picked instance from it's parent, without knowing to which instance it belongs.

    I think this is it for now, I will update this thread as more features are added. If you have any questions I'll try to answer them here.

    Tagged:

  • This is awesome! :o

  • What about picking, will it work similarly to containers?

  • There isn't anything implemented yet, but containers do sound like a logical choice.

    Chances are high that when a hierarchy between instances is established, all the instances involved will be automatically added to a container, so picking will work as expected from that point onward.

    None of this has been tried out yet, but it sounds like it should work.

  • wow, so cool. nice developing.

  • Diego Thanks for working on this cool feature, well done! I didn't see this post, so I went ahead and tried to make a single object w/ different instances have parent / child relationships between the instances. Using the old two Family trick which Ashley mentioned seemed to work, but I am interested to see if you are going to approach it in a different way, since this method feels a little clumsy.

    I used instance variables to name a parent and a name of the instance. On start of layout I use this variables to assign the child / parent relationship.

    Event sheet:

    Here's the project:

    gofile.io/d/yGGaO3

    Automatic containers for picking sounds great also. Would you pick from top of picked element down tree to leaves or would picking also transverse up the tree too?

  • Pick one, pick all. Seems like the best way to go.

    Just because it's in the SOL doesn't mean you have to use it.

    Definitely don't want something like "For Each Child" winding up in there however.

  • Keep in mind is that when a parent instance is destroyed, it will destroy all of it's child instances recursively.

    Is this necessary? Maybe it would be better to add a setting Destroy with parent=Yes/No in "Add child" action?

    Also, I think there will be a lot of confusion about using scene graph and containers. As I understand, scene graph will allow to create relationships to/between multiple instances of the same object. Say, one Body sprite to two instances of Leg sprite. This is not possible with containers. And what will happen if I add Foot sprite into a container with the Leg? Will Foot instances be picked when a Body is picked? Will feet move/rotate/scale with legs?

  • Is this necessary? Maybe it would be better to add a setting Destroy with parent=Yes/No in "Add child" action?

    There's two ways to look at this. If they don't get destroyed with the parent, then they would need their own destroy action, if it's the "pick all" way. Then if it was set to destroy all like a container, then I would expect the "remove child" action to work in the opposite manner.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • One suggestion: Indexing of children.

  • Something to consider is how z-sorting will work.

    A scene graph object comprised of multiple individual parts should probably be sorted as if it was a single object, but there still needs to be a way of sorting the drawing order for the components of the graph itself, an example would be an arm or leg that needs to be in front of the torso walking to the left but behind the torso walking to the right.

    In Godot there is a property for every "renderable" object called "Show behind parent" which is pretty self explanatory, it changes the render order for this one object to be behind its parent object (children are usually drawn in front) this property is usually enough for pretty much every use case as far as i can tell.

  • Cool stuff. Looking forward to experiment with this

  • Does this plan currently extend to being able to create presets of hierarchies of objects in editor, naming them and using them in editor and real time?

  • Mikal I think what you did to build the hierarchy would be pretty much how it would work... as far as a pure runtime actions solution goes.

    What you did with instances variables will eventually be covered by a tool in the editor which hopefully will be more friendly, but ultimately will do the same as you did, tell each instance who is it's parent. Later that information will be exported to the runtime and you won't even need to set it up in events, the whole thing will be built automatically to mimic what was configured in the editor.

    The editor tools are still a bit far way, so for now this is the best we have.

    I do find the two family trick a little bit weird myself, I wonder if it could be promoted from hack to feature just for this purpose... we'll see how that turns out.

  • dop2000 newt

    The next beta adds the option to choose what should happen to a nested child if it's parent is destroyed. It will either be destroyed with the parent, or just detached.

    As for containers, as I said, nothing has been even tested, just don't take what is said in this thread as a final answer. The next beta introduces a few new conditions to pick parent's and children so that will give more control.

    We are trying not to get ahead of ourselves, because it is not clear what the best approach is in some cases, we are trying to cover the basics and only after that is working look into the issues that people might have from actually using the feature.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)