@MikalDev any hopes to get an update that fixes support for the playable ad C3 export? When you export as a single file with base64 assets, the plugin can load the PNG for Spine from the base64, but the .atlas and .json always 404 as the atlasURI and jsonURI are trying to look for the actual file itself instead of using the base64 string in self.c3_base64files.

@MikalDev that sounds much better! Let's hope future C3 releases will allow proper triangle mesh rendering.

@MikalDev
oh wow thank you for this, finally got it working

i still haven't completely figured out fixing the cropped image if the initial skin for a spine object is smaller than the skin set for a new dynamically created spine object

kindly check if you don't mind: sendgb.com/JQ9lX5TnLAr

thank you

sorry for double posting in two forums, take a while for the mods to approve my post in the construct forum

@MikalDev what do they mean with "emulation"? Constructing degenerate quads? That would explain why they only want to do per triangle (quad really) colors. But it's still a strange decision. Their batcher ultimately must expand the per triangle (quad) colors to individual vertex attributes, both in WebGL and WebGPU.

Then I had a look at c3runtime.js, specifically their WebGLShaderProgram class. It turns out that they are passing colors not as vertex attributes but as uniforms. That means you can not batch sprites with different colors. Anytime you have to change a uniform, you have to submit a new rendering command to the GPU. I'm sure they have their reasons, though I can't think of any myself. Haven't checked if there's a WebGPU implementation in there.

It seems the only reason WebGLRenderer can only draw quads is because they statically fill the index buffer via FillIndexBufferData which assumes that the vertex buffer consists of sequences of 4 points, each making up a quad. If instead the index data would also be written "on-the-fly" each frame, e.g. for quads or arbitrary triangle meshes, then the quad restriction would go away. I'm not intimitely familiar with the whole renderer, but from a look at related code, e.g. WebGLBatchJob, it doesn't look like such a change would influence anything else in the renderer.

WebGLRenderer has a handful of QuadXXX methods, which would also need to write data to the index buffer. Then it's just a matter of adding one more method to WebGLRenderer, which allows specifying vertex and index data directly.

I can see how this could be a scary change tho, and ultimately it is their software and on them, how they want to move forward. The "emulation" will likely not be much faster judging by the renderer code, but it will at least reduce the amout of temporary JS objects that need to be created and garbage collected each frame.

That the parameters to the new method are going to be arrays of arrays is also unfortunate. We (and likely other plugins) would have to shuffle our data around and create temporary arrays each frame, which need garbage collection. On the Construct side, they then have to untangle those arrays and convert them to linear typed arrays again.

In any case, it's great that there's some movement on this. If the initial implementation is slow, that's likely not a big deal. Having a stable API for rendering triangle meshes plugin creators can rely on is a good first step. Ideally, the parameters aren't arrays of arrays but linear (typed) arrays instead.

@MikalDev i was able to access the skeleton json and just manually parse it, but thank you

anyway, if you or anyone else could help:

1. i'm playing around with the mix and match sample spine project. can we dynamically create a spine object? i tried but it seems the skin isn't changing

2. how do i resize a spine object (skin) so that the whole thing is within the bounding box? set size allows me to change the size, but it doesn't guarantee the whole skin is displayed and not cropped out