Jump to content

Its a very scary Pull Request, codename pixi v4.1


ivan.popelyshev
 Share

Recommended Posts

https://github.com/pixijs/pixi.js/pull/2414

I made a very scary PR for pixiv4, stil work in progress. It takes care of multiple things:

  1. No need to calculate matrices for objects every tick: only when they position/scale or something else was changed
  2. Same with bounds
  3. Same with interaction
  4. Sprite size doesnt change scale
  5. Camera projection doesnt change transforms. Object transform wont be re-calculated if camera was scrolled or rotated.
  6. DisplayObject can have pre-calculated local bounds that will be used to speed up interaction process.

Things that I'm preparing right now:

  1. Z-indices, displayorder for camera. 
  2. culling based on bounds for camera
  3. 3d transforms. See that gif at https://www.kickstarter.com/projects/chimeraco/lux-a-survival-mmorpg-pc-mac-xb1-ps4 ? Its pixi-flip.
  4. new version of pixi-spine that will use all that stuff.

I need people who understand WTF is I am doing and who can tell me what can go wrong with it, because that's one of the most sofisticated things that I've made in my life.

Link to comment
Share on other sites

:) sounds great...

there looks performance up...

 

can i ask this meaning?

Quote
  1. Same with bounds
  2. Same with interaction
  3. Sprite size doesnt change scale

 

 

and is this option?

Quote

Z-indices, displayorder for camera.

z-indices  looks great but is this better than sorting children?

 

is this automatic culling  objects(containers) by camera?

Quote
  1. culling based on bounds for camera

 

 

thx~~

 

ps> can i ask pixi.spi

Link to comment
Share on other sites

Quote

hi @ivan.popelyshevlooks great...

z-order is controlled  by camera...

is this more powerful than container's children controlling?  

which one is more optimized between sort children manually and camera-zindex controlling?

 

Link to comment
Share on other sites

Camera z-index is much better:

  1. All objects inside camera, except those who are INSIDE filters or masks are sorted. Objects that are not renderable (culled) are ignored.
  2. There are no changes of "children" AT ALL. Camera forms _displayList array, that will be used by render() method.
  3. You can assign different z-index to parent and child, its useful for making shadows of objects.
  4. First they sorted by z-index, but if you specify function that assigns dynamic z-order (like sprite.zOrder = -sprite.position.y), it will be taken into account too.
  5. If both z-index and z-order are the same for two elements, that often happens if child is inheriting parent z-index, update order will be used.

I'll implement special optimization for sort function later, but I dont think we'll need them right now.

Link to comment
Share on other sites

I just thought about common uses of Z coordinate and came up with solution that covers them.

zIndex is like layer in web-page. In most cases there will be only a few z-indices and I'll be able to optimize it.

zOrder is for arranging sprites by their distance from camera, like in actual 2d/3d scene.

onZOrder is called after updateTransform() of camera for every renderable element in that camera:

https://github.com/ivanpopelyshev/pixi.js/blob/dev-v4.0.0-geom/src/core/display/Camera2d.js#L329

camera.onZOrder = function(obj) {
  if (obj.zIndex == 1) { 
     //THATS MY UI! preserve natural order! I wonder why did I add it in camera container anyway...
  } else if (obj.zIndex == 0) {
     //my precious sprites. some of them are in containers, and camera might be rotated, so I take it directly from the matrix
     obj.zOrder = -obj.projectionMatrix2d.ty;
  }
};

 

Link to comment
Share on other sites

On March 27, 2016 at 4:16 PM, ivan.popelyshev said:

I need people who understand WTF is I am doing and who can tell me what can go wrong with it, because that's one of the most sofisticated things that I've made in my life.

Oh dear! :)

Link to comment
Share on other sites

This is not something that will come with the 4.0 version, right?

 

Quote
  1. No need to calculate matrices for objects every tick: only when they position/scale or something else was changed
  2. Same with bounds
  3. Same with interaction
  4. Sprite size doesnt change scale
  5. Camera projection doesnt change transforms. Object transform wont be re-calculated if camera was scrolled or rotated.
  6. DisplayObject can have pre-calculated local bounds that will be used to speed up interaction process.

This will likely give a huge performance boost in my use case :)

Link to comment
Share on other sites

  • 5 months later...

@klim now Its a fork, third iteration, and it is used in production of some projects. Fourth will be done soon.

https://gameofbombs.github.io/pixi-bin/

https://gameofbombs.github.io/pixi.js/

https://gameofbombs.github.io/pixi-bin/index.html?s=flip&f=cards.js&title=Cards

As for Z-index, https://github.com/pixijs/pixi-display works just fine for latest pixi-v4, and its actually faster than the one in "scary pull request" and "gameofbombs pixi"

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...