Closed davidetan closed 3 months ago
hey @davidetan , do you have a spine file i could use to test this pls? I think there might be a way we can avoid the extra checks in addRenderable
but would like to verify! thanks man
hey @davidetan , do you have a spine file i could use to test this pls? I think there might be a way we can avoid the extra checks in
addRenderable
but would like to verify! thanks man
Sure, just use the basic example and change the animation from run
to portal
at this line: https://github.com/pixijs/spine-v8/blob/main/examples/basic.html#L45
Close in favor of this: https://github.com/pixijs/spine-v8/pull/32
This PR fixes a couple of problem with clipping:
spinePipe.addRenderable
is called with acacheData.clippedData.vertexCount
set at0
, butcacheData.clippedData.vertices.length
is bigger than0
, it was still added to the batch, generating aGL_INVALID_OPERATION: Insufficient buffer size.
on webgl and aCalling [RenderPassEncoder (unlabeled)].Draw with an index count of 0 is unusual.
on webgpuspinePipe.updateRenderable
is called, thebatcher.updateElement
was called regardless of the fact the attachment has zero clipped vertices to draw; however, thevertexSize
of theBatchableSpineSlot
is never set to zero becuaseaddRenderable
set it only if vertices are more than zero. I added an if intoupdateRenderable
, otherwise we can move thebatchableSpineSlot.setData
outside the if in theaddRenderable
I'm not an expert of
RenderPipe
, so let me know if I did some wrong assumption :)