Sauerbraten engine development

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

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

   Board Index   

#1019: Re: portals

by pushplay on 07/20/2005 06:59, refers to #1018

Usually I'm a huge fan of choice. But. When it comes to occulsion culling, giving the mapper more power is bad. Understanding the pros and cons of a bunch of options is a lot of work. Making mappers understand a single method and use it properly is bad enough. I think all of it runs contrary to the reason mapping for Cube was popular.

reply to this message

#1020: Re: portals

by spentron on 07/20/2005 12:33, refers to #1019

Portals are weird, defining what you can't see by what you can. I tried using them in Unreal, and except for the looking-glass type which is different, took most of them out as they caused visual glitches and poor performance stats (and then went on to tax the engine 10 times as much as well).

What would be good is some kind of plain occlusion, even if limited. For example if you have a huge outdoor area with big windowless buildings with 32 gridsize walls, you should be able to put lots of details and models inside without issues.

reply to this message

#1021: Re: portals

by HopFrog on 07/20/2005 13:32, refers to #1019

Good points. :)

reply to this message

#1022: ..

by madcrow on 07/20/2005 14:54

How do the commercial engines like Quake 3 and Unreal do their default culling? Maybe we should try things like that.

reply to this message

#1023: Re: ..

by Pxtl on 07/20/2005 15:30, refers to #1022

Unreal uses portals, and they're a pain, because mappers have to manually define areas as being a portal. Now, if Cube mappers often don't know to use the fill commmand, can we expect Sauer mappers to use the Portal command?

reply to this message

#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

   Board Index