Rendering child behind parent

[norcrel]

Hello, is it possible to render a child behind a parent? The reason is because I have a custom paper doll system, and the torso needs to be in front of an arm, but the arm is a child of the torso.

 

I tried to find another thread on this but couldn't find one that exactly matched. It seems like the best solution is to have a group and add all the sprites to that, but then the transforms based on local positioning/rotations/scaling gets really messed up.

[rich]

Use a Group. Children of Sprites will always render on-top, as is the way the display list works.

[rich]

The Group itself can be scaled, rotated and transformed btw. The children of the Group will offset themselves from that accordingly. It's worth adding that the same issues you'll deal with re: local transforms with a Group + children are identical to those faced with a Sprite + children (as essentially it's the exact same underlying classes)

[norcrel]

Thanks for the help

 

Doesn't that mean that I essentially need to manually link and calculate transforms for the children of children? For example if I have this transform hierarchy I want to make for a guy holding a stick with a ball attached:

 

Root

|-- Torso

   |-- Arm

      |-- Stick

         |-- Ball

   |-- Head

      |-- Hat

   |-- Leg

 

And I want to swing arm with the stick-ball (like a flail), so I basically need to manually calculate the inherited transforms all the way down? What you're suggesting is an hierarchy that looks more like this right?

 

Root (Group)

|-- Torso

|-- Arm

|-- Stick

|-- Ball

|-- Head

|-- Hat

|-- Leg

 

I understand that I can run root.sort('z', Phaser.ASCENDING) to then sort the rendering order, but I would really like to avoid replicating phaser's transform hierarchy since that's just asking for unclear code when parts of my game use it and other parts don't.

 

Thanks again for the help, just trying to make sure I understand what needs to be done.

[norcrel]

Ok, I looked into the PIXI renderer and I see why its constructed the way it is. Its possible to introduce a depth sort for the renderer but that comes with an impact that every frame you're looking through and sorting the entire scene hierarchy as opposed to just children at the same level in the hierarchy. That sort of performance impact makes it questionable as a feature, and so that feature might not be a great usage of development time on the engine level.

 

What I'm thinking of doing next is creating the hierarchy with simple empty objects and leverage the parent-child transform system, then applying the global transformation to a flattened group that will contain the sprites that make up the object, sorted by my own depth information. I'll basically have to create two objects per sprite in the paper doll animation, but this is the best I can think of right now.

[rich]

Don't forget you can nest Groups within Groups.

 

Alternatively you could use the PIXI.DisplayObjectContainer (which is what a Group is) directly and just manage the children within that yourself - with a tiny number of them it should be a fast process. You can then just position the children as required based on the parent, you won't have to calculate the whole transform for the whole body - just the parts that matter.

[shmikucis]

For one of our games we have created a character consisting from multiple body parts and animated with tweens. If it helps you then there is a time-lapse video 

 

 

I would do it following way:

 

Root

|-- Torso

|-- Arm group

  |-- Arm

  |-- Stick

  |-- Ball

|-- Head group

  |-- Head

  |-- Hat

|-- Leg