Sauerbraten Maps

by shahar2k on 05/09/2004 04:31, 57 messages, last message: 01/03/2005 18:58, 17724 views, last view: 05/18/2024 12:32

well I think the current release is good enough to start really working on maps with...
I made this weird experimental map here wich has a few cool Ideas

http://home.earthlink.net/~shahar/ruins.ogz

it also contains a few errors, and shows off the scale that sauerbraten can work in (from smallest to largest)
really neat stuff this engine

   Board Index   

#1: wow

by Aardappel on 05/09/2004 20:05

scary. I knew sauerbraten would give people creative freedom, I am now getting more curious what the future will bring :)

reply to this message

#2: Re: wow

by jcdpc on 05/09/2004 20:49, refers to #1

after seeing that and playing spentrons MM, I'm scared of what spentron might think up...

reply to this message

#3: Cool

by pushplay on 05/09/2004 21:07

I like the abstract direction I think Sauer maps are going to take.

reply to this message

#4: newmap (kinda)

by nieb on 05/12/2004 10:58

http://www.geocities.com/nieb8504/Sauer.html

a map i just started on its going to be a town on a river.

and a question
how do you change the textures?

reply to this message

#5: ..

by nieb on 05/12/2004 11:00

and that ruins map was pretty interesting...

some good ideas going on there

reply to this message

#6: ..

by >driAn<. on 05/12/2004 11:39

R+MouseWheel

or something like that

reply to this message

#7: ..

by shahar2k on 05/12/2004 12:01

actually textures are changed with T+mousewheel


here's another map "test" thing, more polished, but still a headache to make
http://home.earthlink.net/~shahar/church.ogz


oh and ruins wasnt really a map, I'm just exploring the behaviour and limitation of the engine, and I'm running into some serious problems...
specifically the problem is that the structures that you create will break, OFTEN, unless you are constantly using the same brush size (cube size)

I dont think the problems have to do with anything that can be fixed, it's simply impossible to tesselate exactly down to certain scales...

I think the solution is to simply NOT allow diffrent sized cubes... I know that's the point of the engine, but hear me out. what if instead of having one grid trying to fit all size cubes onto it. You have a general structure which is basically a grid of same sized cubes which can be constructed just like cube, but then placed scaled and rotated around the world wherever you chose. that way you could create diagonals, and other structures and still have the editing methods cube had...

Aard, any comments? I think that if you stick with this octree-cube structure you're going to find that it breaks more often than not... I spent a lot of time fixing cube errors, much more than I do creating architecture, if you can fix it then more power to you, but I dont see how... then again you are the programmer :)

reply to this message

#8: ..

by nieb on 05/12/2004 12:45

T brings up the talk consle and r does nothing...hmm...o well

reply to this message

#9: --

by Gilt on 05/12/2004 16:22

shahar2k:

yup, the mipping is definitely a problem. I thought I could get away with, but your right, it's just plain not good enough. I'm working on a better solution right now.


nieb:

you probably downloaded the older version. try the new one.

reply to this message

#10: Re: ..

by Aardappel on 05/12/2004 18:09, refers to #7

having a regular grid is definitely not an option, that would ruin all the scale, and in fact would require smaller maps than even cube.

You will never have "diagonals"... this completely goes against the way the geometry is stored.

I'm sorry, but the world format is pretty much set for sauerbraten.. it is the central point of its design. So please help out Gilt and maybe make a small test map that shows all the things that go wrong you have come across.

reply to this message

#11: also

by Aardappel on 05/12/2004 18:21

these test maps remind me "lighting" has gotta be high on the wishlist :P

reply to this message

#12: hmmm

by Gilt on 05/13/2004 03:41

shahar2k >> specifically the problem is that the structures that you create will break, OFTEN, unless you are constantly using the same brush size (cube size)

I was just playing around with the new build and realized something -- subdivision literally occurs wherever you look! This shouldn't happen, and is a result of me taking a not-well-thought-out short cut.

Sorry about that, I've already fixed it. Just remember, you're mapping on the bleeding edge :)

reply to this message

