sage-of-mirrors/gltf2vmd

gltf2vmd's Issues

Allow vertex attributes to be specified by a config.txt file in the model's directory

The GameCube allows vertex attribute data to be stored in a variety of ways. This is to facilitate efficient storage of the data under various circumstances.

By default, all VMD files will be built with default formats for each of the attributes - floats for positions, RGBA8 for colors, and int16s for texture coordinates and normals. However, it would be advantageous to have the option to specify formats differing from these defaults in the event that those differing formats would have a beneficial impact on performance or file size. Such a file would be named config.txt and have the following structure:

position float
normal s16 8
color0 rgba8

Each line would contain tokens relating to a vertex attribute and the format that it should be stored in.

Implement binary data modification (Vertex Colors)

GLTF stores vertex color data as floats in a vector4 (RGBA). The GameCube does not support using floats for vertex colors.

At runtime, the colors must be read from the binary data and saved back to it as RGBA8 (one byte per component) or another format supported by the GameCube. The converted color data will take up 1/4 as much space in the data, with 4 bytes of RGBA8 data for every 16 bytes of float color data. The extra space is unlikely to cause issues, so the data between the last color and the start of the next section will be zeroed out.

Implement scenegraph

The skeleton data (transforms and hierarchy info) needs to be converted from the JSON format in gltf to the binary format of VMD. This data will be the first section in the VMD file after the header.

The data will be stored in the following order:

• Parent bone index (uint16)
• Translation (vector3, float)
• Rotation (quaternion, float)
• Scale (vector3, float)

Additionally, this section will contain a list of structs that map meshes to their materials. A simple structure:

• Material index (uint16)
• Mesh index (uint16)

There are also other pieces of data that it may be advantageous to encode in the scenegraph:

• Explicit parenting of fully-weighted meshes to the bone they are influenced by
• Matrix type? (Billboarding)

Load all BufferViews into separate objects to be modified and saved to the VMD

BufferViews in GLTF specify where the binary data is stored for each component of the mesh - vertex attributes, inverse bind matrices, etc. Because several of these components need to be modified before they are written to the VMD, they will be loaded into separate objects so that these modifications will be easier to make.

Each BufferView would consist of an object containing an array with the original data values and the details for the data given by the GLTF file. The desired modifications could then be made independently to each object before they are all written to the VMD file.

Implement texture encoding

GLTF stores texture data as separate files within the same directory as the .gltf and .bin files. These images must be converted into a format that the GameCube can utilize and copied into the VMD file.

The texture data will be the last section of the file, coming even after the binary data produced by GLTF.

Nintendo's BTI format is a good starting place for image encoding.

Implement materials

Because the GameCube uses its own material system (TEV), the GLTF materials will be discarded in favor of a new system.

This system has yet to be finalized. This issue must be revisited at a later date.

Implement binary data modification (Vertex Indices)

GLTF stores primitive vertex indices as lists of uint16s. Unfortunately, the GameCube requires more than just the basic vertex attributes (position, normal, tex coords, etc) in the index data:

• The sequence of vertices must begin with the primitive type and the number of vertices in the primitive.
• There must be an index inserted into each vertex that tells the GPU what matrices to use to skin that vertex.

Additionally, the default layout of the GameCube's standard matrix memory (for use with geometry and textures) leaves only 10 matrices for skinning per primitive. Thus, skinned meshes must be broken up into separate primitives that have less than 10 unique matrices influencing their vertices. This was already implemented in SuperBMD.