Sauer portals??

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

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   

#1: nope

by Aardappel_ on 07/04/2005 18:48

that is only possible in cube because the cube grid is so regular that a brute force approach is possible. In sauer, the same algorithm would be WAY too slow. Hence the portals as alternative.

reply to this message

#2: Re: nope

by Aardappel_ on 07/05/2005 03:28, refers to #2

I have seen that paper before I think. It is an attractive idea, as it could work without mapper intervention. The challenges for making this work are 5-fold:

- driver and card support and efficiency for queries (it is a relatively new feature)
- even with interleaved queries, the potential pipelining lag is still an issue. This is a general problem with the idea of occlusion queries
- there are no "natural" object boundaries on geometry, meaning it will be more complicated to make optimal (may require a second layer of dynamic statistical adaptive chunkifying.
- Chunks for culling may not coincide with current chunks for vertex arrays
- things like rapidly shifting viewpoint (either just looking around, fast movement, or teleports, as are common in an FPS game) will reduce the usefulness of the temporal dependency of the statistics.

reply to this message

#3: Re: nope

by enigma_0Z on 07/05/2005 06:08, refers to #1

Why would the new algorithm be so much slower in sauer? Is it because cube is basically a 2d height field?

I guess that makes sense, but how would a portal system work? What if you passed thru a portal and looked back, would you see black in the previous room, or just the previous room... then of course what is the point of the portals... I'm a little confused by your idea/implementation on the wiki. Perhaps a little more details would help clear somethings up for me anyway...

--

On a different subject,

Well... we can start by only rendering what is in front of the player...

That will cut out half of the map.

I don't know... I guess I'm concerned about occlusion cullling because insanely detailed maps like roughinery and killfactory run ~25-35 fps in the slower parts. And in my experience, LOD popup doesn't really increase my framerate that much in cube...

reply to this message

#4: Re: nope

by pushplay on 07/05/2005 08:47, refers to #3

Cube's structure was 2D as far as occuslsion was concerned, so processing was on the order of N. The Sauerbraten structure has no such restrictions, so line of sight occusion is on the oder of N^2. and N is not small.

How does the propsed portal system differ from BSP?

reply to this message

#5: Re: nope

by enigma_0Z on 07/05/2005 19:07, refers to #5

So basically...


If you have two rooms with a doorway between them... both boxes for now, you are in room A and look into room B, all of room A is always drawn, but only the visible part of room B is drawn?

Here's an example: http://img180.imageshack.us/img180/3928/portals5ah.gif

the space between A & B is a portal, player is the red dot in A, red lines represent line of sight to B... is only A, the doorway, and that part of B drawn, or is all of A & B drawn, but no other rooms?

reply to this message

#6: Re: nope

by enigma_0Z on 07/05/2005 22:33, refers to #6

In other words...

In this example, the player is at the red point, the red lines are one possible viewing direction, the green lines are another...

the darker red & green lines represent the second level of portal recursion/consideration...

For the red example,

Because the DE portal is in the view, it occludes on the bright red lines.
Becaause the EF portal is in the viewing area, it also occludes on the dark red lines. In this case rooms A, B, and C aren't even considered.

For the green example,

Pecause the AD portal is in the view, it occludes on the light green lines. However, the AB portal is in that view as well, the dark green line represents one edge of sight for that room, the left light green line and dark green line coincide... Would it consider room B or not? In this case rooms E, F, & C aren't considered?

Image: http://img89.imageshack.us/img89/9635/portalsex29sc.gif

Thanks for your help!

reply to this message

#7: ..

by enigma_0Z on 07/05/2005 22:36

I just got another idea on a _dynamic_ occlusion culling that my work in sauer...

Only cull on cubes of gridsize X. This could be set at a reasonable value such as the size that is either 4 or 8 times the smallest gridsize... That could reduce the amount of processing needed by alot... then you wouldn't have to cull around the more detailed features, but the larger obstacles, walls, and features would be culled around & out...

Just and ieda.

reply to this message

#8: ..

by enigma_0Z on 07/06/2005 00:15

OK, cool, thanks alot! That system would work pretty good for indoor maps...

but what about outdoor landscapes? Perhaps mountains could serve as occludors in a dynamic mode? If you are outdoors, then there aren't usually _many_ up/down occluding considerations.

reply to this message

#9: Re: nope

by Aardappel_ on 07/06/2005 00:27, refers to #5

the cube algorithm could work in sauer if we could make it 2d (meaning find an occlusion value for the the entire depth of a level), and do it at a large grid as enigma suggested.

Couple of problems with that:

- the grid will have to be large depending on the level size, which means level designers need to know to that they need to make really thick grid aligned walls to occlude anything

- because it is 2d, any gap, even in a room above you, will stop occlusion.

- worst: cube generates geometry on the fly, so could cull individual cubes. Sauerbraten renders LARGE chunks of the world at once, which is needed on modern GPUs to get good thruput. These chunks are less easy to cull, especially if they don't coincide with "rooms" as in the portal scheme.

reply to this message

#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

   Board Index