Sauer portals??

by enigma_0Z on 07/04/2005 01:35, 29 messages, last message: 07/14/2005 04:36, 7171 views, last view: 05/04/2024 23:42

just reading about sauer "portals" in the new wiki... I have a question... is it possible to do line-of-sight occluding like cube does? I think it would help out alot in outdoors maps as well as larger, but detailed, rooms...

Just an ieda.

   Board Index   

#10: Re: nope

by enigma_0Z on 07/06/2005 02:56, refers to #9

Good question...

What is sauer's default vertical FOV? Is it the same as the horizontal?

As to Morgaine2's suggestion, how would you draw the world when you have a vertical pitch of 45 degrees? Could we still reduce the viewing window to a 2d occluding plane?

If we create too many "special" situations instead of cube cases we run into the same problem... IMO the best idea is start by ignoring geometry outside of the current FOV... LoS detection should work vertically in sauer as well as horizontally... including culling out not shown geometry simply because it's not in the FOV (eg behind or below, too far left or right, etc)... That in itself will speed up sauer immensely...

For indoor maps perhaps we can mark "walls" as culling surfaces manually instead of marking spaces as portals?

This could work alot better for outdoor scenes, perhaps we could

reply to this message

#11: Re: nope

by Aardappel_ on 07/06/2005 03:22, refers to #10

making it 3d will require too much memory for storing cubes (the traversal is bearable), but the bigger problem is that the occlusion map now has to become 2d (it is 1d in Cube) which means you need WAY more rays to build it up, and checking becomes more expensive.

FOV doesn't affect the problem.

reply to this message

#12: ..

by staffy2005 on 07/06/2005 09:25

I thought it already killed cubes outside your fov. (because I lost cubes inside my fov with a sis video card.)

reply to this message

#13: Re: nope

by absinth on 07/06/2005 19:26, refers to #9

>one shouldn't forget that they [portals] have downsides ... big ones.

i always thought that the biggest drawback for portals is that they have to be manually placed by the mapper...

i've not yet heard about automatic placement of portals, but i can't imagine it beeing very efficient

the other thing is that they are mostly suited for descent-style closed-room maps

i still think that the best general solution for occlusion culling is the algorithm described in this paper, as mentioned a while ago in the development thread:

http://www.cg.tuwien.ac.at/research/publications/2004/Bittner-2004-CHC/

reply to this message

#14: Re: nope

by absinth on 07/06/2005 22:48, refers to #14

>Oh, that's a good paper.

i'm certainly biased towards the paper because it was developed on my university, and i've talked to some of the people involved, and they sounded quite sold on it ;->

there is also a chapter in "GPU Gems 2" about this algorithm

reply to this message

#15: All I know is....

by Pxtl on 07/08/2005 02:22

If some sort of sophisticated occlusion is added to Sauer, I hope it doesn't require the mappers to learn to use special mapping functions to use it, 'cause they never do. I mean, if you think remembering to hit the F key for fills in Cube is bad, you should see the kind of poor mapping more famous engines get - in UT, there are tons of directive surfaces (like manually defining portals) to help the map compiler optimise, and mappers never use them.

reply to this message

#16: Re: All I know is....

by tentus on 07/08/2005 05:23, refers to #15

ouch. yet another brick wall- incompetence as well as coding issues.

does sauer already occull faces that are at greater than 90 degrees from the player? ie anything that you coul see through if there wasn't a face in your way?

reply to this message

#17: Re: All I know is....

by makkE on 07/08/2005 11:05, refers to #15

You will always have good and bad maps. Even in a thing as easy as cube, some people just don´t bother about reading any docs, I have seen numerous maps where people pulled ceilings down to occlude the gap, because they didn´t know there was "f"...

Mapping always means having to understand how the engine works, not in detail, but enough to know what works and what not.(and especially knowing how to optimize it).
I don´t think a "just map, engine will do all optimizing itself"-engine is really possible. And imho it´s a good thing.
We just get to see more of the bad stuff in cube, because more people are willing to afford 1 hour to make some rooms, call it map and /sendmap it.. just the downside of comfortable in-game editing.

reply to this message

#18: Re: All I know is...

by absinth on 07/08/2005 21:59

>I hope it doesn't require the mappers to learn to use special mapping functions to use it

thats why i said that the need for manual placement is the biggest weakness of the portal system...

>Mapping always means having to understand how the engine works, not in detail, but enough to know what works and what not

AFAIK the mechanism described in the paper i posted is pretty general and shouldn't require any understanding or special behavior on side of the mapper.

reply to this message

#19: :/

by pushplay on 07/09/2005 07:47

How hard would automatic portal placement be? Something the engine could whip up and more advanced mappers could optimize?

reply to this message

#20: ..

by TOGoS_1u2kuhbui on 07/09/2005 15:25

OK, what about this?

