- Изменено
[Spine web player]: bug with translucent player?
Greetings and Happy New Year. =)
I am engaged in the conversion of the old format (v2.1.27) to the new one (v4.1-beta? something like that). For fun, I play with the spine web player (ver.4.1.5). According to the instructions on the link ( http://en.esotericsoftware.com/spine-player ), I configured the Spine web player. And I found a problem that is a bit critical for me.
Something is wrong with rendering attachments in the Spine web player when "alpha" configuration property enabled (translucent player). If you disable "alpha", then the problems disappear. But in order to export transparent images from canvas I need "alpha" property to be enabled. Can you help me fix that?
Example of expected animation (w/o "alpha" property) - https://www.norbdragon.com/uploads/spine14/
Example of unexpected behavior (w "alpha" property) - https://www.norbdragon.com/uploads/spine16/
The files used in the experiment have already been sent to contact@esotericsoftware.com
Export your texture atlas with premultiplied alpha, that should do the trick.
I'm curios. The version string in the .json file ends with norb. Did you change that manually and if so why?
Mario написалExport your texture atlas with premultiplied alpha, that should do the trick.
I thought about this option, but threw it away with thoughts: could an artist individually unload this particular texture without premultiplied alpha to a png-file with other textures that are with premultiplied alpha? Sounds pretty strange to me. Have some files with this bug (?), not one. But I can check this. I will inform you later about the results.
Mario написалThe version string in the .json file ends with norb. Did you change that manually and if so why?
For fun. Spine web player does not look into this parameter. This is a mark for me that I converted this json file from old format (spine v2.1.27) to new (4.1-beta).
Mario написалExport your texture atlas with premultiplied alpha, that should do the trick.
Drako написалBut I can check this. I will inform you later about the results.
No, it didn’t work with "alpha" configuration property enabled. Something with spine web player or webgl, i think.
Link to my test after re-export with "pre-multiplied alpha" - https://www.norbdragon.com/uploads/spine17/
I see no difference with the example from the first post - https://www.norbdragon.com/uploads/spine16/
I have read the forum. I drew attention to a neighboring topic - http://esotericsoftware.com/forum/png-with-additive-export-with-black-screen-16872
Checked how the problem texture looks in the texture pack and type of blending for slot with this attachment. "Additive" blending + this texture use black instead of alpha... And I can see this bug (?) in export window too. :hmm:
The conclusion suggests itself that Spine web player renders an image on a transparent background using the same algorithm. Well, these are my thoughts out loud. It is quiet here on holidays, so I communicate with those few who are here. Suddenly someone is interested. Well, yes, that is, with myself. :sun:
Since the opinion was expressed in a neighboring topic that most likely nothing will be done in this direction, then... I need to surgically edit inscribed textures of this type in texture packs (png-files)? Need to change carefully the use of black to alpha channel for some parts...
Questions from "not an animator/artist" (maybe silly, sorry):
What is this "additive" blending used for?
What are the consequences if "repaired" texture with "normal" blending be drawn later not on empty transparent background, but on top of another object? Let's say the animation of a "glowing ball" flying past a character. The same rendering as if it was an "old" texture with "additive" blending? Or will there be changes?
Will I create new adventures for myself if I automate the process, assuming that ALL textures that are mentioned with "additive" blending are subject to "correction"? Or maybe there is a variation where the texture uses both the alpha channel (not black) and "additive" blending?
But... can it still be somehow fixed in the web player code?
I'm not talking about a new minor version of Spine web player. I would only need a hint as to which function to change the code in. And new code to replace.
Oh, the attachment is rendered with additive blending. That may not work at all with a transparent canvas, premultiplied alpha or not. I have to research it though before giving a definite answer.
Regarding assets provided by artists: they should always provide you the original image files in straight alpha, aka unpremultiplied alpha. That means the RGB values stored in the image are not pre-adjusted by the alpha channel. You then export those assets from the Spine Editor to a texture atlas with premultiplied alpha enabled. If you don't receive Spine projects + original image files from the artist but instead already get exported texture atlases, the artists must give them to you with premultiplied alpha enabled. Deciding if an image has been premultiplied is pretty much impossible, so you have no way to "correct" the images yourself.
Additive blending on a transparent background will always give you transparent. You probably don't want to use additive blending if you are drawing on a transparent background.
Spine does something special when exporting images/video so where there is a transparent background you get non-additive blending. This is just because users often use export to show a preview of their work, so they prefer to see something in those areas.