Got some speed boosts from recalculating the node and leaf bounding boxes for brush models. I was actually totally unaware that this was a problem, but reading through hmap2's source code alerted me to it, so now there's some much more efficient frustum culling going on.
Been having more fun with MDLs. Before I say anything else, I need to stress that all of the following is optional, OK. So let's not be getting paranoid about any of it.
First of all I put mesh optimization back on MDL files, but this time did it right. What this does is rearrange vertexes so that they're in a more optimal layout for faster rendering. To be honest it's really only of major benefit for huge datasets, but it feels like the right thing to do, so it's done.
This does cause a small (i.e. barely even noticeable) delay in map loading, so if it's objectionable to you, you can always disable it by using r_optimizealiasmodels 0. This one is enabled by default, so it's opt-out. I would encourage you to leave it at 1 and only disable it if it causes you any specific problems; the extra millisecond or so to load each MDL should otherwise not be a problem, and you may get a performance boost from it.
The second one is the return of the dreaded "mesh files", also known as "the glquake directory" (although I've called it "mesh", and the files are a new .ms3 format). DON'T PANIC - this one is optional, remember, and in this case it's strictly opt-in (i.e. disabled by default). Set r_cachealiasmodels to 1 to enable it (the default is 0, which is disabled, remember) and you'll offset some of the speed loss from mesh optimization by loading an already optimized mesh from disk.
What's different here is that the format has been changed to conform to my new in-memory layout for MDL files (introduced 2 years ago), and also to resolve problems with mismatched meshes (try saying that fast after a few beers). The important bit is that the new .ms3 file contains an MD5 checksum which is taken from the original MDL and used to verify that the .ms3 file is valid. The other important bit is that this is disabled by default, or did I already mention that?
So if you don't mind having extra files clutter up your Quake directory, and if you want slightly faster loading times (although on todays hardware the gain will be marginal at best, and may even be slower if disk IO is a bottleneck for you) you can opt-in to this, otherwise it won't even happen at all and you can cheerfully carry on as if it never even existed.
In other news, I tested the new fullbrights code on Intel today and it worked Just Fine, thangyewvuhmush, so I'm thinking of releasing this puppy tomorrow.
Tuesday, March 15, 2011
DirectQ Update - 15th March 2011
Posted by
mhquake
at
10:01 PM
Subscribe to:
Post Comments (Atom)
3 comments:
What this does is rearrange vertexes so that they're in a more optimal layout for faster rendering.
Very interesting. Can you elaborate a bit on how this works?
The basic thing is that your 3D card has a vertex cache on it, and if a vertex is already in that cache then it can skip the vertex shader stage and just be reused. Optimization means reordering vertexes in the MDL so that vertexes are more likely to be reused sooner rather than later.
Google "vertex cache optimization" for more info than a person could probably want.
"Google 'vertex cache optimization' for more info than a person could probably want." --MH
I've done exactly that and came across this document which I found quite an interesting read.
Just wondered how far the optimizing extend of your .ms3 goes, and whether or not the technique described above is still relevant to unified shader hardware.. I suspect, that on modern hardware, at least as far as relatively low-poly quake models are concerned, this won't make any noticeable difference.. unless of course, hundreds of instances of the same model need to be rendered in a scene ;)
Post a Comment