gromgull / py-vox-io Goto Github PK

I guess this library no longer works?

Trying to load a file I just created with latest version gives this error message:

ParsingException: Unknown vox version: 200 expected 150

How to write IGES from 3d volume image using python ?

Let the range of z values in my numpy array be 0 ... z_max.

Voxels in my numpy array with z coord = Z actually appear in MagicaVoxel with z coord = z_max - Z.

The reason for this appears to be this line in models.py which inverts the z coords:

    voxels = [ Voxel( nz[2][i], nz[0][i], z-nz[1][i]-1, a[nz[0][i], nz[1][i], nz[2][i]] ) for i in range(nz[0].shape[0]) ]
                                          ^^^^^^^^^^^^

Is there a reason for the inversion of the z coordinate? (It reminds me of OpenGL LHS coordinate system, or similar)

Note: I'm considering the coordinates reported by MagicaPixel when viewing my model in that software as the canonical truth about what coordinate a voxel is at.

See here for format extensions.

I tried the simple visualization example with the castle.vox model that ships with MagicaVoxel. I get this:

2019-05-17 15:00:59 foo.home pyvox.parser[26148] DEBUG Found chunk id b'MAIN' / len 0 / children 39931
2019-05-17 15:00:59 foo.home pyvox.parser[26148] DEBUG Found chunk id b'SIZE' / len 12 / children 0
2019-05-17 15:00:59 foo.home pyvox.parser[26148] DEBUG Found chunk id b'XYZI' / len 10516 / children 0
2019-05-17 15:00:59 foo.home pyvox.parser[26148] DEBUG xyzi block with 2628 voxels (len 10516)
2019-05-17 15:00:59 foo.home pyvox.parser[26148] DEBUG Found chunk id b'nTRN' / len 28 / children 0
Traceback (most recent call last):
  File "./test.py", line 10, in <module>
    m = VoxParser(sys.argv[1]).parse()
  File "/usr/local/lib/python3.7/site-packages/pyvox/parser.py", line 93, in parse
    main = self._parseChunk()
  File "/usr/local/lib/python3.7/site-packages/pyvox/parser.py", line 81, in _parseChunk
    chunks.append(self._parseChunk())
  File "/usr/local/lib/python3.7/site-packages/pyvox/parser.py", line 83, in _parseChunk
    return Chunk(_id, content, chunks)
  File "/usr/local/lib/python3.7/site-packages/pyvox/parser.py", line 55, in __init__
    raise ParsingException('Unknown chunk type: %s'%self.id)
pyvox.parser.ParsingException: Unknown chunk type: b'nTRN'

Thank you for your program.
In using viz_rgba.py to read my original file, unpack_from error occurred.
It says:

unpack_from requires a buffer of at least 8 bytes for unpacking 4 bytes at offset 4 (actual buffer size is 4)
File "C:\Users\vscode\vox-py-io\py-vox-io\examples\viz_rgba.py", line 9, in
m = VoxParser('test2.vox').parse()

How can I avoid this error?

Thanks for this awesome module, currently I am really trying to understand how this module. Your examples are helpful, but a little bit complex.

I am wondering what is the easiest way to think about the RGB and the materials for Vox?

Let say if I just want an array of 10 x 10 with random RGB and random Material (glass, emission, metal) for, how to make it?

Thanks!

Just wanted to bring up this bug / limitation. After tensors go beyond 255 lengths in all 3 dimensions i.e. tensor.shape > (255,255,255) and the VoxWriter call is run (VoxWriter(save_file, vox).write()) this error is produced:

pyvox/writer.py", line 48, in <genexpr>
    chunks.append((b'XYZI', pack('i', len(m.voxels)) + b''.join(pack('BBBB', *v) for v in m.voxels)))

error: ubyte format requires 0 <= number <= 255

I was wondering if there is a way to circumvent this issue or should we just resize the array to a smaller size

Hi, thanks for the lib!

I was generating a very simple vox scene with 2 colours in it and have realised py-vox-io seems to have an off-by-one error in it when creating the palette information because it inserts a black colour entry at index 0 when in fact it shouldn't be doing so.

In models.py there is a line:

palette = [ Color(0,0,0,0) ] + [ Color(*c, 255) for c in chunks(palette, 3) ]

I believe the line should actually read:

palette = [ Color(*c, 255) for c in chunks(palette, 3) ]

After I make this change, my palette indexes are correct.

I can make a pull request if you think this sounds correct.

P.S. I think I can see how this came about. The spec for the vox format says:

color [0-254] are mapped to palette index [1-255], e.g :

... but I don't think this means that you actually have to have your own entry for black at index 0 when you generate palette information.