[feature] [question] Different style of level editing, like CSG and marching cubes.

[CortexReaver]

This is more a question, rather than a full feature request. I want to know if something like on these videos will be possible to implement: https://www.youtube.com/watch?v=egm9QdKdQtM Or maybe even stuff like this:  https://www.youtube.com/watch?v=FNFZL9yF7DY and https://www.youtube.com/watch?v=fIinDxqDYnw Traditional style of creating levels in Half-life is to build them out of convex forms (so called "brushes"), wall by wall. So this process might be very tedious, especially in the process of creating really big city locations, containing a lot of buildings. I remember creating levels in Unreal were much more fun, then in World Craft\Valve Hammer, because it was possible to make rooms with one single "hollow" (subtractive) primitive. For example, I've provided a video of a plugin called Realtime CSG for Unity, which adds CSG hierarchy into a standard unity editor, allowing subtractive primitives that you can move dynamically without cutting already existing boxes into smaller pieces, like Hammer does. Another examples are VoxelFarm and Cube 2 level editors, the second one allows you to edit geometry in game realtime. Although, I don't know if Cube is using marching cubes "under the hood", but they feel similar. VoxelFarm is a standalone editor AFAIK, which does have an Unreal 4 plugin for its own format support (only opening and playing, not editing). And I don't know if you can combine CSG with marching cubes either, like make a CSG subtractive primitive, and then "sculpt" or "shape" it to the form you need, but this would be really cool. Marching cubes have a huge advantage of a cleaner geometry, because shapes are merging in one consistent by request. Also how well these technologies can go along with the original BSP format, to be cut down into little pieces and stored into binary tree? Does this require BSP at all? Pretty sure no engine nowadays uses binary trees for storing geometry anyway, not to mention it can get really slow while you go deeper into the tree. But I might be completely wrong here. CSG is very dependent on hierarchy on the other hand, but such data can be stored in "level editor" format, not the "playable" one.

[SNMetamorph]

It's hard question, but I'll try to explain things. Level creation pipeline already have CSG in it - it's used to correctly split brushes to smaller parts or to merge brush faces together. Unreal also was using BSP, but in it's different implementation (and this is why there is possible to use substractive primitives). And this differences between Quake's BSP and Unreal's BSP are fundamential. This is why it's not possible to have same level creation process like in Unreal 1. Who knows, maybe all of this CSG instruments can be implemented in level editor. So, we just do our things and it's immediately or in final will being converted to regular brushes.

[CortexReaver]

