Note: LucasForums Archive Project
The content here was reconstructed by scraping the Wayback Machine in an effort to restore some of what was lost when LF went down. The LucasForums Archive Project claims no ownership over the content or assets that were archived on archive.org.

This project is meant for research purposes only.

2 questions plz answer

Page: 1 of 1
 Shadow_stone
03-28-2004, 2:32 PM
#1
is there any way to keep fps low, aside from caulking,
(and i know to do vis also) but is there anything else. ?
and for some reason tree's will drop my fps from 90 to 30 when they are on ..... anyway to fix that


and another question
what are area portals? like what do they do?
 LordP
03-28-2004, 3:42 PM
#2
Area portals go inbetween doors so your video card doesnt draw things a player cannot see. This helps with the FPS. Check out this URL for more on area portals.
http://fps.brainerd.net/Areaportals.htm)

Secondly, make sure you make all brushes that aren't touching the outside of the map into DETAIL brushes. To do this, select a brush in GTK radiant, right click and hit make detail. All brushes touching the outside of your map should be made into STRUCTURAL brushes. You can do this by right clicking a brush as well. If youre pretty well into a map then you can click on the view menu in radiant, then filter, then do DETAIL BRUSHES ONLY to see if you missed turning any brushes into details.
 Shadow_stone
03-28-2004, 4:55 PM
#3
when i used the area portals FPS went up but
whenever i walked through the door all the entity's would disappear, for example like all the other doors on the levels went invisible
 wedge2211
03-28-2004, 7:32 PM
#4
Originally posted by LordP
make sure you make all brushes that aren't touching the outside of the map into DETAIL brushes. To do this, select a brush in GTK radiant, right click and hit make detail. All brushes touching the outside of your map should be made into STRUCTURAL brushes.

No no no no. Bad. Tsk-tsk. This is one of the few places where RichDiesal went wrong and confused a generation of JO mappers.

Structural brushes are taken into account during VIS calculations, while detail brushes are treated as "invisible" to VIS. Any brush that comprises a "major" piece of architecture should be structural. Detail brushes are for things like tables, columns, consoles, stairs, and ALL transparent brushes.

The VIS process will split your map up into nodes, and then calculate which nodes are visible from which other nodes, using structural brushes, hint brushes, area portals, and antiportal brushes as a guide. Detail brushes, entities, and patches are ignored. Thus, if you imagine a large room with a wall dividing it in half, and that wall is a detail brush, then the game will draw everything on both sides of the wall, thinking that the player can see "through" the wall since the wall is a detail brush and was ignored by VIS. If the wall was a structural brush, then only the stuff on the same side of the wall as the player will be drawn, and this may save you a LOT of frames.

What does this mean? It means that any outer walls of buildings should be structural, floors of buildings, major walls, and especially the outer walls of your map should all be structural. Small partition walls, columns, windows, and small details should be detail brushes. Note that just because a brush is structural doesn't mean that the engine won't draw things that are directly behind it--it all depends on where the nodes are and which nodes are visible from which other nodes--if you can see even a small part of a given node, then everything in that node will be drawn. This means that it isn't useful (in fact, it's counter-productive) to make freestanding brushes like columns into struct brushes, since you'll be able to see behind them anyways, but the engine will have to think more than it should. Generally, only flat walls should be structural brushes. Read up on the VIS process and Q3 visibility to get more info on this...there's a really good site but I can't find it since the search function seems to not like loading right now. I'll get back to you with that.

You can kind of think of area portals as acting like struct brushes when the door is closed, but acting like detail brushes when the door is open. However, for them to work really properly, there can't be any other way for the player to see into the node on the other side of the area portal--there should be no way to see "around" the door. This means that if you place a door right next to a window that opens into the same room, it's not worth it to put an area portal in the door. I've also had trouble with have two area portals opening into the same node, for example two doors at either end of a single, straight hallway, but usually this works fine.

One thing you can try is covering every surface of your area portal brushes with the common/skip shader, and putting the area portal shader on only one surface of the brush (this has to be a surface parallel with the door).
 mslaf
