I have a counter-proposal:
The current state of the renderer (v3.10) is kind of complex… it has too many commands:
-
QuadCommand
: originally thought for 2d sprites (labels included). Batch-able -
TrianglesCommand
: an improved version of QuadCommand that supports a mesh. Batch-able… kind of supersedesQuadCommand
-
MeshCommand
: thought for 3d objects. Supports any kind of mesh/primitives. Non batch-able. -
PrimitivesCommand
: Not used internally, but initially thought as an improvedQuadCommand
but was a bit slower, so decided not to use it. I think this is similar to yourArbitraryVertexCommand
. -
BatchCommand
: For legacy code, likeSpriteBatchNode
… not used very much -
CustcomCommand
: for everything else.
In theory we shouldn’t need more than 3:
-
PrimitivesCommand
: for 2d stuff (or single-pass 3d stuff). Batchable -
MeshCommand
: for 3d stuff (multiple-pass stuff). Non-batchable -
CustomCommand
: for everything else
But in practice we can’t remove existing commands due to backward compatibility issues.
So, my counter-proposal is:
- Let’s use
PrimitiveCommand
(or improve it in case it doesn’t meet all your needs) - Let’s do the “transformation/conversion” in the constructor of of the Command, and not on the renderer.
eg: When you create a QuadCommand
, internally it will create PrimitiveCommand
… so the renderer will know nothing about QuadCommand.
I think issues 1), 2) and 3) could be fixed with that… (but I could be wrong).
Issue 4): Let’s define an API for that… where should we put it?
Issue 5): Yep… I think this is low priority since I think it doesn’t affect performance… but I could be wrong.
Issue 6): Let’s use (and promote… add documentation and more examples) RenderState
does it make sense? thanks