Take the cube of size X which contains the viewer. Now, for each cube surrounding the current one of size X or larger, check if it is entirely solid. If so, don't render anything directly behind that cube. Otherwise, render the cube's contents and do the same thing again starting at that cube. It's sort of like there were portals at the edges of every cube of size X (or larger). Or is this the 'too many portals and it becomes inefficient' problem? Maybe not if X is large...

reply to this message

#21: Re: ..

by Aardappel_ on 07/09/2005 20:34, refers to #20

that kind of algorithm gets complicated fast. What you descrive only deals easily with cubes directly in line with the viewer, what do you do with all the others (at various angles)? Also, how does this work with the vertex arrays?

reply to this message

#22: ..

by TOGoS_1u2kuhbui on 07/09/2005 23:13

Yeah, I was thinking that might be a problem. As for vertex arrays, I figured it would store vertex arrays for each cube of size X.

Maybe 'sticking portals between every cube of size X' is a better way to think about it. And in low detail areas, use a larger X. :P

reply to this message

#23: An alternative to portals...

by HopFrog on 07/10/2005 14:24

could be anti-portals. If you think about it, this would be easier to use from a mapper's perspective, since all that would have to be done is to select some cubes and apply a material. Then, any ray between your location and the destination cube that intersects with the near-plane of the antiportal material simply would not be drawn.

The only thing I'm having difficulty with is optimizing the algorithm for speed in my head, because it seems that it would scale with every antiportal within the scene.

If somehow the closest antiportal was used first (which in most cases is also the most useful) then in effect other, now-useless antiportals could be culled too.

I'm thinking out loud too. :)

It presents the problem of the mapper having to manually add them, but it seems like a really easy method in execution. It's the algorithm that could be tricky.

reply to this message

#24: Re: An alternative to portals...

by HopFrog on 07/10/2005 14:25, refers to #23

I should say, any line between the destination and yourself that intersects with the anti-portal results in the destination cube not being drawn. After re-reading I caught the error in my terminology.

reply to this message

#25: Re: An alternative to portals...

by D.plomat on 07/11/2005 14:00, refers to #24

This anti-portals system can maybe operate on the fly without mapper intervention by using some cubes as anti-portals, like giving cubes a "potential occlusion" value, depending on their size , distance from the player and direction of the viewpoint (and maybe also their distance from the borders of the map?). The engine would compute this value on cubes with a max distance and a min size/distance ratio, maybe tunable for CPU vs GPU load.

This would probably work well in indoor areas, but unfortunately that would be nearly useless when the player is in the middle of an open landscape where things to occlude by distant walls composed of many cubes and would have a bad occluded/occluders ratio.

As the map structure can vary a lot in complexity per areas and it would require too much CPU load to compute this complexity a each frame, maybe there could be a "complexity map" that would be computed at map load that store some "density" values of the areas of the map so the occlusion algorythm would focus as much on what to occlude as what to use as occluders, maybe by trying to find the biggest cubes (or maybe any surfaces?) that are somewhat between the viewpoint and the most complex areas.
Looks like this would work on mixed detailed indoors and large outdoor areas but i don't know how that would behave on a fully high-detail map like roughinery.

reply to this message

#26: ..

by enigma_0Z on 07/11/2005 18:18

Well, we'll need to get some kind of occlusion culling up and running soon... one of the newer maps, "oasis" runs ~25 FPS on my machine due to all the mapmodels...

/clearents mapmodel gave me back to ~80 FPS...

Perhaps we should encourage people to use sauer's world geometry instead of mapmodels?

reply to this message

#27: ..

by enigma_0Z on 07/14/2005 01:21

A few questions 'bout some form of occlusion culling in sauer...

1) The main engine code for the world is basically finished, right (except for things like heightfields)?

2) How many portals would a line of sight query have to pass thru before it become really innefficient?

3) How soon will an occluding system be up and running? Already I'm hitting maps that run really slow (admitted, I have slower hardware, but still).

4) Why do models slow the engine down so much? Mapmodels in oasis slow my framerate down ALOT (see above post). In my new SP map, same thing with monsters.

reply to this message

#28: Re: ..

by Aardappel_ on 07/14/2005 02:50, refers to #27

most current maps wouldn't benefit all that much from occlusion culling, as they are small maps. Occlusion culling would mainly be needed for some of the large worlds I am planning.

So if your framerate is already low, it means that your hardware is simply to slow for sauerbraten, or that some of the maps are a bit too insane in their inefficient use of detail.

Oasis is slow because kurt used that 4000 poly leaves model allover, as you can see that map has about 200k model polys, and 20k world polys. That is not exactly a healthy balance.

reply to this message

#29: Re: ..

by enigma_0Z on 07/14/2005 04:36, refers to #28

I'm not talking about current maps (except for roughinery and oasis, heh), I'm talking about new, large SP maps, SP maps approaching the size of some of cube's larger SP maps.

It's definately partially (mostly?) my hardware (I admit it is quite old), but I'm sure that sprawling maps (landscape or indoor-sp) would benifit alot from occlusion culling of some sort.

reply to this message

   Board Index