Godot: A tool for blocking out levels

[mrzapp]

Idea
I am considering implementing a tool for blocking out levels. They are called geometry brushes in the Unreal Engine, and they are a very helpful design tool, once you become fluent in their usage, as well as a huge time saver. They are based on BSP in Unreal, but a more modern implementation of this could be beneficial to Godot.

Rationale
With the current workflow in Godot you have to build all of the geometry in Blender, export it, hope that the imported asset is updated, fix normal errors, etc. before you can test your game. Either that, or you'd have to build your prototype using a lot of StaticBody+MeshInstance+CollisionShape combinations, which would be a structural mess and probably a memory hog. This feature would be a way to improve this workflow significantly.

Features in order of importance

• Mesh merging (CSG)
• Collision geometry generation
• Navmesh generation
• U/V mapping and texturing
• Mesh deformation

Questions

• Who else is interested in this feature? (If nobody is, I won't make a pull request out of it)
• Which node composition would be best? Perhaps derived from StaticBody with CollisionShape + MeshInstance + NavigationMeshInstance nodes as children?
• Do you have any other features in mind for this tool worth mentioning?
• Is there an API for merging meshes with CSG? (#7844 seems to suggest there isn't)
• And most importantly, where should I start in the engine code?

Disclaimer
I am a decent programmer, and I've made a lot of tools for Unity in the past, so I don't need much hand holding throughout, I am just looking for a push in the right direction. It is my first time contributing to Godot specifically though, which is why I do have some questions initially.

[reaply]

I'm posting in the issue just to state that I'm all for this feature. BSP is a wonderful thing to work with like you said. Blocking out levels will increase productivity/ level design while also being performance efficient. CSG would be nice too but from my understanding is that it would be way more complex to create.

[mrzapp]

CSG is no joke, it is hard. Luckily there are libraries out there to take inspiration from. On that note, what is the preferred way in Godot to include a library? GIT submodules?

[ShyRed]

As far as I know the source of libraries is always copied into Godot ( see https://github.com/godotengine/godot/tree/master/thirdparty ) and the readme file is updated with information of what library is used, where the source has been taken from and in what version and if changes to the 3rd party source have been made. The 3rd party library license must allow for this, of course.

Though, you might want to get in contact with the Godot dev team first to clarify if they're ok with having the feature in Godot per default or prefer it being added as a plugin via Godot's asset-library (using GDNative etc.).

Pinging @reduz and @akien-mga

[Calinou]

Note that Cork is licensed under the LGPLv3, which we can't use in Godot; we can only use permissively-licensed libraries (due to iOS support, among other concerns).

I've tried out RealtimeCSG which is an Unity add-on. It has a compelling feature set, but it took years for the developer to get there.

TrenchBroom is also worth a look, especially for the UI side of the level editor. It's the most usable level editor for Quake-derived games I've used. However, having a built-in level editor in Godot will provide features an external editor cannot provide, such as accurate real-time feedback on materials and lighting.

[Zireael07]

Speaking of unity addons, there's SabreCSG https://github.com/sabresaurus/SabreCSG

(I know we can't just drop it in but surely something to look at?)

[mrzapp]

@Zireael07 that's probably a better reference then, since it's MIT licensed.

[ILoveGodot]

Isn't this a duplicate of some issues? Here are some where CSG is mentioned: #14506, #1920, #1381 and #4304.

Quoting reduz in #1920:

I will close this, as it's not intended to be a built-in editor feature.
Instead, support for SabreCSG could be added via GDNative now

So you basically want something like ProBuilder (https://www.youtube.com/watch?v=Kjqx6cKUepc, it'll be part of Unity in the future and is free now)? Aren't there already people working on this? I read several times from different people that they wanted to implement this. I even saw someone on Discord working on a GDScript plugin. The guy posted some screenshots of it:

It would be a waste of time and effort if multiple people work on their own implementation.

[ShyRed]

I even saw someone on Discord working on a GDScript plugin. The guy posted some screenshots of it:

Who are they and are they still actively working on it? The thing is that in #9046 it turned out that GDScript is not (yet) up to the task of intensive calculations / mesh generation. I'm not sure, if a CSG editor can be done in GDScript right now. Then again, the meshes generated in CSG are usually not as huge as the ones used for terrains...

The editor could be done as a plugin (like reduz proposes) or it might be possible to open this for discussion again, because

1. reduz himself wants a terrain engine / editor inside Godot ( https://github.com/godotengine/godot/issues/9046#issuecomment-348755653 ) while this could also be done via a plugin (why have terrain in engine, but not csg?)
2. if Unity is incorporating ProBuilder, then there is enough demand for it. We might want to satisfy this demand too in order to attract users.

[reduz]

I am fine with something like this BUT not in the core engine. I don't
think there is any need to bundle it.

On Sun, Mar 11, 2018 at 11:42 AM, Pascal Richter [e-mail]
wrote:

I even saw someone on Discord working on a GDScript plugin. The guy posted
some screenshots of it:

Who are they and are they still actively working on it? The thing is that
in #9046 https://github.com/godotengine/godot/issues/9046 it turned out
that GDScript is not (yet) up to the task of intensive calculations / mesh
generation. I'm not sure, if a CSG editor can be done in GDScript right
now. Then again, the meshes generated in CSG are usually not as huge as the
ones used for terrains...

The editor could be done as a plugin (like reduz proposes) or it might be
possible to open this for discussion again, because

1. reduz himself wants a terrain engine / editor inside Godot ( #9046
   (comment)
   https://github.com/godotengine/godot/issues/9046#issuecomment-348755653
   ) while this could also be done via a plugin (why have terrain in engine,
   but not csg?)
2. if Unity is incorporating ProBuilder, then there is enough demand
   for it. We might want to satisfy this demand too in order to attract users.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/17411#issuecomment-372120556,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2yhyCovhlzimDA3-l-flxt6Gix7hks5tdTfugaJpZM4SlRaR
.

[ILoveGodot]

Who are they and are they still actively working on it?

@ShyRed The author of this one is Lennardt#5663 on Discord. I already asked him. He is still working on it and gave me that screenshot as a progress update. I have never seen anything again from the others who wanted to work on this. I think this one is dead for example: https://github.com/Silvea12/GodotCSG

[mrzapp]

@ILoveGodot I will contact Lennardt on Discord and see where he's at, maybe we could collaborate on it.

[eon-s]

If the game does not need the tool on runtime, it could be a plugin (even with LGPL libraries if using GDNative) but may be annoying to download and install the tool for use every project, godot need "global" plugins for these editor tools.

[curieos]

I have interest in this feature. A big barrier for me using Godot is blocking out simple levels for testing. I don't have much experience with Blender or 3D modeling, and it adds extra nonsense for me to simply test things. I really enjoyed the BSP feature in Unreal, and I would love to help assist with this project if I can. I'm writing proposals for GSoC right now, should I talk to Lennardt on discord about this?

[tyradeveloper]

@curieos, it seems Lennardt has only focused on the GUI, he hasn't gotten around to the actual meat of it yet. So we are indeed starting from scratch when it comes to the CSG.

I think we can approach the design without any major UI, to be honest:

• A root node that calculates the CSG and uses it for collisions and mesh generation
• Subnodes that are basically MeshInstances with a few extra features like (subtractive/additive)

What can you bring to the table in terms of contribution?

[eon-s]

@curieos if is for GSoC, first talk with godot devs at IRC, read this for details https://github.com/godotengine/godot-roadmap/blob/master/GSOC-2018.md

[UsmaanSahak]

I have also prepared a GSoC proposal for this project. @eon-s Both times that I have joined IRC for Godot, it has been quite inactive. Is there any particular time that I should join chat in order to have a discussion with them?

[willnationsdev]

@UsmaanSahak part of that may be because GDC is happening this week, so there was a lot of preparation going on beforehand?

The IRC's activity tends to vary, and I don't really know when most of the users are active. There are many times I have been on there though, and a lot of active discussion was happening, so I'm not sure what the prime time is.

[UsmaanSahak]

@willnationsdev Yes, I was just recently made aware of GDC on the Discord channel. Fortunately, the IRC picked up in activity and I was able to get a response. Thank you for the heads up.

[curieos]

Turns out I can't participate in SoC this year, but I still have interest in this project and would like to assist if possible.

[mrzapp]

@reduz Since you changed your mind and even decided to implement it yourself, I am closing the issue. Thank you, it looks very promising!

[reduz]

@mrzapp yeah, I didnt realize doing the boolean style CSG was not much of an effort and not worth making it external. Guess I just overstimated the complexity.

[drequivalent]

@reduz great work on CSG so far (dynamic CSG is even better as this potentially means destructible maps). However, I think GSG also requires better snapping - like the one you see, for example, in Trenchbroom where it is actually hard to make something off-grid when you don't want to (check it out, I think a lot can be picked up from its interface, like brush manipulation via shift button, or a clipping tool)

[reduz]

@drequivalent ah, yeah probably snapping was not implemented, but should not be difficult to add.

[drequivalent]

@reduz I've seen Unity's SabreCSG making a whole new grid for itself after adding.
Also, any way to make CSG a collision object yet? Gotta be walkin' those floors and touching those walls.

[drequivalent]

@reduz also, great video on level editing tools: https://www.youtube.com/watch?v=brByJ5EVBn4

[reduz]

Just toggle the root CSG node collision flag I guess

[reduz]

@drequivalent Also, besides fixes (no snapping is clearly a bug) I won't add any new function, that's up to anyone using it to work on. So I hope the videos you linked inspire someone :)

[drequivalent]

@reduz Thanks, did not notice it.

[drequivalent]

@reduz well, I certainly hope that you'll be not only one working on Godot's CSG implementation, this thing is important. Unreal for example is popular and best known because of its map-editing tools, because of how easy it is to just fire it up and start creating in it, without much of external instruments or even knowledge. So Godot needs to take the best practices and make them its own.

[drequivalent]

Oh, and 17:18 mark on the video is just about snapping, by the way.

[reduz]

@drequivalent Well, that's kind of how open source works.. if someone wants to improve it (and there is actual interest in the feature), code is there. I just put the first stone.

[drequivalent]

Oh. Also important for level creation: ability to texture (or assign materials in this case, I guess) to individual surfaces. Don't know if it could be done in Godot though.

[eon-s]

@drequivalent open new issues about that so that way it will get more chances of being seen and possibly added.

[nodefish]

I realized the real annoyance of using CSG to block out levels is that scaling expands/shrinks the mesh in both directions at once, and then you have to manually recenter the mesh for every single adjustment you make, whereas moving faces is much easier, so I made a really simple tool as a proof of concept:

https://imgur.com/a/Gyqm6OL

Usage: you instance and combine (union/intersection/subtraction) as many copies of the EditableCSG scene as you need, in your main scene, inside a CSGContainer.

However there are currently 2 roadblocks to doing something like this:

1. Selecting children of an instanced scene, in 3d view, is very flaky and doesn't work well. So it's hard to control the widgets.

2. The CSG implementation is currently rough so the results are a bit off when combining shapes...

If these barriers are fixed, this can be made much more flexible by using a SurfaceTool generated cube mesh as a basis, and "binding" its vertices to custom widgets (which are just spatials). This feels quite easy to make, honestly.