03-28-2004, 7:37 PM
#5
when i used the area portals FPS went up but
whenever i walked through the door all the entity's would disappear, for example like all the other doors on the levels went invisible

That's because of an engine bug. Area portal must be applied to single surface on the brush to decrease this effect - but it won't disappear. Create a brush, apply the "skip" shader to all surfaces except the one for areaportal.
 Shadow_stone
03-28-2004, 9:17 PM
#6
wouldn't there be 2 surfaces of the area portal if its a door as in it goes both ways
 mslaf
03-28-2004, 10:09 PM
#7
wouldn't there be 2 surfaces of the area portal if its a door as in it goes both ways

No. The system shaders like this one work both directions even if they're applied to the single surface.

By using it you're telling the compiler/ engine to split/dynamically split BSP leaves in this particular place. Creating two splits in very close distance (like 1 unit i Radiant ) will create useless portal between them and double the “disappearing entities” effect. Is it a SP map?
 wedge2211
03-28-2004, 10:35 PM
#8
Originally posted by wedge2211
Read up on the VIS process and Q3 visibility to get more info on this...there's a really good site but I can't find it since the search function seems to not like loading right now. I'll get back to you with that.

Found it:

http://www.nibsworld.com/rtcw/tutorial_detail_and_hint_brushes_part1.shtml)
 Shadow_stone
03-28-2004, 10:53 PM
#9
Originally posted by mslaf
No. The system shaders like this one work both directions even if they're applied to the single surface.

By using it you're telling the compiler/ engine to split/dynamically split BSP leaves in this particular place. Creating two splits in very close distance (like 1 unit i Radiant ) will create useless portal between them and double the “disappearing entities” effect. Is it a SP map?

its an mp, just a lot of rooms, and its causing low fps,
one more thing
is there a reason why trees cause a drop of 30 fps

and thx wedge for the site
 WadeV1589
03-28-2004, 11:58 PM
#10
The leaves on trees are several flat images with transparency, when you look through the gaps between trees you're actually looking through an invisible part of that leaf image. The result of this is everything behind it has to be drawn through a transparent layer...it doesn't matter that it is fully transparent, the game has to draw what's behind it first and then apply the leaf image on top of it.

Net result: more work for graphics card = lower FPS.
 Ockniel
03-29-2004, 7:42 AM
#11
Originally posted by wedge2211
No no no no. Bad. Tsk-tsk. This is one of the few places where RichDiesal went wrong and confused a generation of JO mappers.

Structural brushes are taken into account during VIS calculations, while detail brushes are treated as "invisible" to VIS. Any brush that comprises a "major" piece of architecture should be structural. Detail brushes are for things like tables, columns, consoles, stairs, and ALL transparent brushes.

The VIS process will split your map up into nodes, and then calculate which nodes are visible from which other nodes, using structural brushes, hint brushes, area portals, and antiportal brushes as a guide. Detail brushes, entities, and patches are ignored. Thus, if you imagine a large room with a wall dividing it in half, and that wall is a detail brush, then the game will draw everything on both sides of the wall, thinking that the player can see "through" the wall since the wall is a detail brush and was ignored by VIS. If the wall was a structural brush, then only the stuff on the same side of the wall as the player will be drawn, and this may save you a LOT of frames.

What does this mean? It means that any outer walls of buildings should be structural, floors of buildings, major walls, and especially the outer walls of your map should all be structural. Small partition walls, columns, windows, and small details should be detail brushes. Note that just because a brush is structural doesn't mean that the engine won't draw things that are directly behind it--it all depends on where the nodes are and which nodes are visible from which other nodes--if you can see even a small part of a given node, then everything in that node will be drawn. This means that it isn't useful (in fact, it's counter-productive) to make freestanding brushes like columns into struct brushes, since you'll be able to see behind them anyways, but the engine will have to think more than it should. Generally, only flat walls should be structural brushes. Read up on the VIS process and Q3 visibility to get more info on this...there's a really good site but I can't find it since the search function seems to not like loading right now. I'll get back to you with that.

