Page 2 of 2

Posted: Sun Jan 16, 2011 4:33 pm
by Rich
Oh man, that thing. No one should ever use that. Just don't. I was retarded when I wrote it.

Cost of per-triangle collision on stock Quake models is completely trivial even without any kind of tree, and would run just fine on a PSP, if done right. You need to use a proper world space inverse matrix to transform to local model space instead of the insanity that's used in that tutorial, and the actual ray-triangle collision can be sped up drastically.

Posted: Sun Jan 16, 2011 10:20 pm
by Mexicouger
Well that would be helpful, Beings that everyone wants to make vehicles, But doesn't realize that the thing holding em back is world collision.

Posted: Tue Jan 18, 2011 12:54 pm
by Team Xlink
Mexicouger wrote:Well that would be helpful, Beings that everyone wants to make vehicles, But doesn't realize that the thing holding em back is world collision.
The amazing, Cubic Combat, by Electro, features vehicles, that work rather well, without per-poly collision problems.

http://www.youtube.com/watch?v=7JmktJKaQ4A

Posted: Wed Jan 19, 2011 9:13 am
by metalmodman
Team Xlink wrote: The amazing, Cubic Combat, by Electro, features vehicles, that work rather well, without per-poly collision problems.

http://www.youtube.com/watch?v=7JmktJKaQ4A
lol That's cool.
Rich wrote:Oh man, that thing. No one should ever use that. Just don't. I was retarded when I wrote it.
erm.. :roll: don't be so hard on your self.
Rich wrote:Cost of per-triangle collision on stock Quake models is completely trivial even without any kind of tree, and would run just fine on a PSP, if done right. You need to use a proper world space inverse matrix to transform to local model space instead of the insanity that's used in that tutorial, and the actual ray-triangle collision can be sped up drastically.
lol sorry you don't have to reply, just curious. I'm guessing its loading the model information from the video card to the memory and your saying it would be faster to just load it to the system memory?

Posted: Wed Jan 19, 2011 10:19 am
by Sajt
metalmodman wrote:
Rich wrote:Oh man, that thing. No one should ever use that. Just don't. I was retarded when I wrote it.
erm.. :roll: don't be so hard on your self.
No, he has EVERY right to be so hard on himself! The code is terrible. It transforms every vertex individually into worldspace (actually multiple times for most vertices) for every traceline. Whereas all you actually have to do is, like he said here, inverse-transform the trace line segment once, then you don't have to transform any of the vertices at all. (And his R_TransformPoint function is actually WAY more expensive that it needs to be!) So you go from potentially thousands of transform routines, to just one. I would say it's significant! Anyway, everybody learns about matrices at some point... :)

The bottom line is that even if you're tracing against a standard low-poly Quake model, a proper per-poly trace routine would be literally THOUSANDS of times faster than the code in that textfile. For high-poly models it's even more significant.

Posted: Thu Jan 20, 2011 11:35 pm
by Rich
No, he has EVERY right to be so hard on himself! The code is terrible. It transforms every vertex individually into worldspace (actually multiple times for most vertices) for every traceline. Whereas all you actually have to do is, like he said here, inverse-transform the trace line segment once, then you don't have to transform any of the vertices at all. (And his R_TransformPoint function is actually WAY more expensive that it needs to be!) So you go from potentially thousands of transform routines, to just one. I would say it's significant! Anyway, everybody learns about matrices at some point... Smile

The bottom line is that even if you're tracing against a standard low-poly Quake model, a proper per-poly trace routine would be literally THOUSANDS of times faster than the code in that textfile. For high-poly models it's even more significant.
Yes, that. Typically you would also want to pre-calculate your triangle planes, though this is not so much a good idea with collision against vertex-animated models, and it's worthless if you want to collide on the client against interpolated vertices.

However, what Sajt says doesn't even cover all of the problems with it. The actual sidedness check is unoptimized, as is the plane calculation. (you would not want to copy this model even if you did make the obvious change to transform the start/end to modelspace) I was actually aware that I was doing that wrong when I wrote it, but I just didn't give a shit because it still ran "okay" and I didn't want to get into matrix math because I was still mildly retarded. I never considered that people would actually be using it, I suppose, and in fact didn't even release it until I found it in an archived folder years after the fact and thought "Oh, cute, I should stick these on my web site for the hell of it." In all fairness, though, my web site also cautions against using any of the tutorials there and directly calls them crappy and poorly-done. So, as advertised.