Quake3World

I'm slowly working towards my first beta ever. Throughout the years I've read a lot about optimising and I do have a understanding about the basics. However, Quake 3 is 13 years old and current tris counts can be much higher, without causing problems, then back in the day. What is currently a good triscount / r_speed to aim at?

I have no illusions about my map getting server time or anything like that. Seeing as how it basically took about ten years to come this far with just one map, I don't want to spent another ten optimising it

Not that I'm lazy, well perhaps a bit, but I probably made every possible building mistake there is. So optimising it properly would mean rebuilding it entirely. My question is then, what are the absolute minimal optimisations to be done?

With todays hardware and triscounts is it even relevent to manipulate t-junctions to reduce minor triscounts?

A structural hull with detail brushes makes it easier for bots to navigate correct? I'm not planning to skip botplay, but in my test versions they play rather well without using detail brushes. Which gives me the impression it only matters for triscount / r_speeds. The same as using caulk to elimate overdraw.

I know you can use hintbrushes if Quake decides to draw areas that in reality can't be seen. But my understanding of that concept never went any futher then that. The same goes for when to use areaportals.

I have no questions regarding botclip or player clip since that's pretty self explanatory.

If I've left anything out, misunderstood what I've read or if I'm just plain wrong, I would appreciate anyone taking the time to elaborate. Same goes for anyone trying to answer any of my questions.

To-do:

• Caulk unseen faces.
• Remove T-junctions (especially on brushes around patches). Not necessarily to lower polycounts, but to remove "sparklies" which are actual visual artifacts.
• Caulk behind patches.
• Reduce overdraw.
• Reduce long lines of sight (bad for performance as well as gameplay)

Sure more will come to me later.

Structural/detail or better yet, caulk hull has nothing to do with bots, everything to do with portal optimization. It helps to improve the whole -vis process, and thereby rendering performance. Physically, structural and detail brushes are exactly the same, it is just a flag that tells the -vis stage what to ignore when calculating the PVS (potential visible set) - it's like an index of what should be drawn for the player from any point of the map.

You might want to explain what part of the hint process you don't understand, it's a big subject. Have you read my hint tutorial?
viewtopic.php?t=3620

As what I've read, a optimized caulk hull will help you to reduce your portals (-vis -saveprt plugins toggle portal viewer) dramatically, since every different textured brush will split them.
Just read through obsidians hint tut and the archived links. Explains everything pretty good. And dl all the example maps and look at them.

Probably the worst advice ever, but I'll just say I've never used a hint brush in my life, due to me still not understanding how to use them. So don't worry too much about advanced stuff like hinting if the map doesn't demand it yet. Focus on the basic stuff obsidian listed first anyway.

If you want to understand hints, it's a good idea to load up the .prt file with your map as Bliccer explained above. What you will see are all the portals being generated by the recursive BSP process. The BSP process starts to break down the inner volume of your map continuously until every single volume is a convex volume. It does this while indexing this relationship between volumes, the BSP-tree.

You will typically see a huge difference between the awful mess that a fully structural map will produce and the better optimized one that uses a fair amount of detail brushes. Even more ideal is converting all textured brushes to detail and manually overlaying the map with structural caulk (aka. caulk-hull construction method).

The BSP process is pretty random in how it starts splitting everything down into convex volumes, so it often places portals in places that are less than optimal. Hint brushes are a way to manually place portal planes to coax the BSP process to do a better job. You can inspect the loaded PRT file and start spotting problem areas and fixing them with hint. See my tutorial linked above to see some examples of what I came across and how I fixed them.

Just to add to what has already been said:
Optimizing really takes two forms.
Optimizing for performance (as discussed by Bliccer and Obsidian) and optimizing for bot play (which is often over looked)
I wanted to discuss the bot play side, seeing as it hasn't been mentioned. I wondered if your confusion regarding simplified structural maps and bot navigation came from the discussion on using -fixass. That approach generally isn't required unless the map has a lot of funky brushwork or is largely comprised of models.
Botclip, as you say is fairly self explanatory bot remember to apply brush botclips to all patches. You may also require botclip if you use clusterportal brushes to try to balance bot areas. Cardigan wrote an very good article on using clusterportals and botclip (in think in collaboration with Raven).
Getting rid of tiny clusters is the hard part in getting bots to behave somewhat logically, that takes a bit of messing about with clusterportal brushes. I always wished it was possible to load a cluster or area file from bspc into GTK, in a similar way to what we can do with the prt file.
I learnt/developed a few tricks to force bspc to merge clusters back in the day

I really appreciate the input guys! I really do.

Excellent Hint tutorial Obsidian. It makes much more sense now.
dONKEY, yes, I have a backup of Cardigan's articles. Should come in handy.

I have a better understanding now. Only question that remains atm is what a acceptable triscount / r_speed is?

I'd say 20k is decent with a fov of 105. 30k is still acceptable but I'd not push it further than that.

Infernis wrote:dONKEY, yes, I have a backup of Cardigan's articles. Should come in handy.

Mind sending me a copy?

Unfortunately, the screenshots are missing and the text isn't properly formatted. However, the content is there and that's what matters most. I put two word documents in this zip file. Let me know if it works.

Thanks, was hoping to put them up back on the web, I'll see what I can do with it.

obsidian wrote:Thanks, was hoping to put them up back on the web, I'll see what I can do with it.

Found it here:
http://www.custommapmakers.org/wiki/ind ... isbehaving

dONKEY wrote:

obsidian wrote:Thanks, was hoping to put them up back on the web, I'll see what I can do with it.

Found it here:
http://www.custommapmakers.org/wiki/ind ... isbehaving

That's a great tutorial. Lots of things about clusterportals in there that I didn't know.

I've saved Cardigan's Powder Room ages ago and put it up here for everyone, no need to edit some wiki articles. Done that exactly for the reason that the wayback machines has no pics archived with this one.
click me

Most of this is not really useful from a LD perspective, but may be worthwhile if you want to know what's going on...
http://www.kbs.twi.tudelft.nl/docs/MSc/ ... thesis.pdf