The missing building pieces

by IllvilJa on 03/27/2008 08:07, 34 messages, last message: 04/01/2008 00:25, 6690 views, last view: 05/05/2024 13:09

Hello!

The intent with this thread is to discuss what "building blocks" you find missing when you create maps.

Creating maps in Sauerbraten is a bit like building with Lego in those days when you were a kid. You dig around in that pile of building pieces of yours until you find something that suits what you are constructing or, perhaps even more fun, you run across that piece that you first was not looking for but which immediately sparks new ideas of how to proceed with your little building project.

But sometimes, when building in Lego as well in Sauerbraten, no matter how much you dig in the pile of pieces, you don't find THAT critical piece you need for the moment. The solution is to rethink what you build or scrap it altogether. Or in the case of Sauerbraten, perhaps to identify EXACTLY what the missing piece is and look into what value it would provide for mappers and what cost it would impose on the Sauerbraten project (or a mod thereof).

Please note, this is a thread for discussions of new features to the mapmakers, features that basically are hypothetical and which not necessarely ever will be implemented.

Dear Sauerbraten users: if you like some suggestion, feel free to say so but do not DEMAND that it get's implemented into the official Sauerbraten releases, not even you are capable to code it yourself. ANY demands expressed will effectively KILL this thread, ok? (and I don't want it to die...)

Dear Sauerbraten and forum maintainers: even if this discussion never result in a single line of executable code, please let the discussion continue. I for one really enjoy trading ideas and discussing various software features, spatial geometrics, data structures, project management etc... If it then actually results in usable features, the better.

   Board Index   

#15: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by SheeEttin on 03/29/2008 02:55, refers to #14

Don't think it's currently possible.
I've been playing around for quite a while trying to get something like that to occur (and, for the map I'm working on right now, it's in a roof, strangely enough).

I guess the way to implement this would be to decide, somehow, which direction to "cut" along when deforming opposite corners.
(For a visual, take square ABCD (a face of a cube), vertices labeled clockwise. Press corners A and C in halfway. Sauer would make the ridge along BD. Instead, what if the "cut" were along AC, such that the cube formed a valley? This is what is being suggested.)

reply to this message

#16: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by tentus_ on 03/29/2008 03:27, refers to #14

I'm gonna go a bit nuts with the ASCII art so I can visualize what you're saying: if I'm understanding correctly then I agree with what you're asking for, I've wanted it a few times myself.

Corners 1, 2, and 3 are lowered, resulting in a hip:
10002
0X000
00X00
000X0
30004

Corners 1, 2, and 3 are lowered, resulting in a valley:
10002
000X0
00X00
0X000
30004

Viewed from the side and diagonally, so that 3 and 3 are centered and 1 and 4 are on the far ends:
Hip:
------4 (I hope the - are the same width)
----X00
---X000
--X0000
1003000

Valley:
------4
-----X0
----X00
---X000
1--3000

So, now that my little monstrosities are out of the way, let's consider what other applications the same data could be used for. It's quite possible that giving the ability to dictate hip/valley to the mapper could result in unforeseen slowdown and complication, but it could also open up some possibilities that haven't been mentioned yet. Specifically, I'm thinking about cave modeling... a little while ago there was a nice discussion on layered geometry in order to create concave surfaces, like that of a complex cave. The general problem was that you would have to build your cave from a square, keeping the corners more or less intact, otherwise you ended up with funny, inorganic angles. Several artists found this very limiting.

If we could tell the engine hip/valley, that same data could be used to tell the engine how to put together caves. We wouldn't have to subdivide everything so much to break away from the grid, we could instead just tell it to make the ridge to go the other way. Example:

Corners 1 and 4 are lowered, resulting in a hip:
10002
0X000
00X00
000X0
30004

Corners 1 and 4 are lowered, resulting in a valley:
10002
000X0
00X00
0X000
30004

Viewed from the side and diagonally, so that 3 and 3 are centered and 1 and 4 are on the far ends:
Hip:
1000004
-X000X-
--X0X--
---X---
---3---

Valley:
1-----4
0X---X0
00X-X00
000X000
0003000

reply to this message

#17: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by demosthenes on 03/29/2008 09:38, refers to #16

Gah!

