Fedor Posted May 16, 2018 Share Posted May 16, 2018 Is there a way to keep a child on it's original scale when scaling the parent object? jonforum 1 Quote Link to comment Share on other sites More sharing options...
ivan.popelyshev Posted May 16, 2018 Share Posted May 16, 2018 There are no solutions for that baked in pixi. You have to make your own transform that ignores parent transform. Its not newbie material but its possible. Quote Link to comment Share on other sites More sharing options...
jonforum Posted May 16, 2018 Share Posted May 16, 2018 I'm so much looking for a ways to do this thing. The logic would pixijs have a property liked called "'death'". Same as a 2d Physics simulator. Example here in AE and newton the death will disable parents influence of child's objects from the parent physic scene, but also from kinematics scale,position .... In pixi, you need make a special update for stabilise the child influenced by parent. And you will also need to deep understand how it update, that are very hard. It not very performance friendly. I not found other solution from my side!. in AE with newton, you can choose what kind of parent influence you need for your children. Tha are very cool. i can wait to see pixi have a similar feature for control parent influence. Quote Link to comment Share on other sites More sharing options...
Fedor Posted May 16, 2018 Author Share Posted May 16, 2018 I could also keep the text apart from the object, but then I would need the screen coordinates of the object and move the text thereevery update. But the DisplayObjects have no method to get the screen coords, or I must be overlooking something... Quote Link to comment Share on other sites More sharing options...
jonforum Posted May 16, 2018 Share Posted May 16, 2018 28 minutes ago, Fedor said: I could also keep the text apart from the object, but then I would need the screen coordinates of the object and move the text thereevery update. But the DisplayObjects have no method to get the screen coords, or I must be overlooking something... it work only if you now hace too mutch obj. if you need update 200 or more obj like that, you will have a strange decal between synconise update. You can see here a very old prototype, but if you look picture. You will understand what can happen if you have too much obj to synchronize without the same parent. You will have a strange picture flicking Quote Link to comment Share on other sites More sharing options...
timetocode Posted May 16, 2018 Share Posted May 16, 2018 I'm not sure if this applies for what you're doing, but I've done player.scale.set(3, 3) let item = new PIXI.Sprite.fromFrame('sword.png') player.addChild(item) player.itemInHand = item player.itemInHand.scale.set(1/3, 1/3) This example is pretending that I've scaled the player artwork up 3x, and then added something called `itemInHand` to the player which I didn't want scaled up, perhaps because I had already drawn the object large enough. So the object is scaled up, but one its children is scaled down, just to undo the scaling. The general pattern is parent.scale.x = n; child.scale.x = 1/n; not that I've ever applied such a thing generally, only ever explicitly in corner cases. I'm also using a centered anchor (obj.anchor.set(0.5, 0.5)). Quote Link to comment Share on other sites More sharing options...
Fedor Posted May 17, 2018 Author Share Posted May 17, 2018 That would be a solution, but my objects are grand-grand-grand-children of other objects so I would need to iterate through all te parent scales... I might try that. Quote Link to comment Share on other sites More sharing options...
botmaster Posted May 17, 2018 Share Posted May 17, 2018 Sincerely if in your code you end up having a child of a parent that shouldn't inherit parent transform then it should probably not be a child of the parent in the first place. This sounds like trying to find an expensive and complex solution to what really is a logic flow to start with. The obvious solution is this, if the parent transform should not be applied to the child then the child is with the wrong parent. Make a parent that doesn't have the problematic transform and add the child to it. jonforum 1 Quote Link to comment Share on other sites More sharing options...
jonforum Posted May 17, 2018 Share Posted May 17, 2018 16 minutes ago, botmaster said: Sincerely if in your code you end up having a child of a parent that shouldn't inherit parent transform then it should probably not be a child of the parent in the first place. This sounds like trying to find an expensive and complex solution to what really is a logic flow to start with. The obvious solution is this, if the parent transform should not be applied to the child then the child is with the wrong parent. Make a parent that doesn't have the problematic transform and add the child to it. thats it true in some way and most context scenario. But it could happen in a complex scenario of wanting to activate||deactivate only temporarily some specific parent inheritance. in this context, you have no choice to create a stabilizer, which is far from being a performance friendly. Quote Link to comment Share on other sites More sharing options...
botmaster Posted May 17, 2018 Share Posted May 17, 2018 That's kind of my point, the first thing to do should be to determine if this is that kind of complex situation where no easy solution can be found or if this is just because the user is unaware that using another parent would be a viable solution. solution. Quote Link to comment Share on other sites More sharing options...
jonforum Posted May 17, 2018 Share Posted May 17, 2018 Animate a tree with spriteSheets its a good complexe example. You hit the tron: the hit afect the tron rotation and children branch you cut the branch and hit again. You don want roation affect the cutted branch. But keep the scale of trhon and also the scene zoom scale.. this it juste a sample example, with spriteAnimation, but it fixed with spine2d Quote Link to comment Share on other sites More sharing options...
Fedor Posted May 21, 2018 Author Share Posted May 21, 2018 @botmaster: in my case I don't think it's bad structure. The child that should remain it's own scale is a bit of text. It follows the sprite but it should not resize when the sprite resizes. Quote Link to comment Share on other sites More sharing options...
botmaster Posted May 21, 2018 Share Posted May 21, 2018 one parent: - child sprite < can scale - child text I don't see what's the big deal here? Quote Link to comment Share on other sites More sharing options...
OSUblake Posted May 23, 2018 Share Posted May 23, 2018 You can use GreenSock's ExpoScaleEase to animate scaling/counter-scaling. https://greensock.com/docs/Easing/ExpoScaleEase // Scale from 1 to 3 TweenMax.to(parent, 1, { pixi: { scale: 3 }, ease: ExpoScaleEase.config(1, 3) }); TweenMax.to(child, 1, { pixi: { scale: 1/3 }, ease: ExpoScaleEase.config(1, 1/3) }); Quote Link to comment Share on other sites More sharing options...
molst Posted February 7, 2020 Share Posted February 7, 2020 On 5/16/2018 at 8:54 AM, ivan.popelyshev said: There are no solutions for that baked in pixi. You have to make your own transform that ignores parent transform. Its not newbie material but its possible. We've got some code for that here now. Quote Link to comment Share on other sites More sharing options...
Fanyu Posted September 16, 2021 Share Posted September 16, 2021 On 5/16/2018 at 2:54 PM, ivan.popelyshev said: There are no solutions for that baked in pixi. You have to make your own transform that ignores parent transform. Its not newbie material but its possible. Hi ivan,If scaling and rotation are applied to the parent Container, how can the children transform so as not to be affected by the parent transformation. I have tried some methods but couldn't do it. Can you write a demo to illustrate? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.