Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1694356 views, last view: 05/03/2024 01:53

This thread is for discussion of Sauerbraten coding issues / implementation ideas etc.

   Board Index   

#921: ..

by ssdd_darkstar on 06/22/2005 09:18

sorry. just ignore the above post. you're not here to debug other ppl's code. i'll post it when it's done.

reply to this message

#922: maplinking

by Flamie on 06/22/2005 09:33

that kind of maplinking should work great for doors and other "enter before you arrive" kind of moves.

however I'd be much happier if we'd have a maplinking which prebuffers the surrounding areas making it seemless to move in all directions :)

reply to this message

#923: sounds good

by Flamie on 06/22/2005 14:33

I'm no coder so I can't really tell which way to do things are the best.

as long as I seemlessly can walk between zones (and see into zones as if they were part of the zone I am in) I'm pleased.

and since zones consist of cubes, and the engine already have the code to intersect cubes I suggest prebuffer/preloading algorithm that intersects 9 zone as one single large zone, that dynamically change as you enter the edges of it.

(going from x to x+1, removes the zone x-1, makes the zone x be x-1, and preloads x+1, then intersects the zones it has loaded to crate a new 3x3x3 cube and replaces the old one. all of this not visible to the user)

reply to this message

#924: Re: sounds good

by RealNitro on 06/22/2005 15:24, refers to #924

Will the area's the player has already visited be saved? So he/she can return to the same place if he/she wants?

reply to this message

#925: Re: sounds good

by quirk on 06/22/2005 17:16, refers to #925

I agree mostly, but what will happen if (for whatever reason) everything isn't local and available for access right now?

reply to this message

#926: Re: sounds good

by Aardappel_ on 06/22/2005 20:52, refers to #926

You're all missing the obvious. Sauerbraten was designed for huge worlds from the start. Scale is not an issue, the only limiting factor is the number of octree nodes.

100 meg of memory can store 3-4 MILLION octree nodes. By comparison, the most detailed maps right now use about 100k nodes, but that is because of insane detail going on. More normal current maps use 10-20k nodes. Using instanced octree nodes for detail in the future will reduce the need for such detail, and a huge RPG or MMORPG world does not need to look as detail as killfactory or roughinery for every inch of it. So that 3 or 4 million can hold a LOT of cool world space.

The only issue is that currently the entire map is converted to vertices on load. That is the only change that needs to be made in the future, that instead it uses a cache of vertices for chunks of the world instead. This is pretty easy, efficient, and will cost no "load time".

reply to this message

#927: Re: sounds good

by TOGoS_1u2kuhbui on 06/22/2005 22:24, refers to #927

I disagree with Aard on a lot of things, but it's definitely good to have a conservative viewpoint to keep us all from going too nutty :)

Without the ability to make portals, we'd be forever confined to linear space. No wraparound worlds or whatever. Wraparound worlds in my experience make mapping immensely more interesting :) And being able to link to *other* peopls's worlds would also be great. My vision is that someday everyone (that wants to participate)'s maps would be linked together. Instead of going off to sauermaps.com to download a new map, you'd just 'go exploring' and stumble across them :)

