Sauerbraten Terrain Editing

by Gilt on 04/13/2006 05:24, 30 messages, last message: 05/13/2006 20:18, 9754 views, last view: 05/18/2024 08:15

Do you think we need more tools for this? What are your thoughts on how this should work? etc etc discuss

   Board Index   

#5: Re: smaller gridsize?

by Gilt on 04/13/2006 17:42, refers to #1

no, a smaller gridsize won't happen. technically speaking, we don't even really need the smallest gridsize we have now... though we are going to keep it.

personally, when mapping, I really would like to encourage people to think somewhat more along the lines of say world of warcraft, then a new unreal engine game. sauerbraten is somewhere in between the two I suppose.

reply to this message

#6: Re: ..

by Gilt on 04/13/2006 17:54, refers to #2

special heightmaps won't happen either. However, the engine is not that far away from being able to kind of faking heightmaps.

Has anybody played around with the editheight command? default key is H. There should also be a newer experimental version of it in the latest CVS source at least. The best way to go about testing it would be in a newmap. make sure to use a medium sized gridsize. The old version will allow you to push into a cube, much like regular I'm suediting, but the newer version will also allow you to seemingly pull up verts from a flat surface.

There are some issues with that though. First, it still uses regular cubes. This means that it's going to feel like it's 'layered'. This is especially true if you try to make steep slopes. Gradual slopes work quite a bit better, and while the mapper will still feel the layers, if done well the player will never really be able to tell where they are.

Another issue, is that it doesn't work very well when you try to mix terrain of different gridsizes. However, I don't think that that is incredibly important. But you can tell me otherwise.

It is also rather fine grained.

Anyway, editheight along with just regular editing and selections, are some of the tools for terrain editing, along with a few issues. Of course, not all issues need to be, or should be fixed... but you tell me, is this enough? are you happy with the stuff we have now? should we add more? For example, the Cube-level importing code has some tricks to deal with heightmaps and the layering issue... though there are going to be a few new issues with that as well.

Maybe we could start with how you'd all ideally go about sculpting terrain, and work from there? Do you even want tools which are not as fine grained?

reply to this message

#7: Re: ..

by CC_machine4 on 04/13/2006 18:03, refers to #2

for both posts #1 and #2:

hold Q, look at a corner of the selected cube and it is very similiar to a heightfield..

you can also use it to make really small cubes (push in all 4 corners on 2 sides)

reply to this message

#8: questions

by Gilt on 04/13/2006 18:34

just in case it got lost in that larger post, what I'm interested in is how you would like to create terrain.

what kind of grainularity are you looking for? do you like editing a few verts at a time, or are you looking for somthing at a larger scale?

for the sake of discussion, if we did have something resmbling a heightmap, how would you want to interact with it? do you want to be able to pullup hills and stuff? do you want to control the size/shape of those hills? how would that work?

how about caves and underground stuff? rocks? how would you like to create that stuff, or make it easier? if we did have a heightmap-thing it probably would not be limited to just horizontal ground. would that matter?

reply to this message

#9: Hmm

by Pxtl on 04/13/2006 18:37

Really, I don't think Sauer is meant for that kind of stuff as much as Cube (or a pure-landscape engine like Spring) is. The short answer of "how do I do a landscape in Sauer" is "don't". Decent heightfields will involve making a tonne of unused volumes.

I've been thinking to myself that a possibly better way to generalize Cube might've been to simply go with a "pure" octree (instead of the irregular/pushable octree) and then allow converting any single cube within the tree into a heighfield, with resolution of the user's choice and facing any of the 6 directions. Simple angled cubes would have to be implemented with the lowest-resolution (single-rect) heightfields. Of course, it would be much more limited, as angled-corners would be impossible in such an engine - and the discontinuity between the cubes and heighfields would be a nuisance, but it would likely be easier to optimize/cull, smoothe, and conceptually simpler for users to understand.

Still, I'm just talking out of my ass.

reply to this message

#10: Re: questions

by Gilt on 04/13/2006 19:12, refers to #8

for example, I'm actually quite happy with what we have already. I whipped up in about a minute or two, a little bit of terrain using just the editheight command (key H). It probably took me longer to badly light and compile this map, then to make it.

http://img134.imageshack.us/my.php?image=terraina5bt.jpg
http://img143.imageshack.us/my.php?image=terrainb1on.jpg

