Thanks, I submitted a PR to Spine-TS (for webgl2 context support) and also a PR to the C3 plugin (that changed to render to texture vs separate canvas and texture upload.) They are definitely still some things to review (C3 effects work on, but some state needs to be worked out as it's not consistent, also low-quality full-screen scaling fails in C3.) The plugin also needs at least a few more features to be added (like picking a skeleton when multiple are available (I have hacked the plugin to allow that, the plugin needs a consistent way that uses ACEs.) There also some perf optimizations (batch Spine render for all Spine objects, so only need to save/restore webgl state once per frame.)
Thanks for the advice on SceneR vs SkeletonR, is there a performance difference, will take a look at it.
I see some intermittent PMA problems too, so working on getting some blend modes appropriately set before and after Spine WebGL render. Any hints would be good, I've read the Spine PMA faq, but still some issues, perhaps with blendFunc() or blendFuncSeparate().
I did have to change Spine-TS to handle resizing for the render to texture buffer rather than render to and resizing the C3 canvas directly. I added an 'issue' to Spine-TS regarding this. My changes are not backward compatible, so I'm not going to create a PR, but at least theses changes show that it will work.
In terms of C3 files, here's what I did in my original C3 JS template and the plugin uses it. It's now pretty easy, just need to import the three files into a C3 project 'FIles' folder, add the names to the Spine plugin properties and it works.
// Creating URI to access C3 project files:
this.pngURI = await globalThis.c3_runtimeInterface._localRuntime._assetManager.GetProjectFileUrl(this.pngPath);
this.atlasURI = await globalThis.c3_runtimeInterface._localRuntime._assetManager.GetProjectFileUrl(this.atlasPath);
this.jsonURI = await globalThis.c3_runtimeInterface._localRuntime._assetManager.GetProjectFileUrl(this.jsonPath);
If you want to try a quick demo, check out the *.c3addon from my branch/PR for the plugin and use the original demo project from the plugin:
https://github.com/MikalDev/c3_spine_plugin/tree/render-to-texture/dist
https://github.com/gritsenko/c3_spine_plugin/tree/master/sample_projects
(Note the current plugin only works with the skeleton / animation in the sample project.)
Igor is the plugin author (great work), their github repo is here:
https://github.com/gritsenko/c3_spine_plugin
C3 Test (w/ edited plugin to allow other skeletons), C3 outline effect on one of the orangegirl skeletons. Integrated into C3 layers, so each Spine object can be in a different C3 z-order and layer.
Thanks for the suggestion on reviewing the Skeleton Renderer vs the SceneRenderer, it looks like that will help clear up the resize difficulties and canvas interactions. We can also get the 'webgl2' context external to the Spine-TS, so I think no changes needed there for that either if not using SceneRenderer.
I did an update using skeletonRenderer instead of sceneRenderer, everything is cleaner and no changes needed for Spine-TS anymore. Thanks for pointing the way there.
There is a remaining issue around PMA though. I have added a flag/property for PMA for the Spine object, so I can apply it to the renderer:
this.renderer.premultipliedAlpha = this.premultipliedAlpha;
this.renderer.draw(this.batcher, this.skeletonInfo.skeleton);
Is the above correct?
However, for the orangegirl and greengirl meshes the small black borders still appear.
I am wondering if something could be happening on texture load. We are using an existing webgl context which most likely has alpha:true and we can't change an existing context when we get the context for Spine and I see this comment in one of the examples:
// Setup canvas and WebGL context. We pass alpha: false to canvas.getContext() so we don't use premultiplied alpha when
// loading textures. That is handled separately by PolygonBatcher.
Suggestions?
