Libgdx: Why Actor can't contain another Actor as its child?

Created on 17 Oct 2018  ·  4Comments  ·  Source: libgdx/libgdx

Issue details

Actor is scene node. Node should be like a folder in OS. Folder can contain other folders and be contained by a parent folder. In libgdx Actor is like a file in OS. File can be placed in a Group (Folder) but cannot contain other Actors (Files) in self. There is no simple way to make orbit rotation of object around another object (Without using extra math and wrapper objects or hardcoded object references). Or assign a Camera to Actor to keep their positions in sync (One of the problem described here #5409)

Version of LibGDX and/or relevant dependencies

1.9.8

Please select the affected platforms

  • [X] Android
  • [X] iOS (robovm)
  • [X] iOS (MOE)
  • [X] HTML/GWT
  • [X] Windows
  • [X] Linux
  • [X] MacOS

I have never seen similar design in other game engines (cocos2dx, unity, UE4 they're all allow you to nest your objects in other objects)

Most helpful comment

just consider Actor as abstract file and Group as folder. Then a Group can contains another Group and so on. Since Actor can be a file (like Image) or a folder (Group), it doesn't have to contains Actor.
This design sounds perfect to me.

All 4 comments

just consider Actor as abstract file and Group as folder. Then a Group can contains another Group and so on. Since Actor can be a file (like Image) or a folder (Group), it doesn't have to contains Actor.
This design sounds perfect to me.

@mgsx-dev Ok, just imagine. I want to make a composite character from multiple sprites of legs, arms, body, etc. You need to make double work, create actors and groups for them, attach all the actors to the groups and all the groups to other groups. Group contain the same data that an actor (excluding some) that causes extra memory allocation. Dropping groups and making actors nestable could make life easier. What's wrong with image having a child? It's just an image over its parent image

If you are concerned about memory usage, you probably shouldn't use scene2d actors for character parts at all. It is too heavyweight for that and was never meant for such high granularity use.

I just did a quick count, each Actor allocates at least ~11 extra objects and Group adds ~8 more on top - merging them would increase overhead for all Actors, including those which are leaf-only. And since most actors are typically leaf nodes, the memory usage would actually go up, not down!

Not to mention that if you intend to use transformations on your Groups, and it sounds like you do, your render performance will tank (assuming default draw implementation of Group and SpriteBatch), since each such transformed draw will cause an extra Batch.flush() -> draw-call.

scene2d was simply not designed for such use.

scene2d could have been implemented where all actors are groups, but this would make _every_ scene graph node more heavyweight, as Darkyenus mentioned. A group has children and transform matrices while an actor does not.

I want to make a composite character from multiple sprites of legs, arms, body, etc. You need to make double work, create actors and groups for them

If you want to worry about efficiency, there is no reason to use only Group and Image to do this. You can use a group for your body parts and draw what you need in Group#draw. If you want to use Group everywhere, you can. Separate actors and groups provides the best of both worlds.

scene2d was simply not designed for such use.

While I mostly agree, and for skeletal animation I would (of course) use Spine, it is possible to do quite a lot with scene2d before running into memory, CPU, or GPU problems. For example, at start up Spine creates 5291 non-group actors and 3713 groups. It's a desktop app, but ~9k actors and groups is totally fine. Rendering the entire UI takes only 13 batch flushes, due to the background and a few groups using clipping. CpuSpriteBatch can be used to reduce batch flushes if you have many groups with transform enabled.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

HoldYourWaffle picture HoldYourWaffle  ·  4Comments

someguy233 picture someguy233  ·  3Comments

chongbo2013 picture chongbo2013  ·  3Comments

centy picture centy  ·  4Comments

nrallakis picture nrallakis  ·  3Comments