ogt_vox: added initial support for CHUNK_ID_MATL

[dougbinks]

The CHUNK_ID_MATL appears to be the current approach for extended material information in MagicaVoxel, with CHUNK_ID_MATT being obsolete - the former is present in all .vox files exported currently, but not the later.

I have added initial support for reading this chunk in this PR, which is intended primarily as a discussion for the implementation approach prior to my making any changes along with adding support for writing these values back.

An alternative approach might be to keep the material data as a dictionary of parameters - the size of the smallest dict for each material (default diffuse) is 36bytes, and the current structure is 64 bytes, so if most materials are diffuse using dicts might be a small saving in space.

[jpaver]

Hi @dougbinks, sorry for the delay. The change looks great, approach is good and I'm happy to rebase/merge once I can verify my own use-case still looks good.

I think we need just a couple of critical things to get working before merging:

1. We need to apply IMAP chunk reordering to the materials. (see context below)
2. We need to add support for _plastic material.

For (1) there are 2 things that Magicavoxel does that makes it tricky.

• 1. when using ctrl-drag to swap colors in magicavoxel palette, it doesn't swap the color palette entries, but uses an additional indirection table for color_index -> palette_index and it stores this as an IMAP chunk. See the 'found_index_map_chunk' section for how we deal with this in ogt_vox.
• 2. In the original spec for RGBA chunk, see: "color [0-254] are mapped to palette index [1-255], e., so a color index of 255 is transparent but the palette index of 0 is transparent. We handle this in the code around the 'rotate the scene palette' comment for how we deal with this in ogt_vox.
• Basically we'll want to make sure that similar transforms are done for the materials array, but I suspect it won't be as simple as making the exact same transforms as are done for the palette.
• Example repro: setup color palette R/G/B/C/M/Y in color indices 1,2,3,4,5,6,7. Assign different types of materials to each. Now ctrl-drag index 1 onto index 2. When loading using ogt_vox, make sure the ordering of materials still matches the corresponding R/G/B/C/M/Y color that was assigned to it. Try a few more ctrl-drags and make sure the colors/materials as imported don't drift apart.

for (2), I think "_plastic" can be written to the dictionary too, and the current code will just treat it as diffuse.

If you don't get to it, I can probably take a stab next week.

[dougbinks]

Thanks for the detailed response - I can take a look at these next week.

[dougbinks]

I've added support for the IMAP chunk remapping (materials 1-256 are already re-ordered on load to 256,1,2... ).

I can't find any "_plastic" material properties, if you have a way to make these in MagicaVoxel or a file with them in let me know.

[jpaver]

Thanks Doug, the new changes look and work great for me. I'll merge it in shortly.

I can see plastic with an older version of Magicavoxel (0.99.5.0.1-alpha). Attaching here: test_groups.zip, though I'm seeing _type come through as "_plastic", but also keys in the dictionary for: "_weight", "_rough", "_spec", "_spec_p", "_ior", "_att", "_g0", "_g1", "_gw", "_flux", "_ldr"

It looks like ephtracy may have moved _plastic into the _blend materials category in later versions based on this in the update log for 0.99.6.22 Blend Material: weighted blending Metal/Plastic/Glass/Cloud materials (similar to Disney Principled BRDF). and substantial other changes too.

It may be pretty difficult to identify all the transforms for materials from older file versions to provide a mapping from them to the latest format, so it's probably not worth the effort but if you'd like to tackle it I won't stop you :)

[jpaver]

BTW, thanks for the contribution, it's really appreciated!

[dougbinks]

Thanks for the library - it's been very helpful!

I'll take a look at the older model and see if I can find a translation later on.

[dougbinks]

Quick thought - I might need to add some documentation for the content flags. I've just discovered that if, for example, a value is 0.0f then it isn't present in the dictionary. So if you expect k_ogt_vox_matl_have_rough for ogt_matl_type_metal but the roughness is 0.0f then k_ogt_vox_matl_have_rough isn't set. Thus it's safest to initialize to 0.0f prior to load (as we do for the ogt_vox_matl values in ogt_vox_read_scene_with_flags()).