Add support for SDF-based CSG-Shapes (like in MagicaCSG)

[novemberist]

Describe the project you are working on

No specific project, but this would be usefull for any 3D project when you want to quickly build prototype/placeholder assets

Describe the problem or limitation you are having in your project

Prototyping with the current CSG implementation is very limited and kind of hard to work with

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Since SDFs are already used in many places in Godot (Particles, GI) it might be worth considering to make use of them for CSG

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

I don't have the knowledge to talk about a possible implementation or how efficient this would be compared to the current implementation. But inspiration could be drawn from software like ephtracy's new MagicaCSG. which let's you produce good results with ease

Maybe such models could even be imported/exported between applications

If this enhancement will not be used often, can it be worked around with a few lines of script?

I don't think this can be implemented with a few scripts

Is there a reason why this should be core and not an add-on in the asset library?

CSG Shapes are already part of the core engine, so this would be an enhancement rather than a completely new feature

[Xrayez]

Looks like there's a plugin by @Zylann which does something similar: https://github.com/Zylann/godot_sdf_blender.

[novemberist]

Looks like there's a plugin by @Zylann which does something similar: https://github.com/Zylann/godot_sdf_blender.

Oh, dearie me. I must have totally missed that one. I should probably have known that @Zylann was already one step ahead again. Maybe Zylann could comment how well this works as a plugin or if this would make more sense as a core feature? Maybe some of the menitoned limitations of the plugin could be overcome.

[mrjustaguy]

As SDF is most often done on a GPU, this could yield in Performance benefits, potentially allowing it to be used for real-time destruction without the sharp decline in performance of the current CSG Implementation (which is atm single-threaded afaik), or at least allow for significantly more easy destruction compared to the current implementation which starts struggling to stay within 60 fps with a handful of thousands of triangles being CSG-ed every frame, and might be an approach that doesn't have the plethora of edge-cases that cause bugs (such as CSG Crackling - godotengine/godot#43755)

[Calinou]

SDF-based object rendering, while useful for some edge cases, comes with its whole lot of downsides and limitations such as #1942. Due to this, it's difficult to use SDF objects in a real world project.

Prototyping with the current CSG implementation is very limited and kind of hard to work with

This means we should try to improve the CSG editor usability instead 🙂

If we add SDF nodes but they suffer from the same usability issues, you won't have a easier time prototyping 3D assets.

[novemberist]

SDF-based object rendering, while useful for some edge cases, comes with its whole lot of downsides and limitations such as #1942. Due to this, it's difficult to use SDF objects in a real world project.

Prototyping with the current CSG implementation is very limited and kind of hard to work with

This means we should try to improve the CSG editor usability instead slightly_smiling_face

If we add SDF nodes but they suffer from the same usability issues, you won't have a easier time prototyping 3D assets.

Sorry if this is a naive question, since I don't know much about the technical details of SDFs, but could the models that were construced in the editor be converted to regular meshes for actual in-game rendering?

[Zylann]

IMO, it seems to me the shadow map limitation is not really a true technical challenge, it's more that the way Godot expects your 3D content to be does not match what happens with raymarching. The idea of shadowmapping is to render the depth from the point of view of the light (which Godot does, and raymarched content also does if you allow its fragment shader to run so it can provide depth). Then pixels can get shadowed in the main rendering by querying the shadowmap per pixel, which is also possible if you allow again the fragment shader to do so.

About performance: animating raymarched SDF at runtime is costless, you can modify it entirely every frame if you like, since it is re-rendered entirely each time. But the more complex it gets, the more expensive it becomes (my plugin does not optimizes anything in that regard), unless some solid data structures and rendering techniques are put in place. This is a very different design than purely mesh-based rendering. It is possible to make hybrids though, where polygons are used to place "surfaces" or AABBs where stuff roughly is, kinda like a broad phase, and then raymarch content as narrow phase, more locally. It also means vertex shaders performance becomes negligible, while the cost of a pixel rises dramatically. This means forward rendering is getting costy, and temporal/deferred techniques might be better suited to separate costs and smooth it out over several frames.
I think CSG can be improved too, but it probably suffers the same issue if you keep adding many operations to the bunch, unless maybe some get collapsed if they are determined to cancel each other out.

It is also important to note that usage of SDF is not limited to in-game content, it is also a powerful tool for asset creation. You get incredible flexibility at design time, and when you're done, you can bake it as a classic mesh. However, in this case Godot is not necessarily the best tool for it, compared to MagicaCSG.

Still... if there is a way to bring SDF rendering to Godot for in-game content, that still unlocks a crazy range of possible artstyles and effects. Just look at the game Dreams, , or the Unity plugin Clayxels, to see what's possible.

[novemberist]

It is also important to note that usage of SDF is not limited to in-game content, it is also a powerful tool for asset creation. You get incredible flexibility at design time, and when you're done, you can bake it as a classic mesh. However, in this case Godot is not necessarily the best tool for it, compared to MagicaCSG.

There will probably always be better external tools for producing your final assets or even good placeholder assets. But I think especially something like tools for level prototyping (which is probably what most people would use the current CSGs for) should definitely be inside the Godot editor. This is not something you want to import and export all the time from an external application.

Do you think the use of SDFs could be beneficial in that area?

[Calinou]

But I think especially something like tools for level prototyping (which is probably what most people would use the current CSGs for) should definitely be inside the Godot editor. This is not something you want to import and export all the time from an external application.

For level design, I'm not sure if SDF is really desirable because it's costly to render (the SDF will occupy a large part of your screen) and texturing may be difficult to do accurately.

[novemberist]

But I think especially something like tools for level prototyping (which is probably what most people would use the current CSGs for) should definitely be inside the Godot editor. This is not something you want to import and export all the time from an external application.

For level design, I'm not sure if SDF is really desirable because it's costly to render (the SDF will occupy a large part of your screen) and texturing may be difficult to do accurately.

That's where the "baking to traditional mesh" mentioned by Zylann might make sense. So SDF would mainly be there for the ease of use when editing/designing and not so much for its benefits when rendering the game. For prototyping tools I think ease of use beats performance cost (and possibly accuracy for texturing) anyway, since you probably won't use those creations in your final game.

[mrjustaguy]

Yeah, having SDF data, and baking to polygons when there's a change makes sense, that way there's no SDF rendering and the computation is only done when something happens, because it's just used to generate the Mesh, which also potentially allows for Triangle targets..

[alexfreyre]

Please all interested on this topic see this library made for MaterialMaker.
The next MM version will support export SDF shaders as Godot shaders, maybe all this is useful in this discussion.

https://github.com/paulofalcao/MaterialMakerRayMarching