Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better Algorithm for Voxel Graph #36

Open
william-silversmith opened this issue May 17, 2021 · 1 comment
Open

Better Algorithm for Voxel Graph #36

william-silversmith opened this issue May 17, 2021 · 1 comment
Labels
enhancement New feature or request

Comments

@william-silversmith
Copy link
Contributor

Currently, we increase the volume 8x in order to accommodate the voxel graph. For a 512x512x512 uint64 volume, this increases the memory usage.

# Non-Voxel Graph
1 uint64 volume: 1,073 MB
1 float32 output: 536 MB
Total: 1.609 GB

# Current Voxel Graph
1 uint64 volume: 1,073 MB
1 8x uint64 intermediate volume: 8,584 MB
1 8x float32 intermediate output: 4,288 MB
1 uint32 graph: 536 MB
1 float32 output: 536 MB
Total: 15.017 GB
@william-silversmith william-silversmith added the enhancement New feature or request label May 17, 2021
@william-silversmith
Copy link
Contributor Author

I suspect this could be done with a kind of multi-source dijkstra-like algorithm that colors in the "territory" of a point. When the search encounters another color, you test to see which is the minimum.

This would be roughly:

1 uint64 volume: 1,073 MB
1 uint32 "color" volume: 536 MB
1 uint32 graph: 536 MB
1 float32 output: 536 MB
Total: 2.645 GB

A similar kind of algorithm in dijkstra3d runs at about 4 MVx/sec (42 sec for a 512 cube) while the current 8x algorithm took > 100 sec on a faster machine. I suspect that this would be a bit faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant