How to 'clone' a Scene Graph at Runtime?

0 favourites
  • 6 posts
From the Asset Store
Antisuspend Plugin for Construct 3 prevents the runtime from getting suspended.
  • Diego

    The scene graph features are great, the additional ACEs and the new editor support.

    How do you suggest to 'clone' a Scene Graph at runtime. For example if I have the Skeleton model setup in the editor once, with parent child relationship and placement, during runtime, how would I create another version and place it somewhere else? I would hope that I could create a new Scene Graph based on the particular root instance (perhaps through UID, or some other picking, like an instance var, etc.)

    Since scene graphs can have multiple instances of the same object, it does not seem like Containers work for this (we have tried and I have not yet seen a successful implementation using containers, especially with multiple instances of the same object in the Scene Graph.)

    Any suggestions or ideas, or is this a new feature request?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Maybe save the data/config to a json and then allow events to load the information on runtime?

    (something similar to the json created in Spriter/Spine)

    Hopefully allowing to create/edit/save "states/animations" of the skeleton to allow animation down the line.

  • There is still no easy way of doing this.

    As an experiment you could try saving the JSON information of the root instance, and use that as a template to clone the whole hierarchy. Each instance holds a list of all the UID's which are it's children.

    So, you could:

    1) Clone the parent

    2) Look up all the UID's of it's children (get the JSON from the AsJSON expressions)

    3) Make clones of the children, add them to the cloned parent (using the existing runtime actions)

    4) Repeat steps 2) and 3) for each child until the whole tree has been cloned.

    I am not going to go into the specifics of the JSON format C3 uses, because all of this is not a great idea to begin with :P

    There could be hidden issues I am not foreseeing. I can already see that before setting the JSON for each clone you would need to NOT pass any hierarchy information, because it would be for the old one.

    I guess it can be an interesting thing to try out, but I wouldn't recommend it.

    I am thinking the runtime action that is going to end up doing all of this work will do pretty much what I just described.

  • Just to offer some thoughts, I would prefer save/load/delete scene graph actions, instead of a 'clone' action. To further elaborate, the downsides I see to a clone action are:

    - The scene graph would have to exist in the layout at the time it is cloned.

    - There would be no simple way to share the scene graph across layouts.

    - The scene graph would be cloned with non-inherited transformations that have been applied to children after the scene graph was created, i.e. it would difficult if you wanted to re-create the scene graph in it's original state when it was first created.

    I would like it if we could 'save' the scene graph data to JSON or memory in it's current state using a string based 'tag'. The scene graph data would be saved at the global level so it could still be accessed when switching layouts. In the editor we could also store this 'tag'. The 'load' action would take the 'tag' as an input to create a new copy from the scene graph data. Finally, for memory management, a 'delete' action to remove the scene graph data corresponding to the input 'tag' (not ones created in the editor).

  • I thought you would be able to just setup the scene-graphs in the resource layout.

    It would then save the data and be available in the rest of the project similar to when you want to setup object variables for a project.

    Reading DiegoM post i realized Construct doesn't really have a scene-graph "entity" with all information incorporated. Instead we have the parents with the info of their children, and then the children with the info of their applied transforms.

    Hoping that what he is planning to implement will allow something similar to setting up the objects on the editor, pick one of the objects and allow to save the info of all connected objects to a json.

    Then at runtime you would be able to load the json and create the objects and connections it describes.

    Maybe create one of the objects at the expected position and then be able to "inject" the json information.

    Another aproach would be to "upgrade" containers to allow setting and saving the relations of it's objects like mikal tried?

    (though you would have to keep single objects for similar parts with different positions/connections since it doesn't allow duplications)

  • I'm just using a function since all my groups will be made the same way.

    This is a prefab. It's been on the wish list since the beginning.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)