How to make voxels smaller?

[Froidoh]

Hey!

Thanks for sharing your work!

I am currently experimenting with the library and bevy and am curious: How would I make the voxels smaller?

Setting the octree size to a higher multiple of 2 doesn't do the trick... as far as I understood it's just the amount of voxels in each dimension, but not the "depth".

One can play around with the LOD and say tree.insert_at_lod(pos, 2, color) which means that the "leaf node" is one depth up (so a bigger "chunk" is filled), but so far I've not found a way to make the voxels smaller!

I am thinking like a 4th of a minecraft block or even smaller.

Thanks for any kind of direction you provide!

[davids91]

Hi! Thank you for your interest! :)

If you are thinking of the scale of the octree, the logic is relying on the octree coordinates to be between 0..size;

However the viewport can be used to compensate for that, you can refer to the bevy example:

https://github.com/davids91/shocovox/blob/413f3db1de430c6cb8753487fc478a3fd38a54f0/examples/bevy_wgpu_render.rs#L88

In this case the displayed size is depending on the ratio of viewport_size / octree_size.

Please do tell if you manage to make a minecraft-like game with this! :star_struck:

[davids91]

I extended the example to showcase it: https://github.com/davids91/shocovox/blob/2d1e49610dac122afc4de94e46ba6c3d8915d5d1/examples/bevy_wgpu_render.rs#L157

Is this what you were looking for?

[Froidoh]

Oh wow, thanks. Well, I think you... I'm not sure yet.

What I am really after in the end is something akin to: https://www.youtube.com/watch?v=74M-IxtSVMg

For that I am currently investigating shocovox and https://github.com/ria8651/alex

[davids91]

Ah for sure I think alex is rasterizing voxels before rendering so it might be better suited for large-scale stuff.. Right now I just couldn't find a way to fit anything over 64x64x64 into a rendering pipeline, as it's real time.

I was thinking a lot about this limitation and is struggling to overcome that. In order to get reflection and refraction there's rally no way around having the whole data in FOV ( as the data itself needs to be part of the same render pipeline in order to access it from the GPU )

But I do have another method under implementation which would overcome this, it's not even published yet

[Froidoh]

Sounds interesting.

AFAIK alex doesn't rasterize (if you mean that it creates triangles), but raytraces as well. I may be wrong though.

Douglas does rasterizing AFAIK and greedy meshing.

[davids91]

I was basing my assumptions based on this line: https://github.com/ria8651/alex/blob/3fcc1d720ae722b6261e470854a287b74ec7e4da/src/bin/voxelize/block_model.rs#L5 not sure though as I have not gone in depth, but if Alex managed to do what it does without rasterization, it is for sure better suited for your intentions.

One optimization I can think about that alex might use is the reduced dimensionality of the data ( as in 3D vs pseudo3D with e.g. heightmaps )

I asked for confirmation :)

[ria8651]

Hello, thanks for the interest :D

That line is part of voxelizing Minecraft assets to use as block models. However, my main rendering loop is based on a hybrid rasterizing/raytracing system. The screenshots on the readme are from before I did hybrid rasterizing/raytracing so it should be much faster now, but I haven't added back in shadows. It does run in real-time on my M1 MacBook. I don't any kind of hightmap, it should all work with arbitrary voxel data though I've only tested Minecraft worlds. Do note that while it renders quite fast the streaming and world loading is pretty slow. That's the next part I want to work on.

[davids91]

Thanks for your work! It's an awesome addition to the ecosystem!

[davids91]

@Froidoh with this I think I can close this issue now, please reopen if you have not had your question answered, and feel free to open another issue shoudl you have any more queries!