Chase camera fixes

[mh]

[mh]

[MauveBib]

[Baker]

[mh]

I think it might be...


_____________


I fixed dead bodies by changing the alias model bboxes (on the client side only) to be per-frame rather than a single bbox for the entire model.

This info is already loaded in Mod_LoadAliasFrame and Mod_LoadAliasGroup, so it's just a matter of (1) pre-scaling and translating it (change from a trivertx_t to a vec3_t also - lightnormalindex isn't used here, per modelgen.h); (2) retrieving the aliashdr_t from Mod_ExtraData if it's a mod_alias; and (3) using paliashdr->frames[e->frame]->bboxmin and paliashdr->frames[e->frame]->bboxmax instead of e->model->mins and e->model->maxs.

If you do this, and you've implemented the aliasbboxmins/aliasbboxmaxs fix, be sure to remove the scaling and translation from that.

Also watch out for the bug in stock ID code where it has "frame->bboxmax.v[i] = pdaliasframe->bboxmin.v[i];" - this should be "pdaliasframe->bboxmax.v[i]", of course.

[Baker]

[mh]

Another option that's occurred to me is that you could change the value of NUM_TESTS; 64 is OK I suppose for the defaults, but like you said if you increase them you'll lose a lot of granularity. Using something based on the distance between r_refdef.vieworg and the original chase_dest would be much better, then perhaps also adding a cvar to allow the user to control how granular they want it to be (say, 0 to 1 with 0 being a reversion to the default behaviour, 1 using the full scale, and points between using a partial scale). Allowing user control over this kind of behaviour is definitely a good thing, IMO.

The main thing I'm unhappy with is that first new for loop; it's a "late-out" loop, so in the majority of non-extreme cases it will run for most or all of it's iterations. Increasing the number of tests for smoother camera positioning could end up hurting a bit.

Using a coarser scale to establish an initial good point and bad point, then a finer scale to position more correctly between the two seems to be the way to go. I don't have my code with me right now, but I think the loop for the finer scale could be written as "early-out".

Another option would be to impose PVS restrictions on the chasecam positions.

The second loop is fine; it looks a little frightening - 6 checks per iteration! - but it will "early-out" in the vast majority of cases - one iteration most of the time, no more than 2 or 3 otherwise.

[Baker]

[mh]

Interesting...

With chase_back of 512 and chase_up of 256 it's incredibly jerky indeed. Changing NUM_TESTS to 1024 resolves that - very smooth. It seems obvious that distance-based is the way to go with this, so I'm gonna try that out and report back. I'll also try the initial coarse/then fine-tune method and see what happens. All code will be posted, of course, but be warned that it's my D3D engine and not GLQuake at this point; there won't be any rendering code (naturally) but there will be some minor C++isms.

[Baker]

[Baker]

[mh]

[Tomaz]

[scar3crow]

[mh]