2 questions - func_areaportalwindow Created 14 years ago2010-08-09 02:10:32 UTC by quailcreek

1. When using an areaportalwindow, does the geometry enclosed in and behind it effectively cease to render when the rendered window is fully opaque? And if not, what is the purpose of the rendered window?

2. What does it mean if I have geometry that's rendering like this in-game:I assume it means there is too much geometry being rendered at one time. Thing is, I set up areportalwindows with hopes to remedy that problem (on the belief that the answer to my previous question is yes.) The func_brush pictured is identical to several others in the same room which render perfectly. If I put more than 22 of them in the room, the remainder render like shown in the image. But I have set up the areaportalwindows such that no more than ~10 of them are visible (not encolsed in an opaque rendered window) at any given time.

I have tried using func_lod's instead and got buggy results. That's aside from the fact that I need these brushed to cast shadows.

Could be errors with the actual geometry or your video card is artifacting from either damage or heat.

Okay.... well it can't be geometry errors because as I said, this is an identical copy of geometry elsewhere that renders fine. I'll try shutting down my computer for a while and then compiling the map immediately on start up to see if it's a heating issue, though the consistecy of the "22" amount makes me doubt it.

Weird. Ordinarily, I would accuse overheating or poorly constructed geometry in Hammer of being the cause of those rendering issues, but since they render just fine elsewhere.. Try copying the probematic geometry into a new, blank Hammer map and see if they appear there too.

To answer your first question about func_areaportals, you need to understand a little about how Source renders its worlds. Maps, upon compiling, are split into hundreds of individual sections called "leaves." These sections consist of all the explorable space available to the player, and the reason for doing this is to maximize performance. The engine analyzes the leaves the player is in at runtime, and if the leaf a player is in can draw an unobstructed line to any other leaf, that outlying leaf is drawn, while ones that can't be "seen" by the player's leaf are not rendered.

Func_areaportals are a way to force the engine not to render a leaf or section of leaves that are still visible to the player, no matter what the case. The section to be closed to the player needs to be sealed completely by world geometry and func_areaportals; if it isn't, you'll end up with a leak. When the player is the appropriate distance from all the areaportals such that they're all closed, the entire set of leaves are closed, and rendering them stops.

This can be really handy for openings of buildings in large, expansive spaces. When the player is too far away from the building to see into the windows, but too close for the engine to know that it shouldn't render the building's interior, func_areaportals can prevent rendering without any overtly noticable change to what the player sees.

All that said, it won't fix the rendering fuckups.

Thanks for the extended explanation, RotatorSplint. At least I know that my areaportalwindow system is set up properly, or at least not related to the rendering issue. Unfortunately, due to an unforseen problem expounded upon here, I won't be able to experiment with this any further until I'm once again able to compile ANYTHING.

This may sound like a dumb suggestion, but try making the brushwork a func_detail or func_illusionary if it isn't already. I know some of my crazy brushwork won't even compile as a world brush.

Thanks Captain Terror. I was planning on it. They were func_brush's before, which I thought meant they had the functionality that it turns out func_deatil has.