dust-engine / dot_vox Goto Github PK

Could you release a version 5.2.0 to crates.io soon? I ask because:

• #37, restoring compatibility with stable Rust, has been merged but not released
• The last stable-compatible version, 4.1.0, now results in a future-compatibility warning in Rust 1.68.0 (due to using an old version of nom).

Hi, and thank you for this great lib once more! :)
I am deep in parsing the file format and in most cases I am able to read in simpler models.
However I am unable to parse complex models as the provided transforms seem to be off.
The following model starts from the center bottom:

But upon reading it in with the library the following scene array is parsed:

[0] Transform { attributes: {}, frames: [Frame { attributes: {} }], child: 1, layer_id: 4294967295 }
[1] Group { attributes: {}, children: [2] }
[2] Transform { attributes: {}, frames: [Frame { attributes: {"_t": "-1 -2 57"} }], child: 3, layer_id: 0 }
[3] Group { attributes: {}, children: [4, 6] }
[4] Transform { attributes: {}, frames: [Frame { attributes: {"_t": "0 0 48"} }], child: 5, layer_id: 0 }
[5] Shape { attributes: {}, models: [ShapeModel { model_id: 0, attributes: {} }] }
[6] Transform { attributes: {}, frames: [Frame { attributes: {"_t": "0 0 -8"} }], child: 7, layer_id: 0 }
[7] Shape { attributes: {}, models: [ShapeModel { model_id: 1, attributes: {} }] }

vox tree model sizes: 
[0] Size { x: 16, y: 16, z: 16 }
[1] Size { x: 16, y: 16, z: 96 }

The way I understand this: https://github.com/ephtracy/voxel-model/blob/master/MagicaVoxel-file-format-vox-extension.txt
guide, the positions just don't add up.

First of the leaves part of the model tree is added up to start from Z value 105 ( Right handed Z up coordinate system ), so that seems to be correct. This is added up from its parent transforms, [2] and [4].

However, the second model, which is the trunk of the tree model just doesn't add up to its position, as supposedly it starts at z value 48, which overrides the other model, and is much higher, than it is supposed to be..
In the below rendering of the parsed tree the result is shown, the heights ( z coord ) are marked at 105 0nd 120:

Do the models start at the bottom-left-near corner of the transform?

First off I want to thank you guys, I want to do some experimentation in the near future with voxels and marching cubes.

I made a simple .vox file in MagicaVoxel 0.99.6.4 with two adjacent 'models.' My intent is for them to represent static terrain data, and to be considered different 'chunks.' The problem is, I don't know how to find their coordinates relative to each other. I.E. one of the models is immediately to the 'right' of the other, but neither model lists their world space coordinates, and all the voxels inside each model are relative to the model's space.

Am I just missing something obvious about how I can find the world relative locations of all the voxels in each model?

A .vox file can contain a custom palette. If it does not, then a default palette (https://github.com/ephtracy/voxel-model/blob/master/MagicaVoxel-file-format-vox.txt#L97) should be used.

The parser should supply the appropriate palette as part of DotVoxData.

Hey! Thanks for the awesome library!
I'd like to support it with a voxel raytracing engine I'm writing.

I started to implement parsing the files based on the library here, but I kind of got stuck on the used coordinate system, as I expected it to be Y-Up, but after displaying a model, I assume it is Z-up, from the teapot model I parsed:

in the editor:

In the engine:

Is this in alignment with the implementation? What coordinate system is being used within the format?
Z-up/Y-up - Left handed, right handed?

It would be nice to have this documented.

Magicavoxel now has a sparse voxel octree format. I think it would make sense to have support for parsing and serializing in this format.

I understand this crate isn't actively developed, but I figured I'd just make this issue for the sake of bookkeeping if anyone find the time to implement this :)

The latest version of MagicaVoxel's file format can include one or more Material chunks after the pallete. These would be useful to have in the output object at some point.

It looks like the only remaining major feature left is to extract the scene graph information:

(d) Scene Graph

T : Transform Node
G : Group Node
S : Shape Node

     T
     |
     G
    / \
   T   T
   |   |
   G   S
  / \
 T   T
 |   |
 S   S

=================================
(1) Transform Node Chunk : "nTRN"

int32	: node id
DICT	: node attributes
	  (_name : string)
	  (_hidden : 0/1)
int32 	: child node id
int32 	: reserved id (must be -1)
int32	: layer id
int32	: num of frames (must be 1)

// for each frame
{
DICT	: frame attributes
	  (_r : int8) ROTATION, see (c)
	  (_t : int32x3) translation
}xN

=================================
(2) Group Node Chunk : "nGRP" 

int32	: node id
DICT	: node attributes
int32 	: num of children nodes

// for each child
{
int32	: child node id
}xN

=================================
(3) Shape Node Chunk : "nSHP" 

int32	: node id
DICT	: node attributes
int32 	: num of models (must be 1)

// for each model
{
int32	: model id
DICT	: model attributes : reserved
}xN

which is an extension https://github.com/ephtracy/voxel-model/blob/master/MagicaVoxel-file-format-vox-extension.txt

This doesn't seem like a whole lot of work since much of the groundwork is already laid, but i'm not really sure?

Hi! I am just diving into your project, because I think it's a great candidate to use in reading in model files for my raytracing engine! :)

Are there any usage examples available? e.g. reading in a file from the system and sampling it?

I actually figured it out from docs, I just think it would be a great addition to the lib!

It's great to be able to parse VOX, but it would also be nice to save in that format as well!

