VOXELFORMAT: CUBZH: transforms are not converted from the coordinate system

[mgerhardy]

about version 0.0.32

in cubzh

in blender after obj export

in blender after gltf export

a name issue of the nodes

in addition to this the colors are also looking kind of wrong. There was a recent change in cubzh that changed the default palette behaviour

we have made an update to how palettes are handled in .3zh files, shapes can now share palettes and to reflect this,

• the first "root" shape of the file always has its own palette (unchanged)
• legacy files will have its subsequent shapes save their own palette, in which case Cubzh allocate their respective palette (retro-compatibility)
• newer files will have subsequent shapes without palette, implying that they share the root shape's palette

ears and hands are flipped

Special thanks to Nanskip for the permission to attach his model for this bug here:
player_nanskip.zip

[mgerhardy]

beaf53b fixes the naming issue.

Looks like there is a bug in the uncompressed size of the chunks in the 3zh files

             *uncompressedSize = subheaderSize + shapeSizeSize +
                        (shapeId > 0 ? subheaderSize + shapeIdSize : 0) +
                        (shapeParentId > 0 ? subheaderSize + shapeParentIdSize + subheaderSize +
                                                 shapeLocalTransformSize
                                           : 0) +
                        subheaderSize + shapePivotSize + subheaderSize + shapeBlocksSize +
                        (shapePaletteSize > 0 ? subheaderSize + shapePaletteSize : 0) +
                        (hasCustomCollisionBox ? subheaderSize + objectCollisionBoxSize : 0) +
                        (isHidden == 1 ? subheaderSize + objectIsHiddenSelfSize : 0) +
                        shapePointPositionsCount * subheaderSize + shapePointPositionsSize +
                        shapePointRotationsCount * subheaderSize + shapePointRotationsSize +
                        (hasLighting ? subheaderSize + shapeLightingSize : 0) +
                        (nameLen > 0 ? subheaderSize + nameLenSize + nameLen : 0);

the nameLen contribution to the uncompresedSize is using subheaderSize - which is 1 byte for the type and 4 bytes for the chunk size. but in the case of a string this is 1 byte for the type and 1 byte for pascal type string.
4 bytes too much - as the length is taken twice - the chunk len and the string len - but for the name chunk (id 18) this is only the string length