What about Transform/Parent?

[stupot]

Hi,

Just had my 1sy proper quick play with with Phaser3.  I notice that the traditional scenegraph approach for transform inheritance was dropped earlier in the year and now runs with single flat display list.  Is that right or have I got the wrong end of the stick?

If this is right, then how do we now have a child object whose transform is offset from a parent object?

Cheers, Stu

[rich]

This is correct.

Transform inheritance caused so many problems in v2 we questioned the need for it at all, and ultimately removed it.

The resulting display list calculations are significantly faster, but more importantly, depth sorting is now trivial, regardless of the level.

It doesn't mean you cannot create a Game Object that directly influences the transform of children, as you'll see when we work on the bone / skeleton parent classes, but we're not supporting it as 'standard'.

[stupot]

37 minutes ago, rich said:

This is correct.

Transform inheritance caused so many problems in v2 we questioned the need for it at all, and ultimately removed it.

The resulting display list calculations are significantly faster, but more importantly, depth sorting is now trivial, regardless of the level.

It doesn't mean you cannot create a Game Object that directly influences the transform of children, as you'll see when we work on the bone / skeleton parent classes, but we're not supporting it as 'standard'.

ok, got it.

The biggest speed optimisations I made to a version of Phaser I used was to bypass a lot of repeated scenegraph traversal for the functionality I didn't require, so I can see why this has been done, but it'll leave a functionality hole for many.

Sounds like the skelly-bone classes are what I'm looking for, not a native/global performance hog, but something available when needed, any idea when dev on these begins?

 

[rich]

It will undeniably create a pain point for those who were used to using 'addChild', but given how many issues doing that caused in v2 (with things like physics bodies screwing up, tweens going awry, etc) I'm not expecting it to be that significant of a fallout. Some devs will need to move elsewhere for sure (i.e. just go to Pixi v5), but I learned a long time ago it's impossible to please everyone.

I can't commit to a skeleton class timeframe as its outside of the Mozilla schedule, but we've discussed it here and have a good idea how it'll work, so I'm confident what we have at the moment is flexible to cope with it when added. Support for the likes of Spine is high on our priority list.

[stupot]

 

47 minutes ago, rich said:

It will undeniably create a pain point for those who were used to using 'addChild', but given how many issues doing that caused in v2 (with things like physics bodies screwing up, tweens going awry, etc) I'm not expecting it to be that significant of a fallout. Some devs will need to move elsewhere for sure (i.e. just go to Pixi v5), but I learned a long time ago it's impossible to please everyone.

I can't commit to a skeleton class timeframe as its outside of the Mozilla schedule, but we've discussed it here and have a good idea how it'll work, so I'm confident what we have at the moment is flexible to cope with it when added. Support for the likes of Spine is high on our priority list.

Looks like I'm going to have scratch a little deeper than the surface, conceptualy Phaser3 looks to be quite different to Phaser2.  I've a few different ideas about how parent transforms could be implemented and applied only to required objects but I need to get my head around the new P3 internals first.

Any pointers or suggestions you might would be useful now.

[rich]

Sure, so each Game Object has a Transform component (found in gameobjects/components/Transform) which is a collection of properties and methods for setting things like scale, position, etc. You could take this component and then create your own based on it, that iterates property changes down through children. You'd then take one of the Game Objects, such as Sprite, and use it as the template for your own (ParentSprite?) and where it adds the current Transform component in the mixin, swap it for yours.

There is a TransformMatrix class you could use to help with matrix math too (Game Objects don't have an instance of this by default, but yours could).

[stupot]

Thanks @rich sounds like a good plan, that's given me some food for thought.