Those last two (pairs of views) make no sense! Corners 1 and 4 are lowered, resulting in a hip (which looks like a mountain fold), but your line of Xs runs from 1 to 4... which are the low points!

And the second one is the opposite, with the same problem!

Your first two (pairs of views) make sense, though.

reply to this message

#18: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by tentus_ on 03/29/2008 14:23, refers to #17

Whoops, I flipped my little diagrams. 1 and 4 are supposed to be on the bottom row. Just... pretend that my stuff got flipped because we're looking at the ceiling a cave now. (There's actually a good chance that's what I was thinking, I am more easily turned about when it's 2 am)

Basically, it works like this. Depending on your orientation, having points 1 and 4 up and 2 and 3 down will have these results:
(First diagram)
The division line runs from 1 to 4, resulting in triangles 124 and 134. This results in a little ramp shape I tried to express.
(Second diagram)
The division line runs from 2 to 3, resulting in triangles 123 and 234. This results in a little valley.

Next time I try this I'll just put a bunch of diagrams on my website.

reply to this message

#19: ..

by ezombie on 03/29/2008 20:44

So like a 'in/out' toggle? Basically you are changing the behavior from concave to convex deformation of the cube.

That would sure be handy. But I noticed that ALL possible cubes that can be currently created are fully convex. Perhaps there is an engine reason (some optimization, etc) that concave cubes are not available?

reply to this message

#20: Re: ..

by demosthenes on 03/29/2008 23:13, refers to #19

Aren't convex polygons "easier"?

No, I'm not *quite* sure what I mean by that, but it makes some sense to me. Just can't quite piece together why.

reply to this message

#21: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by KillHour_ on 03/30/2008 00:24, refers to #14

This was originally a problem with ATI cards, as they would always render concave, while nVidia cards rendered convex. To fix the problem, it is hard coded to always produce convex cubes.

In addition, any vertex positions that require a concave cube to be possible are blocked by the engine as illegal cubes (which is why you can only push a corner in a few times in each direction). There IS a command to disable this, but it leads to bugs with lighting and physics.

As eihrul says, every time you make an illegal cube, a kitten is trapped inside.

reply to this message

#22: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by SheeEttin on 03/30/2008 04:55, refers to #21

Aww. Poor kittens.

I wonder, would it be possible to make a cube "inverted", i.e. flip the positive and negative spaces? This'd certainly get the desired effect...

reply to this message

#23: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by MeatROme on 03/30/2008 04:56, refers to #21

Well ... Schrödinger needs to get his cats from somewhere ... doesn't he?!? ;)

reply to this message

#24: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by MeatROme on 03/30/2008 05:03, refers to #22

Errhm .. maybe I didn't get some of the ASCII-Art above ... but aren't you basically asking for "X" (flip) !? ..
the way I see it you can either match your desired geometry to the grid or in dire straits even fake it with mapmodels ... now that the smallest gridsize is so much smaller than it used to be I really don't see anything you can't achieve /acceptably well/ with the octree ... sure, it might not be always just what the graphics-designer dreams of .. but it's the best combination of non-graphics-guy-usable editor and game-engine-friendly data-set all accessible through the wonderously enjoyable sauerbraten editor.
Or did I miss something ??!?? ... like I said ... maybe I skimmed the ASCII-art too quickly :-P

reply to this message

#25: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by SheeEttin on 03/30/2008 05:16, refers to #24

Nah, I probably just explained it poorly.

If you hit X, it basically takes the selected and opposite faces and swaps them (and/or their deformations). What I'm imagining is taking a deformed cube and actually inverting the spaces--take the "ridge" cube I explained a little while back. If you used this "invert", what it'd do is turn the ridge into a valley.
Imagine said "ridge" cube made of wood. One could make another piece of wood that would fit on top of it and make a perfect cube. The "invert" would swap which piece of wood (cube) you have--but unlike X, it wouldn't do any transformations/reflections/whatever.

reply to this message

#26: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by a`baby`rabbit on 03/30/2008 08:56, refers to #25

Think outside of the box (sic), if you rotate your house 45 degrees then ridges and valleys become a piece of cake....

reply to this message

#27: Re: Missing building pieces part 2: The Hip-Valley Cubes!

