Voxel with bounds greater than 254x254x254 trigger IndexOutOfRangeException

[R4wizard]

When attempting to run IsoVoxel with large .vox files created with the latest MagicaVoxel (0.9.6.2-win64) I receive the following error:

E:\IsoVoxel-0-0-14>IsoVoxel.exe Text-Broken.vox

Unhandled Exception: System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at IsoVoxel.PaletteDraw.renderSmart(MagicaVoxelData[] voxels, Byte xSize, Byte ySize, Byte zSize, Direction dir, Outlining o, Boolean shrink)
   at IsoVoxel.PaletteDraw.ProcessUnitSmart(MagicaVoxelData[][] parsed, String u, Int32 xSize, Int32 ySize, Int32 zSize, Outlining o, Int32 multiplier)
   at IsoVoxel.PaletteDraw.Main(String[] args)

I did some testing with other models and it appears that this error appears once I set my voxel model bounds to be > 254x254x254. Additionally, at a bounds size of 254x254x254, the process seems to take a very long time to finished.

I've included 3 test files with this issue, all containing the same test scene just with different model bounds:

1. Test-Broken.vox: 256x256x256 model that refuses to render.
2. Test-Almost.vox: 254x254x254 model that started rendering, but takes a very long time (too long for impatient me to wait out!)
3. Test-Working.vox: 80x80x80 model that renders fine and within a reasonable timeframe.

[tommyettinger]

Huh, I'm not sure why 254x254x254 is specifically so slow, but I know 256x256x256 wasn't supported by older MagicaVoxel .vox formats (they used a byte for size, which maxes out at 255 for any one dimension, or just 127 if it's a signed byte). I wrote IsoVoxel when 126 was the max, and did an at-the-time non-standard extension to handle up to 254 or 255. I have no idea what changed in the file format to allow larger sizes than a byte permits. I'll have to check out any documentation I can find on the current .vox file format; last I recall, ephtracy's format documentation repo was quite out-of-date, and the only other place would be file2vox source.

[JelleBouma]

Huh, I'm not sure why 254x254x254 is specifically so slow, but I know 256x256x256 wasn't supported by older MagicaVoxel .vox formats (they used a byte for size, which maxes out at 255 for any one dimension, or just 127 if it's a signed byte). I wrote IsoVoxel when 126 was the max, and did an at-the-time non-standard extension to handle up to 254 or 255. I have no idea what changed in the file format to allow larger sizes than a byte permits. I'll have to check out any documentation I can find on the current .vox file format; last I recall, ephtracy's format documentation repo was quite out-of-date, and the only other place would be file2vox source.

Hi I came across your project because I have a lot of vox files I need to render, I have some experience with the Magicavoxel file format.
What they do to go beyond 256x256x256 (these would still fit in a byte btw because the coordinates start at 0) is they allow multiple models in a file, these together can form a larger model, you can check the file format "extensions" documentation here: https://github.com/ephtracy/voxel-model/blob/master/MagicaVoxel-file-format-vox-extension.txt#L82 In the extensions you will see an nTRN chunk which specifies the translation (location) of the voxel models.
Note that voxel models are centered, so it is the center axis which is translated.

[tommyettinger]

Since I last looked at this issue, I wrote SpotVox (GitHub link), but I had no idea how to publicize it to the MagicaVoxel community, so I pretty much left it as is, but working. It should handle most, if not all, of the extended chunks, including most of what materials can do (not all, because only so much makes sense for pixel art), and including multiple models with translations.

[JelleBouma]

Since I last looked at this issue, I wrote SpotVox (GitHub link), but I had no idea how to publicize it to the MagicaVoxel community, so I pretty much left it as is, but working. It should handle most, if not all, of the extended chunks, including most of what materials can do (not all, because only so much makes sense for pixel art), and including multiple models with translations.

Hi, thanks!