IQMv3 (and/or EXMv3) wishlist/planning

[shakesoda]

figured I'd leave an issue up about this: future features wishlist. implementation details not required.

feedback/ideas are very much welcome, and everything is valuable. I intend for this format to remain opinionated (i.e. unlike glTF - things work exactly one way, with minimal indirection and an explicit focus on games and simplicity) and try to stay lean, but that doesn't mean we can't think up all kinds of things!

these don't all have to be good and fully thought out ideas, just some potential nice-to-haves to be thought of in depth at a later time. bonus points if they don't increase minimum required complexity to load a valid file.

ideally, new features will degrade nicely for existing readers and incomplete implementations, i.e. an older or minimal reader which doesn't support a given feature can still render a mesh correctly.

I have utterly no idea if upstream will ever update the format, but it seems unlikely. will change the format magic if compat is meaningfully broken ever.

exporter options

• option to ignore root bone motion (convenient when animating)
• export collections, white or blacklist?

metadata

• frame markers (useful for animations having corresponding sfx, for example)
• mesh tagging (vis, groups, collision, lods...)
• look into a simple alternate metadata representation that doesn't need an entire json parser. parsing json is sluggish and a ton of code.
• an actual material model? something like the disney or enterprise pbr model would be really handy, but this might be just way too specific to include.
• cameras and lights might be useful to represent here (in addition to existing support for empties)
  • 2019-09-10: added light data export

format additions/changes/cleanup

• the only animation flag is loop, are any others useful?
• additional color and UV layers would be very useful. common to use second UVs for lightmaps, or more color layers for masking.
  • perhaps allow exporting additional color and weight layers as IQM_CUSTOM+n and use the vertex array flag for the base type?
  • 2019-4-4: added EXM_TEXCOORD2 vertex array 0x20. not in the spec. see comments.
• some of the sections in the header aren't actually used as far as I can tell - what uses flags? has anyone actually used the extensions or should that be repurposed for metadata? etc...
• more strict data types for components - lots of weird combinations are possible now, but few are actually used.
• blend shapes (see how glTF does them?)
• ushort vertex data (positions) scaled to (undeformed) bounding box, ushort normalized uvs, some kind of two-component normal encoding?
• guaranteed object bounds, mesh uvs + normals + tangents
• explicit non-deforming bones (useful for leaf bones for lengths, helper bones/targets...)
• object animation and inverse transforms, implemented such that positions are still applied but if supported you can reverse the transformation and work in their original local space (so you don't have to understand an object hierarchy to render a model properly)

[plankatron]

i second extra uv layers

[shakesoda]

implemented second uv layer using one of the IQM_CUSTOM arrays for now. active layer will be used as usual for IQM_TEXCOORD and first inactive layer for EXM_TEXCOORD2.

in the future it seems sensible to have something like EXM_TEXCOORDS @ 0x20 + n and write names out to text block, same for EXM_COLORS @ 0x30 + n and so on. I'm not aware of anyone using more than 16 IQM_CUSTOM layers, so this should be pretty safe compatibility wise.