search

dust-engine / dot_vox

Rust parser for MagicaVoxel .vox files.
MIT License
51 stars 20 forks source link

Query for overall size of the model in `DotVoxData` #46

Closed davids91 closed 4 months ago

davids91 commented 4 months ago

From what I gathered, the data is iterable as a tree, where the leaf nodes are Models. The maximum position can be determined by the parent Transform offsets, and the models size.

Is there a way to get this information without parsing the whole structure? It is possible, but really impractical for my usecase as declaring the structure I'd like to convert to requires to have the size of the overall data beforehand.

Neo-Zhixing commented 4 months ago

Are you trying to allocate a big 3D array and copy all data into that 3D array?

The MagicaVoxel scene graph was really designed with instancing in mind, so I would advise against pre-allocating a big 3D array. Instead, the transform data should be used during rendering instead.

davids91 commented 4 months ago

Hi, and thank you for the answer! Can you expand a bit on what you mean by "instancing in mind" ? The SVO I am planning to use these in requires the dimensions to be specified in advance, so the area covered by the SVO is well defined.

Neo-Zhixing commented 4 months ago

So, you have a scene graph and the scene graph references models on the leaves, right?

The model index on the leaves may not be unique, so the same model may show up multiple times in your scene at different locations. This is called instancing.

In your case, it would be inefficient to copy everything into your big ESVO because you're going to end up storing duplicated data. In general, it's just a bad idea to have your scene size constrained by the size of your SVO.

Now, for you question, no the overall scene size isn't something embedded into .vox files. I also don't think it's a good idea for dot_vox to offer the capability to calculate the scene size - at the end of the day, it's a parser library for the .vox format, not a voxel game toolkit. And we're going to have to do the same O(n) traversal anyways.

davids91 commented 4 months ago

Thank you for your explanation! It was inspiring, as I think my implementation can be improved by integrating this concept of duplication elimination! The structure I implemented is 100% compatible with this.

One minor comment though, is that redundancy is not necessarily inefficient. Depends on the usecase.

I understand the feature I requested is not available and never will be; Thank you for the feedback on that as well!