Releases 5.0.0 and 5.1.0 contain #![feature(let_chains)] and won't compile on stable Rust. Is this intentional, or a development branch experiment that leaked out? I don't see any use of let_chains, so it seems like it isn't necessary, and I don't see any mention in the README or crate documentation that the package is intentionally nightly-only.

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.

I see the position of the models are stored in the "_t" attribute in the frames. However, in the first frame there is the rotational information also available in the "_r" tag, but not parsed.

This is problematic for models using this feature; Would it be possible to extend parsing and making this available?

When a file with the older format is parsed, we currently panic with a not-too-helpful error message. We should instead make it clear that the file format is unsupported by this version and provide the options of either downgrading to v2.0.0 or upgrading the file through MagicaVoxel, and supply an empty object or an error.

hey! Im pretty newbie in rust. Just finished extracting voxel position and it's all works, but how to extract rgba data for each voxel? Thanks!

According to the spec,

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

the palette IDs are off by one, so you need to minus one from them to get to the right colour, e.g:

let voxel = &vox.models[0].voxels[0];
let colour = vox.pallete[voxel.i - 1];

I'm sure i'm not the only one that will get tripped up by this. Do you think you could clarify it in the documentation?

I am not familiar with nom at all, but upgrading to nom 4 will drop a lot of old transitive deps (many of which can't work with wasm targets); the major change in nom 4 appears to be IResult -> Result iiuc?

I just upgraded dot_vox to the last version (from commit 8aeb367) and my .vox file loading fails because my DotVoxData.pallete field only has 255 elements (where 256 expected).

Seems the culprit is this change :

-named!(parse_pallete <&[u8], Vec<u32> >, complete!(do_parse!(
-    take!(8) >>
-    colors: many_m_n!(256, 256, le_u32) >>
+named!(pub extract_pallete <&[u8], Vec<u32> >, complete!(do_parse!(
+    take!(12) >>
+    colors: many_m_n!(255, 255, le_u32) >>

Hi,

i get the following panic with the below file (see attachment at bottom) with version 1.0.0

with the following code:

    let vox = dot_vox::load("vox/examplechar.vox").unwrap();

thread 'main' panicked at 'Unrecognised material type 4291624755 with weight NaN', C:\Users\xxx.cargo\registry\src\github.com-1ecc6299db9ec823\dot_vox-1.0.0\src\material\material_type.rs:24:18
stack backtrace:
0: std::sys::windows::backtrace::unwind_backtrace
at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:65
1: std::sys_common::backtrace::_print
at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
2: std::sys_common::backtrace::print
at C:\projects\rust\src\libstd\sys_common\backtrace.rs:59
3: std::panicking::default_hook::{{closure}}
at C:\projects\rust\src\libstd\panicking.rs:211
4: std::panicking::default_hook
at C:\projects\rust\src\libstd\panicking.rs:227
5: std::panicking::rust_panic_with_hook
at C:\projects\rust\src\libstd\panicking.rs:511
6: std::panicking::begin_panicalloc::string::String
at C:\projects\rust\src\libstd\panicking.rs:445
7: dot_vox::material::material_type::MaterialType::from_u32
at C:\Users\xxx.cargo\registry\src\github.com-1ecc6299db9ec823\dot_vox-1.0.0\src\material\material_type.rs:24
8: dot_vox::material::material_type::parse_material_type
at C:\Users\xxx.cargo\registry\src\github.com-1ecc6299db9ec823\dot_vox-1.0.0\src\material\material_type.rs:36
9: dot_vox::material::parse_material
at C:\Users\xxx.cargo\registry\src\github.com-1ecc6299db9ec823\dot_vox-1.0.0<named macros>:13
10: dot_vox::material::extract_materials
at C:\Users\xxx.cargo\registry\src\github.com-1ecc6299db9ec823\dot_vox-1.0.0<named macros>:34
11: dot_vox::parse_vox_file
at C:\Users\xxx.cargo\registry\src\github.com-1ecc6299db9ec823\dot_vox-1.0.0<named macros>:13
12: dot_vox::load
at C:\Users\xxx.cargo\registry\src\github.com-1ecc6299db9ec823\dot_vox-1.0.0\src\lib.rs:105
13: voxygen::game::Game::newstd::net::addr::SocketAddr,str*
at .\src\game.rs:47
14: voxygen::main
at .\src\main.rs:69
15: std::rt::lang_start::{{closure}}<()>
at C:\projects\rust\src\libstd\rt.rs:74
16: std::rt::lang_start_internal::{{closure}}
at C:\projects\rust\src\libstd\rt.rs:59
17: std::panicking::try::do_call<closure,i32>
at C:\projects\rust\src\libstd\panicking.rs:310
18: panic_unwind::__rust_maybe_catch_panic
at C:\projects\rust\src\libpanic_unwind\lib.rs:105
19: std::panicking::try
at C:\projects\rust\src\libstd\panicking.rs:289
20: std::panic::catch_unwind
at C:\projects\rust\src\libstd\panic.rs:392
21: std::rt::lang_start_internal
at C:\projects\rust\src\libstd\rt.rs:58
22: std::rt::lang_start<()>
at C:\projects\rust\src\libstd\rt.rs:74
23: main
24: invoke_main
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:64
25: __scrt_common_main_seh
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
26: BaseThreadInitThunk
27: RtlUserThreadStart
error: process didn't exit successfully: C:\rust\game\target\debug\voxygen.exe (exit code: 101)

examplechar.zip