home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


The missing building pieces

by IllvilJa on 03/27/2008 08:07, 34 messages, last message: 04/01/2008 00:25, 6706 views, last view: 05/18/2024 21:19

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.

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages

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

by IllvilJa on 03/29/2008 01:04

(Thanks for the advice Tentus, I'll try that when appropriate).

When deforming the corners of a cube, we can deform it in such a way that all four corners lie in the same plane and thus, the new side of the cube is one single plane. It gets subdivided into two triangles (which can be seen when enabling 'outline' by hitting the key '7' in edit mode) and even if it can be subdivided into triangles in two different ways, it does not really matter which way is chosen by the Sauerbraten engine.

However, when deforming a cube side in such a fashion that the four corners are NOT part of the same plane, then the choice between the two ways of subdividing it into triangles WILL matter. If one looks at the "division line" separating the two triangles the face is subdivided into, the two options of where to put that line will result in it being either a bit higher up (a hip) or a bit lower down (a valley).

The 'hip' subdivision will retain more of the cube's volume than the 'valley' subdivision' as the latter "digs deeper" into the cube's surface.

A picture would help here, and luckily our trustworthy friend Wikipedia has an EXCELLENT image of a house roof which serves as a good illustration of this concept as well as it shows the original situation (creating a roof with valleys) where I ran into problems because I were missing some building blocks.

Ok, here is the picture: http://upload.wikimedia.org/wikipedia/en/a/aa/Rf-iso1.gif

(It is taken from the article http://en.wikipedia.org/wiki/Hip_Roof BTW).

In this picture, we see an illustration of a roof. There are so called 'hips' (denoted with the letter 'h') and there are so called 'valleys' (denoted with 'v'). On my emerging attempts to create a wargame, I do of course like to have roofed houses on he battlefield, and when creating a house like the illustrated one, it's dead easy to create cubes with 'hips' so I can create the hip ends of the house without any problems. However, when I try to create anything like a valley, the cubes refuse to become the 'valley' cubes I need, they just become 'hip' cubes. Subdividing does not help, I get a valley cluttered with a stair of hip cubes. (And actually there is no way to tell the cube if it should be 'hip' or 'valley').

And, in a nutshell, that is what I'm missing, the ability to strictly control when these cubes with non planar deformations becomes 'hip' cubes and when they become 'valley' cubes. From a user interface perspective, this change is fairly easy to implement. Just let some key toggle a face between being either 'hip' or 'valley'.

I had a look into the source, but did not have time to find a definitive answer on how easy this feature would be to implement. I got the impression at least, both from source as well as from working with the editor, that all non-planar cubes consistently end up as 'hip' cubes. If this indeed IS the case, adding 'valley' cubes becomes easier, as we then only need to keep track of two different states for each cube face. Where to store that bit of information is of course a good question. If we are fortunate, we might find some unused bit in the already used data structures, some bit which today always is set to zero or one. That bit can then be used to tell if the cube side is 'hip' or 'valley'. For backward compatability, we do of course let the 'usual' value (used today by sauerbraten) of that bit to denote a 'hip' face whilst the other value then denotes 'valley' face.

If the current state of affairs is that we really cannot count on all these non-planar faces to be 'hip', then we need to find two unused bits which we can use to store the state for each side, be it 'hip', 'valley' or 'dontcare' (the latter being the state used today, given the assumption starting this paragraph).

In any case, we need to ensure that Line of sight code, physics code, rendering code, remipping code etc takes the 'hip' or 'valley' state of the cubes into consideration.

Your thoughts on THIS addition to the editing? It would be quite nice to be able to create 'valleyed' roofs as well, in addition to usual gabled roofs and hip roof.

Or is it just me who has misunderstood the editor and have not figured out how to switch between 'hip' and 'valley' cube faces? That possibility is definitively not ruled out either!

reply to this message

#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

Go to first 20 messagesGo to previous 20 messages    Board Index    Go to next 20 messagesGo to last 20 messages


Unvalidated accounts can only reply to the 'Permanent Threads' section!


content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
54039485 visitors requested 71820237 pages
page created in 0.019 seconds using 9 queries
hosted by Boost Digital