I'm in fact one of the programmers on Spine. I believe I have a pretty good handle on how our code works, and how GPU and CPU side skinning and data representations work. I understand that text communication can be frustrating if there are misunderstandings, but please keep it civil.
I understand entirely what you are trying to say, even though phrases like "hexadecimal code", "uniforms out the information", or "form a grid of information" aren't quite what a programmer would use for what you are describing.
What you are referring to as "hexadecimal code" is a packing of bone indices, say a byte per index, with a maximum of 4 indices encodable in 32-bit. For good measure, you can also throw in lower precision weights and even UVs, say fp16, to pack more data into the same amount of space, though that may actually lead to quite a noticeable degradation in the precision of the skinning and texture sampling itself. All of that has nothing to do with "hexadecimal code" though...
The phrase "uniforms out the information" is also nothing a programmer would say. I assume you are talking about matrix palettes stored in uniform buffers, which is an encoding used by most GPU side skinning shaders to share bone transforms across vertices. The bone indices in the vertex point into that palette.
"add an additional float then" is not possible GPU side. These floats are stored as part of a vertex. The vertex layout is fixed. You can not do run-length encoding in a vertex layout, unless you make every vertex as big as the worst run-length encoding requires. In which case you actually waste more memory than needed.
All of the above comes with tradeoffs that you might be able to live with at runtime in your game/app:
- Number of bones that can influence a single vertex, limited to 4 in a 32-bit packed encoding.
- Number of total bones limited by uniform space, but more importantly, the 32-bit packing, with one index being represented by a byte, limiting the total number of bones in a single pass to 256.
- Precision of weights may result in huge deviations in skinning outcome compared to the high precision mode you see in the editor.
- Precision of UVs may result in texture sampling artifacts compared to the high precision mode you see in the editor.
Again, you can do all of that at runtime, in your game, if you can live with the restrictions and plan your assets accordingly.
But for the Spine Editor, we can not make do with these restrictions. The core data structures in the editor must allow for maximum precision, bone numbers, and other factors that do not turn up in a runtime setting. There are also a bunch of algorithms applied to meshes that have a minimum space complexity of O(n2) (yes, there are no lower complexity solutions for some of these). Whether things are stored/computed GPU or CPU side is entirely irrelevant for the issue at hand.
We won't be able to fix your issue without a reproduction case. We currently lack such a repro. You said you won't send us anything. Please ask your programmers how they feel about fixing an issue without being able to reproduce it.