You can kind of think of area portals as acting like struct brushes when the door is closed, but acting like detail brushes when the door is open. However, for them to work really properly, there can't be any other way for the player to see into the node on the other side of the area portal--there should be no way to see "around" the door. This means that if you place a door right next to a window that opens into the same room, it's not worth it to put an area portal in the door. I've also had trouble with have two area portals opening into the same node, for example two doors at either end of a single, straight hallway, but usually this works fine.

One thing you can try is covering every surface of your area portal brushes with the common/skip shader, and putting the area portal shader on only one surface of the brush (this has to be a surface parallel with the door).

:eek: :eek: :eek:
Is there anything you dont know?
 WadeV1589
03-29-2004, 10:32 AM
#12
He doesn't know my dogs name :D lol
 wedge2211
03-29-2004, 1:46 PM
#13
Muffy.
 WadeV1589
03-29-2004, 3:28 PM
#14
lmao....aah Muffy

nah it's Ricky :D

BTW wedge haven't you wrote that information out in web form somewhere so you can just link to it? Seems insane to repeat it so much.
 wedge2211
03-29-2004, 5:08 PM
#15
DAMN! There goes all my super power!

...No, I don't have that written up on the web. Hmm, that's an idea, though. The Nibs tutorial pretty much explains everything, I should really just remember that particular link.
 Jedi_Vogel
03-30-2004, 8:29 AM
#16
Ok, so I have rebuilt my centre building and although it's small-ish (it is only one small part of the map) I want to keep good framerates as it is intended for MP.

I managed just by pure Areaportals to but out the tris created by a round room. But in between "square" rooms and when I build a door, the tris are STILL drawn behind it.

I also tried the system/skip brush and texturing one side with areaportal and STILL the tris were drawn on the other side. I followed the Areaportal tutorial posted above and every search thing either says Areaportals are enough OR to use a system/skip.

Any ideas?
 WadeV1589
03-30-2004, 11:43 AM
#17
The areaportal must fit perfectly the shape of the door except in an instance where the doorway uses patch meshes to add curved corners and so on. In this case the door should still be a regular square/rectangle that goes inside the patches.

Ugh I've put myself into a bitch to explain...

Ok areaportals only work if they totally separate 2 areas that have access via doorways that can be closed; the two areas cannot have windows looking into each other or any gaps in the walls that separate them; the walls that separate the two rooms must be structural and not detail.
 Jedi_Vogel
03-30-2004, 1:05 PM
#18
Well it's a "square" door, the frame makes it more interesting :P

Two room example. Each room is built with a gap between them. Only one door joining them. Now, in that gap between the rooms and eitherside of the door, there needs to be areaportal?

And the door itself goes up in between the rooms. I build that, and there is also area portal "inside it". Does this "inside areaportal" need to be the same width and height as the door, but not the same depth?

Or as it's invisible can a whole Areaportal separate two rooms and just "pass through" the door?

*isn't making sense*
 WadeV1589
03-30-2004, 4:22 PM
#19
One area portal surface inside the door, other faces of the brush need to be system/skip.

It needs to fit the shape of the entrance, the door can be any shape but the area portal must fit to all the brushes

Say you had this:

_____
|/ \|
| |
| |

The door was shaped so the 2 corners are chopped off but those 2 corners are actually meshes, the shape of the entrance is a rectangle so the area portal needs to fit to that.
 GothiX
03-30-2004, 5:00 PM
#20
Originally posted by wedge2211
DAMN! There goes all my super power!

...No, I don't have that written up on the web. Hmm, that's an idea, though. The Nibs tutorial pretty much explains everything, I should really just remember that particular link.

MR article, maybe?
 Jedi_Vogel
03-31-2004, 9:54 AM
#21
Wade- thanks, but if the door is two-way does it work in both directions?
 WadeV1589
03-31-2004, 2:13 PM
#22
Yes
Page: 1 of 1