Sprite mesh

[GordonTombola]

New Material and derivative of Mesh3D for rendering sprites

reasons:

• Sprite3D implementation had some issue when drawing over 3d objects in the scene
• I was attempting to create a billboard particle emitter and sprite3d wasn't able to render as expected

new SpriteMesh

old sprite3D

• this PR also includes a modified version of the standard shader's render method in sprite-shader.ts which I believe could be an improvement able to be made to the render method in the standard shader

  render(mesh: Mesh3D, renderer: Renderer, state: State, drawMode: DRAW_MODES) {
    if (mesh.instances.length > 0) {
      const filteredInstances = mesh.instances.filter((instance) => instance.worldVisible && instance.renderable);
      if (filteredInstances.length === 0) {
        //early exit - this avoids us drawing the last known instance in the instance buffer
        return;
      }
      this._instancing.updateBuffers(filteredInstances, true)
    }
    super.render(mesh, renderer, state, drawMode)
  }

[jnsmalm]

Hello! Whoa - this is a big PR :-)

It will take while for me to go through all of this, but just some initial questions:

• Wouldn't it be better to try to fix Sprite3D than creating a completely new one? It will be a bit weird for the users to have two different API's to render 3D sprites.
• Did you do any performance tests vs Sprite3D?
• Just to double check, you want render 3D sprites in front and behind another 3d object and everything should look correct?

[jnsmalm]

It may even be that what you want is already supported but is not so clear how it works. Try render the cube before rendering the sprites.

[GordonTombola]

Hello! Whoa - this is a big PR :-)

It will take while for me to go through all of this, but just some initial questions:

• Wouldn't it be better to try to fix Sprite3D than creating a completely new one? It will be a bit weird for the users to have two different API's to render 3D sprites.
• Did you do any performance tests vs Sprite3D?
• Just to double check, you want render 3D sprites in front and behind another 3d object and everything should look correct?

Hey there,

Will check this over Monday, the idea was to have a billboard sprite that could be used for a particle emitter in a scene, as far as I remember when testing, performatively thousands of sprite3D was worse than thousands of instanced meshes

[GordonTombola]

It may even be that what you want is already supported but is not so clear how it works. Try render the cube before rendering the sprites.

Will check this also on Monday, could you explain further how you would ensure the cube was drawn before the sprite3D in your screenshot?

[jnsmalm]

I did some test to be able to have more control over draw order with sprites and meshes. See PR https://github.com/jnsmalm/pixi3d/pull/112

Maybe you can test that branch and see if it work the way you expect?

The method used now is PixiJS's own method to batch sprites depending on state/texture and a bunch of stuff to have the best performance. But it would be interesting to compare it to the instancing method you have.

[jnsmalm]

Will check this also on Monday, could you explain further how you would ensure the cube was drawn before the sprite3D in your screenshot?

Just have the mesh before the sprites in the container hierarchy. You could also use container.sortChildren = true and use zIndex to control drawOrder.

[GordonTombola]

Will check this also on Monday, could you explain further how you would ensure the cube was drawn before the sprite3D in your screenshot?

Just have the mesh before the sprites in the container hierarchy. You could also use container.sortChildren = true and use zIndex to control drawOrder.

I did some test to be able to have more control over draw order with sprites and meshes. See PR #112

Maybe you can test that branch and see if it work the way you expect?

The method used now is PixiJS's own method to batch sprites depending on state/texture and a bunch of stuff to have the best performance. But it would be interesting to compare it to the instancing method you have.

After bumping the instances running to around 5k Sprite3D appears to be performing better across multiple browsers (specifically after an inclusion of the billboard sorting method, as without this the sprites still have the draw issue)

My only real issue with Sprite3D's rendering is inability to seperate its render order from its hierarchal placement, if sprite had a renderSortOrder akin to mesh3D maybe this would make more sense?

[GordonTombola]

Much Better performance coming out of Sprite3D using the abstract batch rendering process - only issue I can see with this currently is separation of render order compared to Mesh3D. (This will lead to issues rendering transparent meshes)