I posted about this in a comment a while back, but I think it may have gotten lost in the flurry of recent updates.
I'm reasonably certain that I know what is causing this to happen, but I need to get some info from anyone who's experiencing it in order to confirm.
So: if you're getting the clipping bug, could you post a reply here letting me know what your host_maxfps value is and what fps you're getting (just set scr_showfps 1 for this) at the time it happens. Also - does lowering the value of host_maxfps make it go away (try 100)?
Ta.
Saturday, March 10, 2012
The Dreaded Clipping Bug
Subscribe to:
Post Comments (Atom)
22 comments:
What is the clipping bug?
Is it the hiccup where there is an invisible ledge of sorts in a map for no apparent reason, that you can get caught up on?
Yup, that's the one.
Ok, phew, I just reproduced this using my regular method (id1-marcher-bastion).
My cl_maxfps is at 1440 (72*20). I normally get 750-900 fps. When the problem occurred I was getting around 720 fps.
Lowering the cl_maxfps to 100, 72, or 60 fps only made things worse. I sank even further into the ground.
Regards,
Mandel
Interestingly I used to have that issue 1 release back, but it seems fixed now... :|
"Lowering the cl_maxfps to 100, 72, or 60 fps only made things worse. I sank even further into the ground."
Interesting. It confirms my theory but not the way I'd expected. So it's definitely related to client input being faster than the server rate anyway; at least that's progress.
Hmm, am I the only one affected by this? May be something local then perhaps, and I don't want to have you debugging difficult timing issues if I'm the only one with a problem.
I've been able to reproduce it on occasion, but it's very erratic - sometimes it won't happen at all how ever many times I run up and down a slope, sometimes it happens the very first time. Normally doing a jump on-the-spot is enough to make it go away, and I've never seen it come back after that (doesn't mean that it won't).
I've built up a pretty good understanding of what I think are the top two or three most likely causes, but am unfortunately not any closer to pinning down the exact reason behind it, and even if I did, the irregular nature of it makes it difficult to test. "Was that just one of the times where it's not going to happen at all, or was that an actual fix?" It doesn't help that I've never found one spot in one map where it's guaranteed to always happen for both me and for the person reporting it either.
Forgot to add: I think that putting the time into understanding and solving this is worthwhile. There's some deep learning about things to be gained here. Until I do hit on the cause the best I can do is try stuff out and see what happens though. That might need to take a few releases in which it's not 100% definitively fixed too.
I had some trouble with necros' ne_ruins a while back (on an older version of DQ). Sinking into the ground halfway through the map.. it happened at different spots, but it did happen pretty much every time, hence I never got around to actually finishing that map.. (I have not tried with the latest DQ yet).
Btw, the classic case of getting stuck on a slope (transition from horizontal floor plane to 45-ish degree slope) would be in e1m1 (going down the slope near the exit).
A similar case in skull near the megahealth..
Mind you, the e1m1/skull case I'm talking about, is based on multi-player experience, which happens pretty much with any client.. fps/sys_ticrate-dependent I guess.
I recall it happening to me a few times (on different playthroughs) on the previous demo release of e2m1rq
I've encountered it with genuine, verifiable consistency in the retail release of the "third" Quake mission pack, Abyss of Pandemonium. Specifically try using the lightning charge weapon (not the thunderbolt) - zapping them with lightning makes enemy models bounce around, but killing them reliably causes them to clip through the floor and explode out of view.
I've never been able to repro it in e1m1 and I do a run of that map at least 5 times a week.
I'll try AoP later.
OK, rereading this, I tell a lie about e1m1 - I have seen that, and quite regularly.
I'm reasonably certain that it's a more general bug now than a DirectQ bug, as I've been able to reproduce it in an unmodified software Quake build.
That is however useful as it confirms for me that it's not the timing code, it's not the client/server separation, it's something else. Maybe these make it occur more frequently (and maybe they don't) but the key info is that it's something that was always there.
OK, just fixed it in software Quake. Here's what happens.
The engine somehow thinks you're going up a step in these places. Don't know why, but it does. There's a comment in the code about "limited precision in clipping hulls" which may be relevant here.
There is physics code to move you up and forward a little, then test if the move ended up on good ground afterwards. The move doesn't end on good ground, so it reverts to the original move without the step up.
Which is blocked.
Removing this last test fixes it, but that's not an option for release as it would involve a gameplay change - being able to hop up on some ledges/slopes you otherwise wouldn't (according to a comment in the code). I'm wary of special-casing the test too as it may have unwanted consequences.
The obvious real fix is to find out exactly why it thinks you're going up a step in these places, and stop it doing that.
Reproduced in TyrQuake too.
Possibly it's a problem with the compiler and the cutting it does, and the clipping hull generation?
Simply require a minimum step height of 1 qu before the entire routine is run, otherwise abort?
Interesting observations, mh.
I've played Quake quite a lot and never had this happening before. I've used mostly JoeQuake-gl/sw and WinQuake in order of decreasing playtime. All of those are limited to 72 fps and 72 hz. I have a feeling Joe (Jozsef) did something related to smoothness going up stairs in some release, maybe just interpolation related though.
For me it happens mostly on large/huge maps, and after playing a while. Other engines I've used wouldn't let you change game directory and play one huge map after another. So maybe it's also a bug that shows up after reaching some time or other limit, that you wouldn't with any other engine because other engines would crash earlier for other reasons (texture memory full or something, etc).
I'm pretty certain it's a clipping hull/physics problem, related somewhat to the physics bugs you normally get when you run at too high fps.
I've done further testing on the e1m1 spot, and dropping the physics update rate to about 40fps almost completely removes it.
I suspect that even the default max of 72fps is too high - I've suspected that before for other reasons.
Anyway, I got lucky and managed to get a game save in the e1m1 spot that infallibly reproduces it 100% of the time, so that's something I can work further with.
Been playing some single player lately and I noticed that after a couple of quick save/load's I get some random clipping errors.. seemingly getting stuck or bumping into invisible objects , often getting blocked by doors that have visually opened, but not clip-wise.
Happens both with 72 fps and 72+ fps (I usually play at 250). Think there might be a bug in the save/load mechanism or protocol related? (used 666)
Seen it happen now with both czg's and scampies new maps..
Oops, I failed to mention that after restarting the engine and reloading (quick load) the problem goes away (for the time being..)
Post a Comment