This also seems to happen if you manually bsp2prt a map and then re-vis it, but I'm going to use the term "vispatched" here to cover both cases.
So, one feature of DirectQ is that it sets the contents colour when underwater to the correct colour of the water surface above you. I always though it was slightly weird in Quake that when you dived into blue water you got a sludgy brown colour, so I wanted to fix that. To do this it does some tracing through the BSP tree at load time to figure out the various colours needed.
It turns out that if you use a vispatched map it doesn't get all spots correctly. I'm not sure if this is a fault in my BSP tracing or if it is a fault in the bsp2prt/re-vis process, but that's not totally relevant for this discussion. What is relevant is that when you pass through these spots you'll get brief flashes alternating between the new colour and the old.
The fix for this involved tracking the last good contents colour and using that instead if you're in one of those spots (which was easy to identify). There are various extra conditions around whether this last good colour can be used, which are intended to catch situations where you get a contents transition or haven't yet been in water; overall it seems a lot more robust than it was.
It's interesting to note that this doesn't happen with maps which have been originally processed for translucent water the correct (and longer) way. Maybe there are differences in the BSP tree this generates?
Whatever, the moral of this particular story is that with 15 years of accumulated content there will always be more than ample room for something to come along and surprise you, and that there are still plenty of places where even 15 years of accumulated knowledge and fixes isn't enough, and you have to do something new.
Saturday, April 2, 2011
Vispatched Maps
Posted by
mhquake
at
4:38 PM
Subscribe to:
Post Comments (Atom)
11 comments:
Note that bsp2prt is a very old tool that probably shouldn't be used anymore. Bengt Jardrup's Bspinfo tool can also generate a prt file which apparently portalized the map better than the old compilers and bsp2prt do. Perhaps that's part of the reason that maps originally compiled for transparent water work better with your watercolor patch - especially if you tested it on newer maps (that were compiled with BJP's tools). -negke
I actually used hmap2 -bsp2prt for my own test, but yeah - this is a valid point. Maps which have been through the original bsp2prt and then the original vispatch may display bugs which latter knowledge has fixed in more recent tools.
It's interesting to note that this doesn't happen with maps which have been originally processed for translucent water the correct (and longer) way.
So what is the recommended way to do this these days?
"So what is the recommended way to do this these days?"
I'd say just use r_novis 1 (unless that cripples performance too much).
The trouble with r_novis 1 is that it only works on the client; the server won't send entities that are not in it's PVS. It's a little weird to jump into water and suddenly see lots of things appearing. DirectQ has an sv_novis cvar to work around that in SP games; in MP you're entirely at the mercy of whatever is running on the remote server, of course.
Best way: get the original map source, qbsp it again (using a tool that does translucent water), light it again, vis it again.
Second-best: get a modern bsp2prt tool (which hopefully has some fixes), use that, then re-vis the map yourself.
Worst: use the old vispatches.
None of this really matters now anyway as I've a fix in the engine to catch when it happens and correct it.
r_novis 1 chops my demo1 performance about in half, from ~1530 fps to ~860 fps, not that it really matters at these frame rates, of course.
Second-best: get a modern bsp2prt tool (which hopefully has some fixes), use that, then re-vis the map yourself.
Sounds doable. Time to break out a batch script!
You'd fully rebuild pretty much all of the original maps in half an hour to an hour on a modern PC.
Vispatched maps needs to be recompiled in order to fix those problems. The toolkit I've made to recompile maps for QuakeDC does this by recompiling the entities table ( -onlyents ) into the original maps.
Maps that goes through BSP2PRT and then goes through VIS doesn't give any problems in QuakeDC, so the problem seems to be in Vispatch.
Interestingly, I ran the original un-vispatched maps (pulled the PAKs straight from a fresh Steam install) through bspinfo to generate the PRTs and then VIS'ed via hmap2 (using the default parameters) — still no dice. It's possible the issue's been minimized to some extent (I can't be certain), but it's still present.
Not that it matters now that the overlay's being handled differently, but it's curious to me that I seem to be the only one experiencing this issue. Perhaps there's some crucial step in the process I've not completed or not done properly, perhaps?
I think that the bsp2prt part of the process is to blame here. If you think about it, the portals file is generated from the BSP tree, and a BSP tree that is split appropriately for translucent water will have some subtle differences from one that is not. Trying to cram different data into the same layout as before will always cause problems.
While I was unable to see the bug visually, I did manage to observe it by adding code that checked for it happening and printing a message to the screen. I've no reason to doubt that it was a real bug as opposed to something that was isolated to your machine.
Post a Comment