Question about BL16 index order

[norman784]

Hi, I'm writing a gox file parser and I've got with a strange behaviour (or maybe I'm doing something wrong while reading the BL16 colors).

Using as example the small tree generated by code, I got it rendered (or to be more precise exported as .obj) fliped, seems to be that the Z axis is the Y axis, I'm calculating the index like this x + y * size + size_cubed * z, tried to change the order but seems that the only way the mesh is generated as the original (except for the rotation) is using that.

I'm missing something? I readed the file specs and also tried to jump between the code but in some parts seems too obscure for someone not used to C and C++.

Regards

[guillaumechereau]

You are correct that the voxels index in a BL16 block is: x + y * 16 + z * 16^2.
The colors are stored as 4 bytes: RGBA.

On a side note: at some point in the future I think I will update the gox format to use a binary json representation instead of my hand made format, so that it will be easier for people to implement parser and manipulation tools in other language.

[norman784]

It's weird that my implementation isn't reading it right then, will continue to debug and try to find what's going on. The transform contained in layer doesn't have any rotation information?

Will be cool to have it, did you have some ETA to have it or start working on it?

Edit: If you have some sort of curiosity about my library is written in rust and I just called it gox (isn't available yet as a crate because isn't ready yet), maybe you can take a look and give me some hints, tips or even check if something that you think I'm doing it wrong, tried to emulate the way you parse it but isn't as optimized as yours yet.

[guillaumechereau]

The 'mat' attribute in the layer is a 4x4 matrix that encodes both a rotation and translation. Note that this is only used for special layers: normal mesh layers don't have an transformation applied.

This discussion makes me realize how easier the gox format could be. I really think I will update it at some point to be based around a json binary representation, something like amazon ion. The 'trick' I used of saving the blocks as png files is also not really needed I think.

[norman784]

How much changes requires to migrate from the current file format to binary json? I mean you don't need to change anything besides the save/load in gox.c?

[guillaumechereau]

The difficulty would mostly be to find the right format since there are a few standards for binary json. I haven’t looked much into it. Amazon ion seems pretty close to what I need, but I am worried it’s not standard enough. Also if I change the format I will need to still keep at least the reader for the old one so that I don’t break people saved files. I’ll probably keep this for the future. The next thing I will work on regarding goxel will be improving the path tracer and supporting different materials, transparency...

…

On Sun, Jan 6, 2019 at 11:59 PM Norman Paniagua ***@***.***> wrote: How much changes requires to migrate from the current file format to binary json? I mean you don't need to change anything besides the save/load in gox.c? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#131 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGkn2uAwE0P1ixBggJhHBE-KKHqnbqvks5vAh1ngaJpZM4ZrwAZ> .