Investigate WebGL Rendering with Pixi.js #350
Comments
|
In #346 @englercj discussed Pixi v3 as a possible target
@samreid responded:
@englercj also described Pixi features that @samreid asked about in #346
|
|
Yesterday working with @jonathanolson we determined that Pixi has support for some of the features that would be tricky to implement ourselves: opacity (including for parent nodes) and clipping (including nested clipping regions). Some text glyphs are getting clipped, but this problem seems difficult to avoid with any technology. So pixi seems promising so far. |
|
I've been working on PixiNode. Here is my first attempt at using it to render a sim:
|
|
From skype: [1/22/15, 10:55:22 PM] Sam Reid: Using PixiNode strategy it is unclear how to let scenery handle input events for original scenery node but not its rendering. Thoughts? |
|
I added no-frills pixi rendering. Performance is very slow on iPad3 when using pixi for the entire sim (though very fast for just a few moving objects). When testing with http://localhost:8080/forces-and-motion-basics/forces-and-motion-basics_en.html?joistRenderer=pixi&screens=2 I wanted to count the number of draw calls pixi is making to see if they are batching draw calls. I instrumented each drawElements call in pixi-dev.js with a call to phetAllocation so they would be counted. Then in the console, I observed: This means 86 drawElements calls were being made per frame. To see if this correlated with any of the sim scene graph numbers, I used popupDebug to get information about the scene graph. I observed: Perhaps the number of drawElements calls is scaling with the number of drawables? Many sources cite that minimizing the number of draw calls is one (of many) important ingredients to getting good WebGL performance, so that's why I wanted to look into this. |
|
We do automatic batching, and we count draw calls for you as well (renderer.drawCalls). Are you using the same base texture for the tings you are drawing? Try to make containers have children with common base textures, or group common basetexture sprites together in the scene graph. Basically we iterate forward and when we encounter a new texture on a sprite we flush the batch and start a new one. So if your scene graphs looks like |
I'm not too familiar with Base Texture, even after taking a look at this http://www.goodboydigital.com/pixijs/docs/classes/BaseTexture.html Is it a way of doing sprite sheeting? Here's a picture of one of our interactive simulations:
Here is the list of node types as they appear in the rendering order. Generally each Image instance mentioned is from a distinct image file. You can also see that there are many shapes/text/images interleaved and no group of related images in a single layer. Is there a preferred Pixi way for rendering a scene like this? |
|
A When you are drawing many sprites, we can batch them into a single gl draw call if their base texture is the same. That is, if all the sprites are drawn from the same "image" (like a sprite sheet) they are batched. Otherwise you basically get one draw call per-sprite because you will get one draw call per baseTexture. Graphics are drawn with the stencil buffer and therefore require us to draw the buffer to the viewport individually (but you can use Does that make sense? |
|
Status update from PixiBlock.js /**
* Handles a visual Pixi layer of drawables.
*
* STATUS REPORT
* March 4 2015
* PixiBlock is in bad condition--it is a collection of prototypes and not ready for production code. The best way to
* see the status of PixiBlock is to launch:
* http://localhost/forces-and-motion-basics/forces-and-motion-basics_en.html?rootRenderer=pixi&screens=1
*
* Completed in this version of forces and motion: basics, with pixi
* 1. Images are rendering, and are in the correct position
*
* Issues in this version of forces and motion: basics, with pixi
* 1. Z-ordering is incorrect. When dragging a (hidden) puller, the z-order of many things changes.
* 2. When dropping a puller, there is an exception that crashes the simulation
* 3. Resizing is not handled
* 4. Context loss is not handled
* 5. Path is not generalized--just doing moveTo/lineTo
* 6. Getting 30 fps when dragging a puller on iPad3. (Also note that transparency, curves, etc will slow this down further)
* Though we could take steps to optimize for pixi, such as batching images together
*
* @author Sam Reid
* @author Jonathan Olson <jonathan.olson@colorado.edu>
*/ |
|
No plans to resume this investigation at the moment. If/when we do, @jonathanolson should be more heavily involved. |
Last week, we decided to investigate WebGL Rendering with Pixi.js. Our plan is to spend an initial 20 hours or so on it, and to check in with @ariel-phet regarding status after about 10 hours. Some discussion about Pixi took place in #346 and I will move pertinent conversations to this issue in subsequent comments.
There are 3 possibilities for how to proceed based on the results of this investigation:
Work on our own custom WebGL renderer module will proceed in parallel with our Pixi.js investigation.
The text was updated successfully, but these errors were encountered: