Zylann / godot_voxel

Voxel module for Godot Engine
MIT License
2.6k stars 245 forks source link

Three sides of voxelTerrain are not getting holes #684

Closed se8820726 closed 3 hours ago

se8820726 commented 3 weeks ago

When applicable, please describe your setup:

I have a voxelTerrain node, and three sides of this terrain are not getting holes.

https://github.com/user-attachments/assets/525f9698-5aae-4b33-8556-baddd44fd88d

scene structure:

image
Zylann commented 3 weeks ago

Have you seen warnings while trying to do this?

Editing across borders like this is not supported. Part of the chunks you're trying to edit are likely not loaded. It's supposed to do nothing. Perhaps in your setup the checks supposed to disallow that haven't worked well, causing this weird state.

Looking closer, that may be caused by lack of support for incredibly small bounds. This terrain system was primarily made with infinite/large terrain in mind, so this is a situation that isn't well supported.

Here is what the boundary looks like after edition when using copy: image Blue is SDF<0, yellow is SDF>0 (hole). Voxels on the other side could not be edited because they are beyond fixed bounds. However, it seems voxel query logic is falling back on the generator in this case, making it look like the terrain continues afterwards, leading to a "wall". That wall is present on every side. It doesn't become visible on negative sides due to how the mesher polygonizes, The wall would have showed up too if neighbor chunks were allowed to be meshed beyond the limit (but they are not because... they are beyond the limit). Will probably need a few patches to check for bounds and generate "empty" instead.

se8820726 commented 3 weeks ago

Does that mean there's no way to at least remove these walls while creating holes?

Zylann commented 3 weeks ago

You can't remove them because they are outside of bounds where edited chunks can exist, and they don't technically "exist", they are "made up" on the fly due to the mesher falling back to the generator when it queries voxels to produce polygons. Copy/query functions also behave like that, because they assume that "chunks without voxels but considered to be loaded are assumed to be non-edited, therefore fallback on the generator" (not all voxels are "stored" depending on the setup, so that's why such behavior eventually occurs). In that sense, a possible workaround would be to have your own generator that returns empty chunks when querying outside of the area you want. Though it may be better for bounds to be accounted for before the generator gets invoked.

Zylann commented 3 weeks ago

I pushed a change that makes it so voxels beyond bounds are considered empty, so you no longer get "walls" when digging beyond it, and copying voxel data also returns air.