by tentus_ on 03/30/2008 15:06, refers to #26

Not so much... and any benefit would be destroyed by mapping at those angles, because then getting doors, windows, and everything else becomes much harder. While it's a good idea, it won't solve the problem.

reply to this message

#28: ..

by IllvilJa on 03/30/2008 15:08

(In response specificly to #26, will respond to other posts later on)

...even if a few other things become a bit problematic.

But as a temporary workaround that probably is the way to go. For a more long term solution (and for a host of other mapping situations), the ability to toggle valley/hip for non-planar cube sides would still be the best way to fix it.

reply to this message

#29: Re: ..

by KillHour_ on 03/30/2008 18:42, refers to #28

Again, this leads to bugs in the engine. Sauer can NOT handle concave cubes.

reply to this message

#30: Re: ..

by IllvilJa on 03/30/2008 19:09, refers to #29

But then why expect I would not fix those bugs?

As part of adding concave cubes into the engine it is of course required that any such bugs you refer to are addressed, that is, all aspects of the rendering code, physics code, remip cod etc that are affected by the addition of concave cubes should be reviewed and if necessary modified to ensure that the engine coninues to work properly.

If we added concave cubes to sauerbraten and did not fix anything that got broken by that addition and claimed that we had finished the job, we would just be incompetent idiots from a software development perspective.

Either we add code that adds concave cubes AND code that fixes anything that the concave cubes presence happen to break, or we add NOTHING. The suggestion is of course to do one of those two choices and nothing else.

Sorry for being a bit harsh but I get a bit frustrated when someone seem to think that I expect it to be ok to only implement a feature halfway.

BTW, I got some more ideas regarding building pieces for maps today. I'll post those later today or tomorrow.

reply to this message

#31: Re: ..

by ezombie on 03/30/2008 20:25, refers to #20

'Aren't convex polygons "easier"?'

In a convex primitive the normals (an imaginary line cast at right angles to the surface) do not intersect. Ever. Normals are used for many things in 3D engines.

Having the normals intersect starts a chain reaction that makes lighting and other such luxuries much *much* harder.

Most games will not let you map with concave brushes (aka primitive shapes or cubes). Even modern iDtech games (Doom3 & Quake4) share this limitation.

It basically opens up another whole level of math that needs to be addressed, IIRC from college.

reply to this message

#32: Command

by dshjfconorfhdsjk on 03/30/2008 23:23

What is the command?>

reply to this message

#33: Re: ..

by yetanotherdemosthenescomputer on 03/31/2008 01:03, refers to #31

There we go! Yes, the normals for a convex wouldn't intersect.

reply to this message

#34: ..

by IllvilJa on 04/01/2008 00:25

Regarding introducing concave cubes in Sauerbraten: the word 'primitive' does not have to mean the same thing for the map designer as it does for the internals of the sauerbraten engine. The maps may contain concave cubes as part of their 'primitives' whilst the sauerbraten engine, upon loading the map, silently splits any concave cubes into smaller convex objects. The engine then applies physics, lighting, mipmapping etc on those 'partial cubes' without having to worry about anything about concave objects.

If this works? Well, try this: exctract a cube i the Sauerbraten editor, then select half the gridsize and then excavacate away one of the corners of that larger cube. The result is a concave structure within the cube, a structure which has proper rendering, physics and lighting. The latter is possible as the larger sructure were subdivided into smaller structures. So I just applies the same reasoning on concave cube 'primitives' ('primitive' as seen by the map-desinger and the code reading/writing maps from/to file) to let them be split into smaller fragment 'primitives' inside the Sauerbraten Engine.

Of course, the Sauerbraten code as of today does not know anything about these 'partial cubes', so the code managing the physics, lighing, remipping etc for those partial cubes must be developed, which will be an effort on it's own. Regarding hip/valley status for non-planar cube faces, when a cube has a non planar face which is selected to be a valley, then the bottom edge of that valley MUST be such an edge along which the cube is split. If several valleys exist on a cube, and they may (or may not depending on their location and topological orientation) require the cube to be split into more than two pieces.


So... The final 3-dimensiosal building piece I've been missing when mapping, and a piece I've understood that others would like to have as well is the ability to create concave structures that are NOT attached to any cube corners/edges in the Sauerbraten Octree. I were first considering to use the current cubes (being defined by 6 deformable faces): look at the space in the octree volume being divided by 6 deformable faces, we have one volume in the middle (the usual cube) but these 6 faces do actually split the bigger cube into several subvolumes. If you think of Rubik's cube and it's invisible middle cube being surrounded by 26 other cubes and then imagine that the 6 planes that sliced and diced the Rubik's cube into it's 27 smaller cubes actually can be deformed you get an idea of the structure I had in mind. My thought were that the map designer should be able to select parts of that "deformed Rubik's cube" that were solid and parts that were empty. Of course, hip/valley option should apply for all the 6 heightfield faces and all the heightfield faces could be partially placed outside the cube (as described for the 'clipped cubes').

This turned out to be a pretty powerful mapping primitive (one could create a roof, a floor and a pillar all in one single cube!) but it also will be very complex to handle in programming code, not to mention the editor end user interface or how to fit it into the exising in memory or on disk data structures (returning to the headache of breaking backwards compaability and increasing the size of data structures). So I decided to give up this concept in favor of what I call the "deformoct".

I played around in my mind with the thought of using not 6 heightfield faces for a cube but instead just use 3 faces and not let those faces be heightfields but instead just deformable dividers (one in the XY plane, one in XZ plane and one in the YZ plane) which could be deformed in the same way as the heightfield faces as of today (even if these faces were permitted to be moved into 'clipped' corner ranges of 9 to 16 or -8 to -1). That way the cube were divided into 8 subcubes, subcubes that can be deformed by deforming the dividing surfaces. In addition to deforming these dividing surfaces (including choosing which directions valleys and hips are going if the dividers are non-planar) the map designer can choose to let each of the 8 individual 'subcubes' be either solid or empty. The designer can let all subcubes except for one be solid, thus forming a hollow corner within the otherwise solid cube. That hollow corner can be extendend quite freely within the solid body, and it can be given walls that are not aligned with any of the coordinates planes and none of the edges or vertices of that hollow corner need to coincide with the octree grid used by Sauerbraten.

This kind of 'deformable cube octet' (deformocts) will of course result in various concave structures so the Sauerbraten engine has to carry out some internal subdivisions of the structure to create convex primitives (and free any trapped kittens ;-) )

