OrbWeaver@Posted: Sun Nov 13, 2005 12:48 pm :
I was just playing through After the War (which is a great map btw, very HL2-like) but the performance is absolutely appalling on my Radeon 9800 XT (sometimes as low as 10 FPS).

Activating r_showportals shows that most of the portals are yellow, which I have never seen before. Does this mean they are not working? Unfortunately I cannot test with r_showtris since this crashes my computer with a large map.

Mordenkainen@Posted: Mon Nov 14, 2005 2:17 pm :
Heya, ATW 1 (heh) is _very_ CPU bound. For reference, switching my 9800 Pro with a X850XT PT made 0 difference in some parts (like in the bunker looking all the way to the construction area) and I have a P4 3.2. If I had built it for Q4 I could have used distance portals and most importantly r_showbatch with is incredibly useful. In this Q4 map I'm doing now it's proving to be an absolute lifesaver.

If D3 had r_showbatch at least I could make it less CPU bound (well, I can do it without it but it'd be a guessing game for the most part).

A second reason is the water: if you open the map in the editor you'll see that I had to resort to strange visportal placing, that's because you can't have a visportal (or any material that has "areaportal" in it) breaking the water surface or the reflections will turn off whenever the engine pretty much feels like it. In Q4 this restriction still applies but it's more consistent: reflections turn off only when the visportal that breaks the surface is closed.

As for the yellow visportals I don't think I've ever got them but I guess it's probably a similar reason as when they appear blue sometimes: you need to use a r_showtris value > 0 to have them show up as either red or green.

As for r_showtris crashing. Have you tried it in windowed mode? The last D3CDiT demo would crash within seconds except if I tried it in windowed mode. This is likely a driver bug.

OrbWeaver@Posted: Mon Nov 14, 2005 2:39 pm :
I did not realise it was the CPU that was slowing things down - I wonder if this is mainly due to the shadow volumes, or to the overdraw (standing in the start point in the tunnel the entire outside area is being rendered).

If I run the map from the editor I don't get the yellow portals, but the portals still behave very strangely, for example they all just disappear (and stop working, as revealed by showTris) if I move a couple of feet to one side. I was going to try adding some more visportals to see if I could improve performance but gave up once this started happening.

r_showTris does work fine in windowed mode, I think this is an ATI-specific issue (like so many things :( )

BloodRayne@Posted: Mon Nov 14, 2005 4:09 pm :
Mordenkainen wrote:
.... distance portals ....r_showbatch with is ...

Can you explain (really shortly) what distance portals are and what r_showbatch is?


Mordenkainen@Posted: Mon Nov 14, 2005 4:48 pm :
BloodRayne wrote:
Mordenkainen wrote:
.... distance portals ....r_showbatch with is ...

Can you explain (really shortly) what distance portals are and what r_showbatch is?


Actually I just added distance-based portal information to the wiki: http://www.modwiki.net/wiki/Visportal#D ... visportals. Put simply, they are visportals that can automatically close when the player is x units away even if by normal circunstances they'd be open.

r_showbatch (mental note: add this to wiki), is similar to r_showtris except it shows you how the engine is batching polygons and sending them to the video card. batching can become a very significant bottleneck so this CVar is extremelly useful in determining exactly how your geometry can be optimised. Batching is a somewhat complex subject but here is a quick description.

Batches are collections of triangles that the CPU has to group so they can be drawn (or not) by the video card. The engine separates polygons into groups because of certain hardware and driver limitations but what's important is that all else being equal, sending 100k polys to the video card in one go is always faster than sending 10 batches of 10k polys each. This is because the CPU has to spend time "batching them". Here's an analogy:

What takes more effort? Drinking a pint of lager in one sitting or in several trips? In the former you raise your glass, gulp down the beer then set your glass down. In the later you raise your glass, take a sip, put it down, raise your glass, take another sip, put it down again, repeat. Conclusion you spend a lot of your time "drinking" but not actually swallowing any lager.

So the cvar shows you how the engine is separating into batches. Important factors here are (btw these are comulative i.e. all conditions must be met for polys to be batched together):

*polygons with the same texture.
*polygons with the same depth sort value.
*polygons with the same light interaction.

If you want just one batch your level would have to use a single texture, a single light and have no entities, decals or visportals. ;)

Anyway, the CVar colours batches differently on the amount of polys each has. More polys is generally better but not always:

Pink - very bad. This batch has only a few polys.
Red - still bad but better than pink.
Orange - better than red but still needs optimisation.
Yellow - reasonable number of polys in the batch
light green - very good.
dark green - you're a god ;)

Now, more polys per batch is only good if the overall poly count of the scene remains constant. Example: if you have 50k tris in a scene and you have 20 pink batches, 10 red batches and 5 yellow batches you could optimise how you're grouping entities, placing lights, choosing textures so that you get only 5 pinks, 5 reds and 5 yellows. This is a good optimisation since you've improved the batches' colours as reported in that cvar but you haven't added extra polys to do it (or you've added only a neglegible few).

You can however completely subvert the usefulness of the cvar by turning every pink batch you see into a dark green one. Say you have a glass window which is usually 2 polys. decals are always batched individually so they're pink. You could then subdivide the patch so it has 1000 polys and that will get you a green batch but you didn't actually optimise anything, in fact you actually increased the scene's complexity.

Damn I wrote a book on this didn't I? Anyway, I'll do an article for the wiki and give some practical examples.

evilartist@Posted: Mon Nov 14, 2005 6:40 pm :
Call me dense, but I'm not getting the idea with the yellow visportals. Why are the outlines appearing yellow again? I thought it was supposed to be green and red only.

OrbWeaver@Posted: Tue Nov 15, 2005 8:25 pm :
Found the answer to my own question: portals show as yellow when they are in contact with a surface that is ARB-shaded (such as water). They still operate, and are displayed in the usual red/green if r_showtris is activated.

Also for ATI users, installing the latest Omega drivers solved the r_showtris crashing problem - now I can activate it in full-screen mode without any problem.