Collision Detection vs. LOS

#1 Bit of a loaded question, they are different is all.
But in terms of CPU cycles a raycast to determine if an object is in LOS is going to be easier and faster for the CPU, than randomly trying to determine if you are colliding against an object.
Collision is easier as a coder, since most objects will automatically throw an event when collision occurs.

#2 The reason I'm asking this question, is because I'm wondering if it's possible or even a good idea to use collision detection for NPC's in an MMORPG. Meaning, instead of using LOS, or predetermined paths, the NPC uses collision detection to navigate the map. You may be picturing NPC's blindly bumping around the map, but that wouldn't be the case at all. I know I asked kind of a a broad question, but does this help clarify what I'm asking?

#3 If you use collision detection you will have NPCs blindly bumping around. I know because I wrote the MMORPG Enhancement Kit :)
For exterior environments, you can safely use a collision event based system, when they hit a tree or what not they can bounce or run in a different direction etc.
For interiors such as dungeons a system of path nodes and good regression algorithm is required.
In the MMORPG Enhancement Kit for TGE we use a precompiled A* pathfinding system in close quarters, that provides a nice balance of light CPU usage and high accuracy.
For more information you can visit our website

#4 Well if you're using torque, and you can use collision for map navigation you might as well do that since collision is always being processed anyway. LOS would only add to the amount of processing the CPU needs to do. although, if youre using torque i dont see how you could use collision for navigating a map without bumping into walls.

#5 Oops, didn't look before and see that this is a public forum, was about to explain some code :)
BTW do you own a copy of TGE yet?

#6 No I don't own a copy of TGE, although I'm very seriously considering it. Which is exactly why I'm asking these questions. I'm exploring TGE's potential.

Which brings me to another question: Is TSE going to be available for Macs? ...Soon, not so soon, ever?


"Although, if youre using torque i dont see how you could use collision for navigating a map without bumping into walls."

I can. ;)

#7 If you can I'ld love an explaination since thats something I've been trying to accomplish for quite awhile :)

#8 One more question, if I made a game using TGE, how easily could I switch my game from TGE to TSE?

#9 Depends on the game.

#10 Yeah ethan, how exactly would collision come into play unless some kind of collision was occuring between the NPC and the wall he's trying to avoid? Unless you cast a ray from the NPC, and had it turn when it was X distance from the wall, the NPC would slam blindly into the wall, and then do it's onCollision(). The only other way I can think of it by making the collision mesh waaaay too big, and that would cause other obvious problems.

#11 @ Woodman: It sounds like you are challenging me... Ready to gloat when my idea doesn't work. I admitted at the beginning of this thread that I was not a very experienced programmer, so my idea could very easily not work. Which is EXACTLY why I'm asking these questions. So please don't flame me. Although I honestly don't see why it wouldn't work.

@ Dreamer:

The concept is very simple. NPC's would do ZERO collision detecting. You would parent an invisible sphere to the NPC. Similar to the way you parent a weapon or a flag to the NPC.

The sphere would do ALL of the collision detecting. You would only have make the sphere big enough to give the NPC time to react to objects.

One of the main reasons I like this method is because the sphere can detect collisions with bullets (arrows in my case) that come near but don't hit an NPC. Allowing NPC's to react to being shot at. Which is very realistic. =)

This idea is just one of many that I have come up with for a game that I have been designing for several years now.
Does it work? Yes? No? I'm just as curious as you.

#12 Would be simpler to 2x the collision mesh in the y coordinate (at least I think it's y.
Your still blindly slamming into stuff, your just slamming into stuff from further away :)

#13 You don't have to have the NPC react immediately, you could randomize a time delay before it turned from the object. That way it wouldn't appear to be reacting (as much) to the object. And with cleverly placed objects, you could "guide" the NPC. But yeah, it's still essentially bumping into stuff i guess. =P

#14 Whoa there, I was not in any way trying to challenge you Ethan. I was simply trying to tell you what problems I saw with your idea, and offered some help. What you just posted is exactly what I meant by making the collision mesh too big though. What that "invisible sphere" you have surrounding your player is, is a collision mesh. When you go to export your model from your 3D app (it looks like your using blender there), you will realize that you need two things: the actual player, and a collision mesh (actually, the model in that picture you posted looks almost ready to go, except for the empties). The player will show, the collision mesh will not. The collision mesh will collide with things, the player will not.
Now thats fine the way you have it, but the sphere is far too big. Your NPC will run into characters that are 5 feet away from him, and he will never get through a doorway. This is why I reccomended raycasting (LOS). This method will allow you to see a wall/object, but you can still have your character run into the wall/go through a doorway if needed.

I know that your idea involved a sphere that wasn't really a collision mesh, but simply acted as a "sensor" to detect if you are within a certain range of something. This is possible, but your sphere would have to be a seperate model, and you would need to write the code to detect it's collision.

For the record though, I have never "flamed" anyone on this forum, and I'm not about to start now, So i'm sorry if I sounded rude, I honestly did not intend to.

#15 Just so you know, only static objects need a baked in collision mesh
Players and etc, have their collision mesh dynamically defined at runtime, just don't forget to add skis :)
That said you can dynamically scale the collision mesh on any axis. I think the facing axis is either x or z (possibly y I'm a bit rusty here). So if you scaled only on the single axis, you would avoid the "fat player" syndrome where not only is he bumping into walls he's running into, but he feels to fat to fit through narrow corridors.

Regards,
Dreamer

#16 @Dreamer: I honestly did not know that, I have always added a collision mesh to my players, as all of the exporter tutorials seem to indicate that you need to create the "Collision" empty and then parent the collision mesh to it.
But in that case, where is the collsion mesh constrained to? when the player is dropped into the world, does the mesh cover the player as tightly as it can at it's first frame of animation? or is the collision mesh dynamic enough to conform to the player's shape during all frames?

#17 It's a box, it changes size to fit the current state of the player. The only exception is if you go prostrate i.e. Swim or crawl, in that case the collision mesh does not update, however the Swimming Tutorial has a fix for that as well.
Regards,
Dreamer

#18 @ Woodman: Thanks for the advice. And thanks for letting me know you didn't intend to be rude. I'm sorry if I got a little too defensive.

#19 @Dreamer: wow, thats great to know! I guess I'll go delete the collision meshes from my characters now and give it a test.

@Ethan: no problem, I probably would have done the same thing :)

#20 Ethan your theory sounds fine but im not so sure it would work for the torque engine. as far as player objects go, theres no such thing as a bounding sphere. like dreamer said, player objects use a bounding box defined in the datablock. other types of objects like staticshape and vehicle can have custom-built collision meshes. however, even if you used a vehicle for your player or mounted a static to your player and used that for your collision detection, you definitely would not want to use a sphere as a collision mesh. if you want to know about cpu usage, it would probably take more time for the cpu to do collision for that sphere than box collision and los combined. dont use a round sphere use some kind of simple polyhedron.