So, "throwing out" all existing level data formats and creating brand new one with a totally new editor is not possible right now? I mean, to me there is not much difference between level geometry and 3d models, besides just bigger size (and modern computers with modern GPUs do not need these optimizations BSP format provides anyway) and physical collisions. I guess collisions are more easy to calculate for a bunch of convex solid primitives as well, rather than for "turned inside" faces of a room. But not mathematically impossible at all, because for example, Unity plugin called "ProBuilder" uses regular 3d mesh that already stops the player from falling down and walls that are blocking him (Dusk and many other modern "retro boomer shooters" developers actively using this plugin: https://www.youtube.com/watch?v=ll7PpGXuHwI). There are also "trigger" primitives that stored in BSP somehow, but to me they are no such big deal if it gets replace with some other methods of detecting NPCs and players (like detection by the radius in most modern editors), so this and maybe some other things are the price I willing to pay to have more comfortable level creation tool. But that's just me, maybe many other media creators got used to all those features, finding them life-saving useful. As for backwards compatibility, BSP format can be read as a polygonal mesh, right? All in all it is just a bunch of interconnected points in space, just stored in a manner of binary hierarchy. GZDoom does exactly this, which allows it to use modern lighting effects as well as PBR, also storing baked lighting in more modern UDMF level format. Moreover, reading levels as a mesh opens the possibility of Vulkan API\DirectX 12 support, which GZDoom already has. Anyway, thanks for the answer, really appreciate it.

[SNMetamorph]

So, "throwing out" all existing level data formats and creating brand new one with a totally new editor is not possible right now?

And it's also useless. Engine will be not like UE4/Unity (because of there is no so much resources to development) and also it'll be not Quake-like too (because we just broke backward-compatibility with already created content and broke existing content creating pipeline)

There are also "trigger" primitives that stored in BSP somehow, but to me they are no such big deal if it gets replace with some other methods of detecting NPCs and players (like detection by the radius in most modern editors)

This is entities and it's not affiliated with BSP in any ways.

GZDoom does exactly this, which allows it to use modern lighting effects as well as PBR, also storing baked lighting in more modern UDMF level format.

Level format is not a limitation for implementing such things as PBR/baked lighting/etc. Moreover, it's already implemented in PrimeXT as backward-compatible BSP level format extensions :)

Moreover, reading levels as a mesh opens the possibility of Vulkan API\DirectX 12 support, which GZDoom already has.

What? o_0 In any graphics API, when you decided to render something - you should represent things that you want to render as set of geometry data. It's common for all graphics APIs, no matter is it OpenGL, GLES, Vulkan, DirectX, Metal. Therefore, nothing limits to implement, for example, DirectX 11/12 renderer for Xash3D. Also, Xash3D already have Vulkan renderer in development (even with ray tracing support)

What about level creating, in theory you'll be able to use regular 3D meshes in PrimeXT for creating level too. But at this time it's not properly debugged yet.

[CortexReaver]

Moreover, reading levels as a mesh opens the possibility of Vulkan API\DirectX 12 support, which GZDoom already has.

What? o_0 In any graphics API, when you decided to render something - you should represent things that you want to render as set of geometry data. It's common for all graphics APIs, no matter is it OpenGL, GLES, Vulkan, DirectX, Metal. Therefore, nothing limits to implement, for example, DirectX 11/12 renderer for Xash3D. Also, Xash3D already have Vulkan renderer in development (even with ray tracing support)

What I mean by that, API's (well GPUs in general to be correct) do not understand BSP, nor CSG or whatever formats, so you have to convert level data into vertices and polygons anyway before sending them, piece by piece (or just small little currently visible pieces), until you got to the bottom of the tree, to the VRAM. This sounds like another layer of extra work to do on top of other complicated things. Vulkan is a modern API built for modern hardware, created around a "working with large chunks of data" concept. And a BSP is a 25+ year old technology for cutting not so big geometry data into even smaller chunks, so it won't choke rendering all by once on slow computers with tiny bandwidths. Sorry, I just completely don't see a need for this in a modern age of 3d graphics :) furthermore, you won't gain any additional performance by using Vulkan on top of obsolete solutions. And to me, statement as this:

because of there is no so much resources to development

Is another great example of "sunk cost fallacy". Maintaining such things only creates an illusion of "easiness". By storing the whole levels in binary polygonal mesh format, you can stream them directly to VRAM, like they do with assets in any other modern games. To me that's a faster and easier solution... But ok, that's a completely different topic.

[SNMetamorph]

What I mean by that, API's (well GPUs in general to be correct) do not understand BSP, nor CSG or whatever formats, so you have to convert level data into vertices and polygons anyway before sending them, piece by piece (or just small little currently visible pieces), until you got to the bottom of the tree, to the VRAM.

It's already done in existing formats. You don't need to do some conversion, all brush models geometry already represented as surfaces which just contains triangles in it. Also, at least in PrimeXT all of the world geometry are being loaded to VRAM once on game start, but rendering only what we should, not everything at once (maybe it'll be even faster, need to be tested)

[SNMetamorph]

Vulkan is a modern API built for modern hardware, created around a "working with large chunks of data" concept. And a BSP is a 25+ year old technology for cutting not so big geometry data into even smaller chunks

It doesn't makes any sense since depends on how you render, not what you render. You can render BSP geometry with small chunks and it'll be slow, in opposite you can also render it with big chunks and it'll be fast.

Is another great example of "sunk cost fallacy". Maintaining such things only creates an illusion of "easiness".

It's just the reality. Most of open source solutions can't conquer with commercial products which are being maintainted by entire teams of professionals and their work is paid.

[CortexReaver]

It's just the reality. Most of open source solutions can't conquer with commercial products which are being maintainted by entire teams of professionals and their work is paid.

Cube 2: Sauerbraten is a free and open source project and it has more comfortable level creation tools rather than Hammer IMHO. Well, at least their method much faster and does not require you to recompile a level every time you make a change... and all the lights are visible during creation process. Although I don't know what space magic it operates on. Maybe it is some form of a modified BSP tree indeed. Maybe it's an octree, idk. Marching cubes are not that complicated either with widely available documentation. Same goes with CSG, a more comfortable tool and there are more ways to implement it than done by Unreal devs in the late 90-s... Anyway, thanks for the answers. I totally got your point.

[SNMetamorph]

Well, at least their method much faster and does not require you to recompile a level every time you make a change... and all the lights are visible during creation process.

It's always tradeoff between quality, performance and interactivity. Did you tried to build something in it? Lighting in such implementations is terrible, light just leaks through walls and you can do nothing to overcome this issue. Lightmapping (most of map compiling time are spent on this) is not a thing that can be changed interactively, but in opposite it has minimal performance tradeoff and good visual quality. It's still used even in Source 2 and UE4.