travisvroman
commented
9 months ago Thanks for submitting this! CSG is on the roadmap, but there are interesting ideas in here, so I'll hang onto this ticket. I appreciate it!
Open CortexReaver opened 9 months ago
travisvroman
commented
9 months ago Thanks for submitting this! CSG is on the roadmap, but there are interesting ideas in here, so I'll hang onto this ticket. I appreciate it!
I wonder how you open minded about level creation tools. There are a lot of cool engines out there, but they are using 3d meshes or rather an outdated BSP tree method of storing data. 3d geometry made in 3ds max or blender is cool and opens you a lot of possibilities, but also requires level designers to learn new tools. I remember times, where some person was able to create a map without any knowledge about 3d graphics packages, meaning that there were a lot of custom made levels just by regular people, not especially artists. And it seems like a "level-designer" specialty pretty much gone these days, because there is no level editing software left. I thought since you are aiming to make an engine for creating somewhat resembling retro games, I think this will be really nice for old-school level designers (the leftovers of them) to play with.
https://www.youtube.com/watch?v=FNFZL9yF7DY - this is video footage of a standalone level creation program, which is a part of Unity/Unreal plugin called Voxel Farm. It has a word "voxel" in its name, but as I understood correctly it is more close to a marching cubes (MC) algorithm underneath the hood. To me this looks like a perfect level editor, because it combines best of both worlds: you can "mockup" your level with a bunch of primitives and then gradually sculpt it to something more detailed without the worries of 3d modelling specifics, like cutting interconnected geometry and then cleaning "polygon leftovers" with merging vertices altogether. Neither of any of stupid BSP tree issues, like leaks and overall slowness of this method, because in the MC case whole level will be combined just into a regular 3d mesh at the end. https://www.youtube.com/watch?v=XJrxcz2cO6E - Cube 2: Sauerbraten also has a pretty unique realtime level editing mode, since it doesn't have any separate level creation tool. Not sure if it uses MC though, might be some sort of an octree algorithm.
https://www.youtube.com/watch?v=egm9QdKdQtM - and there is another cool editor, a unity plugin called "Realtime CSG". This one is more close to a classical Unreal 1-2 editors. It uses "constructive solid geometry", which consists of a hierarchy of objects with subtractive or additive properties. This is more close to a "boolean" function in 3ds max, but more dynamic (you can move your "holes" around solid objects, like at 2:33 on the provided video). First unreal engines had a very clunky implementation of CSG, wasn't very dynamic at all, meaning you needed to recompile a bsp tree every time you moved some geometry primitive, but it was still a great advantage over quake-like editors where you have to draw every wall by hand.
So, what I am proposing is something like a CSG hierarchy of primitives, but each of them can be "sculpted" with marching cubes. Like you made a one big box for a building facade, and then made a "subtractive" room or a corridor inside it. Then you, for example, select a corridor in a "detailing mode" and start working on it, without creating any new elements in the hierarchy. Like if marching cubes were local to every CSG-tree element. Don't if it is even possible or if anyone did ever something like what I've described. Or another approach: marching cubes are global for an entire level, but you also have a CSG hierarchy on top of that. Like you have a BSP under CSG in Unreal 1, with geometric primitives acting as an active frame, that you can move in three dimensions. So you'll have "subtractive" and "additive" frames visible only in the level editor that you can combine by just placing them close enough with each other, guiding the cutting or merging process of the "global voxel mass". But this way the levels will be twice as big, because it needs to store all the frame data besides level geometry itself (same goes for octree if I am not mistaken, like it stores the simplified mesh and the detailed one).
Mind you this is all static (in-game) geometry, it does not have any physics properties or rather destructibility. Marching cubes are a bad choice for real time destruction. But I think (in-game physics) deformation is fine for a particular mesh element of a level geometry. Like you can have a subtractive cave (all normals are inside-out) with something like a "deformation" flag, allowing you just to deform the polygonal mesh of the cave itself and not changing actual vertices and polygons... until it collides with some other geometry. But for solid "additives" it should be much simpler.