VoxelMeshInstance

[Zylann]

VoxelTerrain is nice and all but for small models and tests having a finite non-chunked way of rendering voxels would be useful. Roughly same settings as VoxelTerrain, but with ability to throw in a VoxelBuffer, or a VoxelStream of finite size. For editor usability this could make use of a VoxelMesh resource which would basically wrap a VoxelBuffer and an ArrayMesh.

[antopilo]

imo this would work fine. I was using an arraymesh combined with meta data for the voxel buffer you said and it worked great.

[TokisanGames]

Being able to connect this to a physics body would be super awesome, too! Then we could have a full on destructable world.

[Zylann]

I'm not excluding the possibility of having paged voxels with rigidbody behavior (which further explains why I considered renaming "terrain" as "volume"), but that would be for far future testing. The reason paged exists is to exploit frustrum culling, allow streaming and smooth out mesh updates.

I'd like to make a demo in the future where a new floodfill utility could be used to destroy small chunks of the terrain which would turn into rigidbodies and fall with physics.

[wi-ski]

Do you guys have snippets/code-pointers that achieve something like that? (rigid body etc.)

I'm toying around with the idea of wall segments that behave like: https://www.youtube.com/watch?v=aAgVSTrqNOc&t=370s

Even 10% of that user experience would be awesome right?

[Zylann]

@wi-ski the technique used in that video is very different from what this module does (it heavily uses GPU to render). Breaking that many voxels at once won't be as fast, but breaking chunks is still doable, I have some untested WIP at home for detecting "islands" after cutting parts (connected-component-labelling), and what I mentionned with VoxelMeshInstance is just a simpler way to instanciate those smaller chunks as separate nodes. Currently you have to use a mesher and voxel buffer directly to produce a mesh. Aside from bugs that's one thing I'd like to work on next, for now I don't have dedicated time.

[wi-ski]

Roger roger, I think I understand.

Also, this needs to be said: Thank you for the work you dedicated to this already, I've learned a lot just from this repo alone.

You said:

Currently you have to use a mesher and voxel buffer directly to produce a mesh.

:point_up_2: I wanted to confirm, you meant: Currently, the developer must 'manually' detect/instantiate voxel chunks - and that behavior would be provided 'automatically' by your connected-component-labelling behavior?

Ignoring the 'chunking' nature present in that demo, I feel like there would be fun user experience to be had destroying voxelized buildings but using smaller/more granular voxels with a brief moment of rigid body behavior on voxel death.

Not to be overly blunt/oafish with words - but an "adult minecraft without paging terrain" is the emotion Im going for. Before I burn any more time - does this sound silly/naive? Is there some scaling issue you can foresee already?

[wi-ski]

Ah - on second read, did you mean the linked demo uses GPU to crunch voxel data? And having smaller voxels would - by the laws of scale - not scale well at all with the current CPU approach.

[Zylann]

👆 I wanted to confirm, you meant: Currently, the developer must 'manually' detect/instantiate voxel chunks - and that behavior would be provided 'automatically' by your connected-component-labelling behavior?

That's two different things: this issue is about simplifying the task of creating a simple monolithic mesh from voxels while supporting a similar API to terrain nodes. Currently that's already doable but it requires some manual work. Connected-component labelling is something else I mentionned in reaction to the idea of dynamically cutting through the world and create debris with physics. Which is made easier by having a VoxelMeshInstance to instanciate the resulting debris.

Not to be overly blunt/oafish with words - but an "adult minecraft without paging terrain" is the emotion Im going for. Before I burn any more time - does this sound silly/naive? Is there some scaling issue you can foresee already?

If you want the same thing as Dennis Gustavsson work, this module might get something like it, but my gut feeling is, it won't get close to what he did in terms of scale, until the GPU gets heavily involved into rendering such voxels. This module turns voxels into polygons (like Minecraft, Voxel Farm or No Man's Sky). I believe Dennis' game renders voxels directly using a fragment shader and lots of memory.

[TokisanGames]

I believe it's custom physics, voxels and ray tracing all on the GPU and requires a minimum of a GTX 1070. However most of that is likely due to the ray tracing.

[TokisanGames]

However, this was done in UE4 with an MIT licensed voxel plugin. The pro version adds physics to separated voxels.

https://youtu.be/V72dJoeJ_Uk

https://github.com/Phyronnaz/VoxelPlugin/blob/master/README.md

[Zylann]

@tinmanjuggernaut I don't see separated voxels in that video (only particles), but I wonder if that one uses raymarching? It could also be that their access to mesh upload with the renderer is more efficient than Godot. For sure with UE4's renderer there are more options.

Edit: ah, this is what I'm talking about :p https://www.youtube.com/watch?time_continue=28&v=yzxKTLisOGw&feature=emb_title

[TokisanGames]

My example was closer to Dennis's game video we were discussing with a C++ cpu implementation, but yes you found the voxel physics demo. This plugin looks interesting and with the quixel acquisition I've gotten interested in UE4 again.

And it's MIT so maybe it's a resource for you. It uses marching cubes. The LOD transition is buttery smooth. 256 materials! And he's working on surface nets which provides a little more accurate mesh and half the vertices.

Edit: UE4 has had DX12 and vulkan for a while as well as a mature pipeline, so I'm sure there are many things it can do that Godot 3 can't touch.

[wi-ski]

❤️ Wow. Thank you guys - for the pointers & knowledge. I compiled UE4 last night and will give that plugin a shot.

You guys are a fantastic duo, ty again.

[Game4all]

It would be great if the node could support setting the voxel size in the generated mesh (should be doable as there is no local / global coordinates conversion to do for that node; this was a blocker for VoxelTerrain node.)

[Zylann]

@Game4all this is something to address with all nodes rendering voxels, see https://github.com/Zylann/godot_voxel/issues/105