[2]Implemented bencode serialization for Node and Octree

[davids91]

Since I'd like to have the values stored, and have it as effective as possible I implemented some traits.

As an improvement in the future Nodes at certain LOD-s could be handled separately, so on-demand load could be possible. The current implementation makes it possible; but it only loads/saves the root node currently

[Adam-Gleave]

Hello!

Thanks for this PR, definitely agree that serialization would be nice to have, and pretty necessary towards publishing the crate anywhere.

However, I'm a bit wary about using this method, it seems pretty esoteric. I think a nicer route would be to just use the standard serde traits behind a feature gate, and then let the downstream user decide on a format (JSON/bincode/etc).

[davids91]

That's a good thought, but for Voxel octrees there's also GVOX which provides more convenient voxel features.

For me this worked, but I ran into some performance issues, so Currently iterating on that. I actually Found it through serde; So targeting it sounds like a good plan

[davids91]

Another thing worth considering is that lazy-loading should be possible with this!

[davids91]

I separated the actual serialization methods here: https://github.com/davids91/svo-rs/blob/840ae2e883ade26e2a0a91cf9bb2cf04d31ead9e/src/node.rs#L392

I think that is something easily aligned with serde!
Might I suggest that this itself be pushed behind a feature, only if temporarily?

[davids91]

Hey @Adam-Gleave I hope you are well! After implementing what you suggested in a separate repo: https://github.com/davids91/shocovox

I have come to the conclusion that performance-wise it would be better to use bendy itself, instead of ( or at least next to ) serde. The reasoning behind this is quite simple: as serde has a generic use-case target, I find it needs to write out the names of the struct fields it serializes.

The implementation provided here does not do that, it uses an implicit, order based identification of the struct fields (i.e.: the implementation is so that the field size is the first to be encoded, then follows min_position etc..). Because of this the process handles much less data.

So let's compare apples with oranges! The other implementation using serde has the following performance data for a size 32 octree:
init: 8.40325797 ms
write: 91.6077816 ms
read: 42.742902750000006 ms
query: 2.91500421 ms

The exact same things with my fork of your implementation:
init: 5.4165747799999995 ms
write: 25.533011939999998 ms
read: 7.66889124 ms
query: 1.7162132100000005 ms

Still the direction is yours to decide, I jut thought this would be relevant information!