but if you're not happy and want something easier or more powerful, this is the time to speak out :)

reply to this message

#11: Re: questions

by Aardappel_ on 04/13/2006 19:38, refers to #10

I guess if noone wants anything specifically, we'll leave it as is :)

One trick to make steeper terrain is to create it in cube and then import it :)

reply to this message

#12: Re: questions

by dbox__ on 04/13/2006 20:52, refers to #10

I noticed the editheight command in the Sauerbraten documentation a while back and tried to experiment with it using the latest Sauerbraten release but it didn't seem to do anything.

Is this currently only available if I build sauer from the tip in CVS?

reply to this message

#13: hmm...

by metlslime on 04/13/2006 21:09

I haven't done any huge outdoor levels, but from what I have done, the problems are:

1. difficulty doing steep slopes in terrain (there is a trick to doing it with layers, and I did this sucessfully in metl3, but there are limits to when it can look good.)

2. hard lighting edges between quads. This quickly kills any illusion of the terrain being a natural thing. I would like to see this fixed by specifying in the config file that certain texture slots be "smooth lit" which would mean that the lightmaps are fixed to remove seams between two neighbors if they both have the same texture slot (and it's flagged to be smooth.) This could mean putting the quads together on the actual lightmap, or could mean adjusting edge pixels until they both match. Arghrad for q2 had some code to do something like this.

From an editing standpoint, the basic H + wheel seems to work pretty well (other than the steep slope problem.)

reply to this message

#14: ..

by makkE on 04/13/2006 21:11

Yes, imho the problem is the lightning.
Has to be smooth on terrain. Imho it pretty much ruins any terrain atm.

reply to this message

#15: Re: questions

by nieb on 04/14/2006 00:47, refers to #10

Random terrain generation, and resizeable brushes for raise, lower, and level could be useful.

If its not to much trouble ;)

reply to this message

#16: Re: hmm...

by Aardappel_ on 04/14/2006 01:07, refers to #13

the smooth lighting is a seperate problem, and we are actually working on that right now.

The question is more about if there would be better ways to do landscape editing, within the constraints of sauer's geometry representation.

reply to this message

#17: Re: hmm...

by shadow,516 on 04/14/2006 01:51, refers to #16

Random terrain generation, RGB bitmap to sauer conversion and viceversa (R=X, G=Y, B=Z), makehill command. Not sure how feasible any of this is, but I'm sure someone would use it.

reply to this message

#18: ..

by Mad Merv on 04/14/2006 03:34

it would be nice to import 2d heightmaps, is this implemented?

reply to this message

#19: Re: smaller gridsize?

by Sparr on 04/14/2006 05:45, refers to #5

smaller gridsize "cant" happen, due to some pretty slick coding in the depths of rht world model system. anything smaller and you get division by zero errors in parts of the code that would be difficult to change.

reply to this message

#20: ..

by Mad Merv on 04/15/2006 01:53

you can change the way mapmodels move in the world, and then scale upwards. see spamassassins screenshots for an example. it is possible, I think fairly simply, by changing the parameters of the player and essentially scaling the non-level geometry

it was a design choice Aard made for the vision he had for Sauer, it is obviously for a computer built roughly 2-3 years ago, and not for contemporary hardware

reply to this message

#21: Re: ..

by kurtis84 on 04/22/2006 04:40, refers to #20

I think with the H key feature, and the Q key, and the F key, a mapper should do just fine for terrain. I actually just started using the H key, and I wish I had done so much earlier...I could have built the terrain in k_rpg1 much faster...yes I used the Q key method on the whole thing.

Gilt: what you have done already works great...if you can get a cool idea to add something else, thats fine, but I do not see a reason to complain the way it is now :)

reply to this message

#22: mwahahaha!!

by Gilt on 05/08/2006 03:24

http://img66.imageshack.us/my.php?image=holes1mk.jpg
http://img480.imageshack.us/my.php?image=rock0nf.jpg

guess how long these took me to make!

reply to this message

#23: Re: mwahahaha!!

by Passa on 05/08/2006 04:08, refers to #22

several hours? ;-)

reply to this message

#24: Re: mwahahaha!!

by kurtis84 on 05/08/2006 04:34, refers to #23

Ok, you have my interest :)

reply to this message

   Board Index