Sauerbraten engine development

by Aardappel on 03/03/2004 05:18, 1571 messages, last message: 03/14/2008 18:53, 1699565 views, last view: 05/15/2024 10:19

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

   Board Index   

#1024: Re: ..

by spentron on 07/22/2005 03:03, refers to #1023

Unreal and Quake 3 use BSP, which is a complicated visibility precalculation method that must be compiled as part of the mapping process. Portals are supposed to help the compiler in Unreal but in my experience you're better off letting it do it automatically 2/3 of the time. Probably helps more when you need it less.

reply to this message

#1025: Re: ..

by kurtis84 on 07/23/2005 15:27, refers to #1024

I don't see portals as an option, unless you want to require map compiling of some sort. I cannot think of an engine that used protals, and didn't require a long compile to do so ( in quake engines, it VIS compiling )

Surely theres a better way.

reply to this message

#1026: ..

by TOGoS_1u2kuhbui on 07/23/2005 20:37

The whole point of using portals is to avoid having to compile. Think of Descent, not Quake, which also used BSP.

reply to this message

#1027: ..

by TOGoS_1u2kuhbui on 07/24/2005 05:14

I wonder why it is necessary for the mapper to manually place portals. Why not let the mapper mark cubes as belonging to a certain visarea, and let the engine place portals between visareas whereever there are adjacent empty cubes? This would have the added advantage of working well with my map linking model :) (looking into a different map is not much different than looking into another visarea - visareas in different maps would simply have pointers to a different world structure)

reply to this message

#1028: occlusion culling

by schraf on 07/28/2005 03:29

The discussion got me interested in occlusion culling algorithms. Thought I would throw out some good reads for those that might not be very familiar with the pros and cons for the various algorithms:

http://graphics.lcs.mit.edu/~fredo/PUBLI/surveyTVCG.pdf

http://people.csail.mit.edu/seth/pubs/pubs.html

reply to this message

#1029: Re: occulsion cullling

by schraf on 07/28/2005 15:14

Now that I go back, I had thought there were more papers on occulsion. But here are some that stand out on that page (i think most of them show an approach that requires an off-line portion, but the previous works are nice):

Real-Time Occlusion Culling for Models with Large Occluders

similarly

A Spatially and Temporally Coherent Object Space Visibility Algorithm

also

Visibility Computations in Densely Occluded Polyhedral Environments

and

Visibility Computations in Polyhedral Environments

and

Visibility Preprocessing for Interactive Walkthroughs

reply to this message

#1030: rpgish

by staffy_051 on 07/29/2005 11:51

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

reply to this message

#1031: ..

by staffy_051 on 07/29/2005 12:13

just ignore it. It is just to remind you to get the latest sauerbraten.exe. (without it the map will be unplayable)

reply to this message

#1032: ..

by staffy_051 on 07/29/2005 12:24

http://cvs.sourceforge.net/viewcvs.py/sauerbraten/sauerbraten/sauerbraten/bin/sauerbraten.exe?rev=1.86&view=log

reply to this message

#1033: Re: CVS

by rootnis on 07/29/2005 21:17, refers to #1033

it is already in sauer for more than two weeks

reply to this message

#1034: ..

by shahar2k on 07/31/2005 08:54

random question, uhm the maps in sauer dont really occupy that much memory space as far as I know... what's stopping people from "linking" multiple maps together, and loading the next nearest map as you get close to it (say a portal type trigger) so that the transition from one map file to the next is seamless

reply to this message

#1035: ..

by _tester on 07/31/2005 09:27

u must not know what yur talking about

reply to this message

#1036: Re: ..

by staffy_12 on 07/31/2005 09:46, refers to #1034

1. There isn't much of a need for map linking at present (as far as I know).
2. It requires coding (and could be a large amount of work)

other than that it could be done.

reply to this message

#1037: Re: ..

by Gilt on 07/31/2005 18:44, refers to #1034

if two areas are meant to be connected, why not just put them in the same map?

reply to this message

#1038: Re: ..

by TOGoS_1u2kuhbui on 08/01/2005 05:36, refers to #1037

> if two areas are meant to be connected, why not just put them in the same map?

Because you might end up with infinitely large maps that way.

Not that this is a problem at the moment, but someday... ;)

reply to this message

#1039: ..

by clans on 08/02/2005 01:20

i like the idea of one map than a whole bunch of maps linked together

by shahar2k on 07/31/2005 08:54 through
71.133.216.49
>>uhm the maps in sauer dont really occupy that much memory space as far as I know... what's stopping people from "linking" multiple maps together

well just like you said, map files are already small.. why link when u can have 1 map. But i guess linking larger maps together would have a point to it.

but for now, id say no to linking them.

reply to this message

#1040: skin sharing

by Aardappel_ on 08/02/2005 06:56

multiple models can now share the same skin, to save space, by simply putting the skin in the parent directory. So for a

mapmodel "x/y"

the search order is now:

"x/y/skin.jpg"
"x/y/skin.png"
"x/skin.jpg"
"x/skin.png"

reply to this message

#1041: texture rotation

by Aardappel_ on 08/02/2005 08:08

the new "texture" command can now save you from needing to have multiple rotated copies of a texture on disk:

texture subnum filename flags

Binds the texture indicated in filename to the current texture slot, then increments the slot number. This is for use in texture.cfg files only. subnum allows secondary textures to be specified for a single texture slot, for use in shaders and other features (unused for now, should be set to 0 to indicate primary texture). Flags allow you to specify preprocessing on the image, currently only rotation (0 = none, 1 = 90 CW, 2 = 180, 3 = 270 CW).

If anyone wonders why I don't simply rotate the texture coordinates, that is because there currently are no texture coordinates in the vertex stream (adding them would add 40% to the vertex bandwidth). If there should be in the future, I can transparently replace this texture memory heavy solution.

reply to this message

#1042: Re: texture rotation

by TOGoS_1u2kuhbui on 08/02/2005 16:48, refers to #1041

Woohoo! Thanks aard. That'll be very helpful.

Also thanks to whoever put the 'ambient' variable in.

reply to this message

#1043: ..

by shahar2k on 08/02/2005 19:51

..

reply to this message

   Board Index