#13: Re: hmmm

by Aardappel on 05/13/2004 05:25, refers to #12

doh!
Ah well. Gilt are you working on linux or windows? if the latter you can make your own releases once you accumulate some new features... if not let me know.

reply to this message

#14: ..

by shahar2k on 05/13/2004 11:42

yah but in addition to that subdevision occurs on cubes adjacent to the ones being subdivided... plus it's impossible for some subdevisions to occurs smoothly, here, I've provided a 2D example of the erros created when tesselating edge spans cubes down...

http://home.earthlink.net/~shahar/edge-span-error.gif
basically the blue lines are the original edge spans and the black shape is the original shape created (using the entire image as the "cube"

When attempting to tesselate down 3 levels, (the smaller grid) the squares colored red, are the ones which will certainly cause errors because they are illegal shapes (an edge span can only have lines going from one edge to the other paralel edge)

and the orange squares will also be distorted but not much, and usually those are the errors that can be fixed by a better tesselating algorithm...

anyways, the red ones are impossible to fix, unles you change the entire system

this system is great for memory management I'm sure (storing so few varibles per cube) but kills when it comes to changing scales. still I'm sure I could make levels around this limitation with a lot of planning. but I would have to seriously consider any scale change before I make it

reply to this message

#15: e

by Gilt on 05/15/2004 04:44

aard> releases:

for now it's better if you did the releases. To be honest, I'm not all that familiar with gcc/mingw -- for instance I can't even get the asm to work... so my builds are all hacked up. maybe I'll dig through the documentation and figure out what's what later..

sha> subdivision on adjacent cubes:

basically, right now you have to tell the game to update the map whenever you make a change in the world structure. However, since I wasn't expecting the map to change by simple moving the cursor around, it wouldn't update until another cube was edited. This is why I didn't notice the problem right away, and why adjacent cubes appear to be affected-- you must of hovered over them before hand.


changing scales:

imo, you're blowing that out of proportion (heh). When I was making maps for quake, I don't remember ever changing scales all that much. I mean if I wanted to make a room 1.3x larger, I wouldn't just select the entire room and stretch it, but rather fix everything by hand. Even though I could do it easily with that engine, stretching a room like that would mess up my brushes -- they would no longer be mapped to the grid, which would be a pain in the ass to deal with in the long run.

As you spend more time with the engine, you'll probably develop a better intuition as to what scale makes things look and play well, so that you won't have to change it as much.

reply to this message

#16: ..

by shahar2k on 05/15/2004 07:04

yah that's true about adapting eventually, but the diffrence between Cube and Sauer, is that in cube you always edited on the most detailed level but could select multiple parts... and then the engine interpolated where it could combine parts...

In Sauer on the other hand, making a large room out of small cubes is a pain, but then once you make it out of large cubes and then move to smaller cubes, the room twists and distorts because of the problems I mentioned.

now you're right it is possible to adapt to editing, but I think that the idea behind cube is for it to be an engine optimised for easy editing... and I think there are easier ways to edit than this...

then again, it's a programmer's call, I'm just stating my oppinion,

reply to this message

#17: Re: ..

by jcdpc on 05/15/2004 13:51, refers to #16

could sauer have an editing system like cube on top of what it has now?

reply to this message

#18: ..

by e:n:i:g:m:a on 05/15/2004 16:04

What sauer needs is a set of fill commands, such as fill the square size on the current selection, or fill the current selection plane inside a room, etc.

reply to this message

#19: ..

by _Fanatic on 05/15/2004 16:15

I'm not sure what I'm doing wrong, but editing in the beta of Sauerbraten seems impossible.

I can't seem to make a structure at all, or consistently control what's happening. I updated the cfg for editing commands, and I'm using the mouse wheel and keyboard commands, but I can't seem to make squat with it.

And I really have no idea how to create extra cubes to make 3d structures, other than to push a hole into an existing spot on the test map. How do you create a new empty level too?

Has anyone else had such difficulty?

reply to this message

#20: ..

by driAn@otherMachine on 05/15/2004 16:32

me too

reply to this message

   Board Index