|
1 registered members (AndrewAMD),
1,298
guests, and 2
spiders. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: collision hull
#8691
04/25/02 03:11
04/25/02 03:11
|
Anonymous
OP
Unregistered
|
Anonymous
OP
Unregistered
|
quote:
a) Trace is a very slow command. For a simple scene, what you describe may be fine. But if there are a decent number of entities to track, doing a trace like that for every entity every frame, buh-bye framerate.
The docs say nothing about trace being slow, they only mention that scan is slow. Trace should be no slower than ent_move - and is probably actually a little faster because it doesn't have to compute for glide or push values. I would guess that trace and ent_move actually use much of the same code. (One question I have though is when a trace determines whether it runs into a entity, does it use that entities bounding box or hull to make that determination?)
quote:
b) While I'm doing my custom collision detection, the built in collision detection would still be taking place! Thus, it's doing all the collision detection calculations TWICE for every entity. Talk about a waste
A very valid point I had not considered, but which can be ignored 99% of the time in the typical scenario. In most cases collision detections return false. With that in mind, if your trace returns false (e.g., no collision is detected from the trace) simply do a vec_add (my.x, trace_vector.x); - you already know there isn't going to be a collision so you can relocate your object without following the whole path again, so no second collision detection is needed. In the 1% of cases where you do actually get a collision from your trace then go ahead and do your ent_move and take the performance hit for that small percentage of cases. This is of course a general scenario and will need to be adapted to your specific level - maybe you have so many objects and entities that you are getting collisions at a much higher rate, and then this definately would not work.
quote:
Note also that the undocumented feature is nothing like what you describe. The undocumented feature seems to be just like collision detection with collision hulls, except that each entity has it's own sized "hull" (its bounding box.)
As I understand using trace with the use_box flag, this is essentially what the undocumented features is doing (though from a slightly different approach). e.g., with trace, tell me the distance between my entity origin to a given object, then adjust it according to the entities bounding box (just like the 6 day tutorial talks about when adjusting so that the feet of the entity are above the ground, and not the entities origin is just barely above the ground). In other words, trace with use_box is tell me if my bounding box is going to collide with anything if I move along this vector. A negative return value from trace means I am already on top of something. If move_mode had a use_box flag it should be indentical to what the undocumented feature is doing.
Other random thoughts (as if you cared =p).
There is a problem with the trace method in that you need a way to determine if a return value of 0 on the trace is because you are right next to the object or because there is indeed no actual collision. In my test code I actually never let the objects quite touch, but always back the object off by a distance of 0.001.
I'm not sure why scan is supposedly extremely slow compared to normal collision detection. Yes I would expect it to be slower, but not significantly so. Scan should (at least I think it should work like this):
a) determine if the two objects are close enough for their to be a possible detection with scan - if not go to next object (which is what a trace or move_ent is probably already doing)
b) if they are close enough then determine if object2 is in the angle specified in the scan in relation to object1 (which trace and ent_move are already doing - though they do it for a single angle, that angle being the intended direction of movement - whereas scan would have to check if it is within the angle bounds - resulting in a 'slightly' slower performance).
And of course the whole thing would be a mute point if they would just make collision detection consistant and use bounding boxes all the time anyway (or give the user the option of specifying the collsion detection system to use either on a case by case basis or for the whole level - which is sort of what they are doing with the use_box flag on the trace). I want a use_box flag for my move_mode......... anyway, I hope the feature works for you as it would certainly be cleaner than my current solution. It seems I am forever doomed to find workarounds for the limitations of the software tools that I use - even when I am the original author of the tool ![[Big Grin]](images/icons/grin.gif)
|
|
|
Re: collision hull
#8692
04/25/02 03:53
04/25/02 03:53
|
Anonymous
OP
Unregistered
|
Anonymous
OP
Unregistered
|
quote:
Originally posted by fanatic:
The docs say nothing about trace being slow, they only mention that scan is slow
Actually, the manual says trace is slow in one place, and not the description for the trace command (doh!) It says so in the section on AI, at the top of the table of "states."
I forgot about the use_box parameter. This issue requires more thought... At any rate, it's not a mission critical thing for my current project. Mostly I found the two collision hulls thing really annoying.
|
|
|
Re: collision hull
#8694
04/26/02 02:04
04/26/02 02:04
|
Anonymous
OP
Unregistered
|
Anonymous
OP
Unregistered
|
Actually, it ocurred to me I could avoid the two collision checks thing entirely by not using ent_move to move the model. Instead, manipulate the models X,Y,Z coordinates directly.
Like I said though, not that important to me right now. I mostly wanted to know if a) I was mistaken about there being only two sizes of collision hull and b) that this issue is known and will be addressed in future versions of 3D Gamestudio.
|
|
|
|
