Draft for fixing integer decoding

[javagl]

Addresses #5

This is only a DRAFT and likely not supposed to be merged. This is only to illustrate a ""fix"" for the cases that have been mentioned in the issue, where decoding integer-type attributes (skinning joints and normalized texture coordinates) returned all zeros.

The reason for the values being zero is:

• SequentialIntegerAttributeDecoder calls its getValues function at different places
• This function unconditionally calls preparePortableAttribute
• This always creates a new instance of the attribute, regardless of whether there already was an instance

So the getValues was called at one place, filled with the proper data (I guess), and later called again, causing these initial values to be lost.

Running the test that was shown in the issue now reports at least "non-zero" values.

I also tried out this state in the context of jMonkeyEngine/jmonkeyengine#2591 . It does fix the case of the unsigned short texture coordinates not being read. Maybe someone who knows what this code is about can check whether this "fix" makes sense, and whether something similar has to be done elsewhere. If this is the case, then I assume that ~"something like this" will be done in the .NET version, and then backported here.

NOTE: This fix does not immediately fix the issue with the vertex skinning, but this might be an issue of how I'm using that library in jMonkeyEngine. So someone should (try to) confirm that the values that are provided by openize-drako-java are correct (I'll continue checking the jME side in the meantime)

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[javagl]

This is obsolete, with the exact same change having been done in openize-com/openize-drako-net@ee8befc and now being part of the current main state here.