Morgaine: what do you think about my idea for cube-based portals? (http://strlen.com/wiki/?id=SauerbratenMapLinking)I'd think that would relieve the need to worry about portals in the rendering engine, as once loaded, neighboring worlds can be treated (as far as the rendering engine is concerned) as part of the main octree.

reply to this message

#928: Re: sounds good

by shadow516 on 06/24/2005 00:02, refers to #927

The wiki won't load on my browser :(

reply to this message

#929: Re: sounds good

by pushplay on 06/24/2005 07:08, refers to #928

:/

You're probably not running firefox...

reply to this message

#930: Sauer Central Server?

by locke on 06/24/2005 07:53

Is it possible to log in to multiplayer sauer-braten servers via a central server like Cube?

reply to this message

#931: Re: Sauer Central Server?

by Aardappel_ on 06/25/2005 09:58, refers to #930

multiplayer sauerbraten is not ready for "prime time"... there is no master server, it is really for testing only at this point.

reply to this message

#932: ..

by shahar on 06/25/2005 16:57

I dont think max really has much of a learning curve considering it's required to know in order to do 3d modeling... yah you could use the one from half life, but it's quite limited for high res characters (one bone per vertex) thing is, I think using an exporter for something from a well known package (max, maya, maybe even softimage) really helps the engine become more established.... or just pick a system that is preexisting but provides more use than a simple HL1 system... unfortunately I havnt done any work on custom characters for a while (mostly pre-rendered work with maya lately) anyways, whatever happens with the engine consider the needs of the engine, if you wish to have conversation, or wish to have stories you'd better have a systemthat alows more subtle animation (for facial, and fine tuned movements) and allows you to forego compression if it's needed... but if you need characters that can go online you also need a smallcharacter package... that's my own 2 bits anyways...

reply to this message

#933: Saur Lighting

by Louis! on 06/29/2005 17:09

Oh boo.. lost my super long message about lighting.. so I guess you will be spared as I'll make it much shorter this time!
The possibilities added by light mapping are making me gush! So many awesome possilibilies!!.. But I am wondering about/requesting certain additions to lighting.
Two huge must haves in my book are a global illumination value and colour for the whole level (basically lights the whole level evenly that colour).. great for giving outdoor levels a nice global sky colour base!.. And at least one distant light for making a proper sun!.. By distant I mean a light with vector and parallel beams to emulate the super far light of the sun.. this could be reffered to as the sun light and be considered to come from way far up.. any level with exposed sky would benefit HUGELY from this as light would automatically beam in from open windows.
The other thing I think would be fantastic would be the ability to place three types of lights..
-Level lights, contribute only to the light map.. pretty much the current lights.. These would be used for all that finer detail lighting that you probably don't want bogging down performance but that contribute to the levels atmosphere.
-Main Lights, Contribute to the light map.. but also vertex light dynamic models, like the players.. These would be the main light sources that really HAVE to light models for things to look right, this would do wonders towards making the players feel like they are in the world.
-Dynamic lights, do not contribute to the light map.. Either vertex based or Quake III style decal based.. these would be your rockets and muzzle flashes.. Probably would be cool to be able to set up dynamic lights in the level too.. imagine some cool swinging lights!.. Or pulsing alarm lights!

The last thing about lighting is concerning map objects.. It would be nice if they contributed to the light map and cast shadows too.. It would also be awesome if they could be vertex pre-lit to match the level lights too! That would finally make them look like they are really sitting in the world!

Ok.. maybe one more thing ^_^.. an option to render light maps using inderect lighting as well... For those of us who don't mind walking away from our computers while lighting gets computed ^_^...

To address the concern of not getting a sense for a levels lighting without the long light calc.. how about a quick and dirty vertex lighting toggle?

And finally... I swear!.. Has anyone considered precomputing visibility?.. I know it only compounds the problem of precompute times (ie. anti-Cube).. But the performance boost could be quite significant!.. And it probably would fatten the map files that much... Well.. ok.. it would.. but let's face it.. they could use a little fattening ^_^

Louis!

reply to this message

#934: Re: Sauer Lighting

by tentus on 06/29/2005 19:51, refers to #933

If we really want mapmodels to make shadows, why not make a really simple shadow entity? negative lighting that the mapper can manually put into to increase realism. Shadow entities would also make life easier is you use global lighting like he suggested- it would allow you to create two levels of lighting detail, which could seriously help filesize and performance on a map that is mostly outdoors.

reply to this message

#935: global lighting

by Wolf on 06/29/2005 21:15

cant you do this with a light with radius zero? not sure. might be wrong about this. does sauer have the dynamic lighting from rockets like cube does? if not whats stopping this?

reply to this message

#936: Re: global lighting

by enigma_0Z on 06/29/2005 21:54, refers to #935

You can't exactally do global lighting with a 0 radius light...

That kind of light goes on forever, but objects in it's path cast shadows... very harsh shadows.

But I digress... Sauer's lighting does need a little work. At least a global "Ambient light" setting. It is very difficult to get a nice looking outdoor level without either having it high noon or by "poking" all sorts of little lights everywhere to brighten up the shadows. That increases the mapper's work and the map size in general.

What is really needed is a way to specify the amount of ambient light in the map. By default sauer's shadows are REALLY dark. I mean _really really_ dark.

Basically, you would specify like "/ambient 100" and then place a sutible "sun" somewhere off in the distance with a 0 radius.

IMO that will bring alot of realism to the lighting system sauer has going. Alreay it's alot nicer than cube...

Oh yeah, and you need to be able to specify negative lights... for those dark corners. That way you can place some darker corners in a relatively ambient map...

reply to this message

#937: embedded language for sauerbraten

by absinth on 06/30/2005 15:58

i think the general consensus was that Lua is the best choice, short of writing a sauerbraten-specific language.
what i think should also be considered is the language io, which should fit quite good with sauerbratens goals (simplicity, small size, ...)

have a look at:
http://www.iolanguage.com/about/

reply to this message

#938: Re: embedded language for sauerbraten

by xtencilate on 06/30/2005 21:53, refers to #938

I'm new here, but I'd have to say LUA as well. Its widely used ( and growing ), its simplistic to a great extent.

Anyways, looking forward to spending some time on sauerbraten development. :) Looks great so far!

reply to this message

#939: ..

by staffy2005 on 07/01/2005 05:09

http://cube.snieb.com/node/92

reply to this message

#940: ambient lighting

by Sparr on 07/02/2005 22:06

good luck on ambient light. ive had that discussion with the devs, and it always ends against ambient :(

reply to this message

   Board Index