As far as I can tell (even if I have not yet had time to carry out an in depth analysis once and for all) is that by using these deformocts together with the usual sauerbraten cubes available today, we can safely subdivide any deformoct or cube into smaller components.(only potential catch seem to be the valley/hip stuff... but I'm not certain that dragon is lurking for us...), and we can also use this structure to design concave structures (like the interial surfaces of a room or a cavern) without needing to align edges and vertices with edges and vertices of the overall octree.

But the really nice thing with these deformocts is that a deformoct geometry can be stored with less bits than the 96 bits used for storing the geometry of the Sauerbraten cubes today:

3 planes, each with 4 cornecs of not 4 but 5 bits each (as we need room to store corner coordinates ranging from -8 to 16) means we need to use 60 bits for the deformable planes. Then add another 3 bits, one per plane, to indicate how any non-planar planes should be subdivided into triangles, that is, in what directoin should there be a hip (and thus, show a valley in the opposite direction). Add to this 8 bits to keep track of the solidness for each of the individual pieces of the deformoct.

Total number of bits are 60 + 3 + 8 = 71! This gives us 25 bits "left over" if we store this in the same space as a "regular" sauerbraten cube. Bits that can be used if we want to further complicate things (which I think we shouldn't, this structure is simple yet powerful enough). What we COULD do is to use a few of these bits to create a "marker pattern" which indicate that this is a deformoct.

Another good thing with this deformoct is that it permits the creation of cubes that are both convex and concave (sort of 'saddle points' from a topological/geometrical perspective).

So with the "regular" sauerbraten cube and this deformoct, I think mappers can get quite a lot of the pieces they might have been missing while creating maps.

Your thoughts on this are of course welcome!

(And then, I got some more isoteric ideas regarding map design and materials in the 3d-structures, not to mention textures etc. but more on that in future posts.)

reply to this message

   Board Index