per polygon hit detection tutorial?

I think I remember some one posting a link to a per polygon hit detection tutorial for quake one, but I cant find it. Does any one know what I'm talking about?

I think I remember some one posting a link to a per polygon hit detection tutorial for quake one, but I cant find it. Does any one know what I'm talking about?

http://www.telefragged.com/thefatal/q_t ... lision.txt

O.o DOES THIS WORK WITH PSP?

Thank you Team Xlink!

When my coding improves I'm going to try to get this working on dedicated servers and try to do some thing like doom for head shots.

O.o DOES THIS WORK WITH PSP?

Try it, with some changes it should work, heck it might not even need changes for all I know.

O.o DOES THIS WORK WITH PSP?

From what I remember from this tutorial, it should work with little if any modification.

strange. Aplied it. Fixed some small errors (i think) and it complied fine. But ingame it just crashes the game without errors etc :/

strange. Aplied it. Fixed some small errors (i think) and it complied fine. But ingame it just crashes the game without errors etc :/

What engine are you using?

I still haven't started on it yet. I'm guessing its meant for GLQuake? I need to install XP or linux.

polygon hit detection is too expensive to process
psp is too suck for it anyway

How expensive? I figured if you could play the game in software mode then this should be no problem? I guess it would be a problem in multiplayer.

Damn, still would be nice to play with. Much easier then me trying to learn skeletal animation and setting up hit boxes. I'm still new at this.

From what I've seen in the tutorial, it should be easy to make it work only on some entities, which should reduce its processing requirements.

Another optimization would be to not use it on entities hit by tracelines that exceeds a certain distance, so entities that are far away would be processed through the regular hit detection instead.

And there's a kind of bug in that tutorial: It only applies the per-poly detection after the bounding box detection has been done, so if the bounding box is smaller than the model, some parts of the model will never collide against the tracelines anyway.

Whaaat! Then it shouldn't have any problem processing hit detection at all then right?

I'm guessing is the same box used for level collision, so I couldn't just make it bigger? and I bet it's in assembly. lol Oh well it's still cool.

Yeah, and a solution would be to use the box generated from the interpolation of the boxes of the model's frames, the same that's used for the rendering. But I bet the static hull sizes would get in the way.

By the way, another optimization would be to use a simplified model for the per-poly collision, like the simplified model we've made for the characters' shadows in Fightoon. Combined with the optimizations I've mentioned before, this could make the per-poly collision quite lightweight.

ah that would be cool.


Some thing like this right?


It would be great to get this working and all done server side so it doesn't change the clients requirements.

Yes, that kind of model.

Physics are always processed server-side, so clients shouldn't be affected by it anyway - even without optimizations.