Nested voxel modifiers

[sjkillen]

Is your feature request related to a problem? Please describe.

I have a post-import script that converts mesh instances into voxel modifier meshes. The modifiers do not work unless they are immediate children of a voxel terrain. If an imported scene contains multiple instances, they cannot be made scene root.

Describe the solution you'd like For modifiers to work if they are nested children of Node3D nodes

Workaround Collapse the parent structure of the modifiers after import. However, this only works in runtime and not in editor

[sjkillen]

(Possibly) relevant TODO https://github.com/Zylann/godot_voxel/blob/02596c14d6ce6a444300284204054de61a00188b/modifiers/godot/voxel_modifier_gd.cpp#L132

[sjkillen]

For NOTIFICATION_LOCAL_TRANSFORM_CHANGED Here https://docs.godotengine.org/en/stable/classes/class_node3d.html

This is not received when the transform of a parent node is changed.

If we have nodes under the terrain update their children when their local transform changes, we might be able to get around subscribing to global transform changes

[Zylann]

Something I find really annoying in this situation, is that the hierarchy seems useless here, it's just in the way and requires the engine to do extra work. What makes it required is the import workflow and the way Godot works I guess? Though I'm not fully understanding why your scripts can't also automate the flattening of hierarchy, so that everything gets setup optimally (Think of it like CollisionShapes of a RigidBody).

Optimization aside, nested modifiers are a natural thing to support eventually, but didn't have the need for it before, and the way Godot propagates events has put me off the moment I had the suggestion in mind. In fact I'm not using modifiers much at the moment, I originally added them because it seemed cool to have, as I saw another voxel engine have something similar. But I moved on other things and didnt take time to update them as a result.

[sjkillen]

I can see it also being useful for parent/child transforms, but that's also achievable manually.

As far as I know, an EditorScenePostImport must return a scene which becomes a packed scene resource which, as far as I know, can only have a single root. So it's impossible to flatten the structure from an EditorScenePostImport It might be possible from an editor import plugin, but that's less convenient.

In my mind, it wouldn't be ideal to merge meshes into a single mesh SDF as each one has limited bake precision -but that assumption comes from my limited understanding of their implementation.

If you don't think it would be too non-trivial, I might have a shot at implementing it.

[Zylann]

Couldn't you import your scene as a terrain? Or when you instantiate these imported scenes, can't you just pick their children and put them as child of the terrain? These workarounds seem relatively easy, compared to adding an entire support for nesting just to workaround Godot's import workflow in the first place.

But if you really want this instead, you could try implementing it, as I don't plan to work on it at the moment.

[sjkillen]

I think it would work to have a separate terrain for each import as you suggest. Although if this were the case would the data all be separate? I could reparent the children at runtime very easily, but imported scenes can't be edited in the editor.

It seems like a fun task and a good way to get my feet wetter :)