Container cone?
by Andrew Wiblemo · in Torque Game Engine · 02/01/2008 (8:57 pm) · 4 replies
Ok, so being rather new to TGE I'm somewhat lost and in need of helps.
Is there a cone implementation of containerFind somewhere, or some other way I could add continuous target checking to a guided projectile?
What I want to do, is when a guided projectile is fired, every quarter second it would do a new check based on a cone viewing arc, and reacquire the closest valid target (eventually adding in an EM signature, to weight the validity of targets, like distance/signature = strength and target strongest). This way, if a new target crosses the projectile's path, the target fires off chaff, or the target successfully evades the hit, the projectile will change targets accordingly, possibly to null.
If I can't get that in code I'd atleast like to be able to allow players firing a missile launcher to be able to target without having to be dead on the model when ::onFire is called.
Is there a cone implementation of containerFind somewhere, or some other way I could add continuous target checking to a guided projectile?
What I want to do, is when a guided projectile is fired, every quarter second it would do a new check based on a cone viewing arc, and reacquire the closest valid target (eventually adding in an EM signature, to weight the validity of targets, like distance/signature = strength and target strongest). This way, if a new target crosses the projectile's path, the target fires off chaff, or the target successfully evades the hit, the projectile will change targets accordingly, possibly to null.
If I can't get that in code I'd atleast like to be able to allow players firing a missile launcher to be able to target without having to be dead on the model when ::onFire is called.
About the author
#2
then as Stefan says do some math on them using dot products to see if they're within a viewcone.
some convenient math for doing radial & angular proximity can be found here.
if you wanted to get really fancy i guess you could go into the engine and write a containerConeSearch which would only look at bins falling inside the cone, but that would probably be a fair bit of work.
02/02/2008 (10:42 am)
The simplest thing would be to do a containerRadiusSearch to first get all the objects in minimum distance,then as Stefan says do some math on them using dot products to see if they're within a viewcone.
some convenient math for doing radial & angular proximity can be found here.
if you wanted to get really fancy i guess you could go into the engine and write a containerConeSearch which would only look at bins falling inside the cone, but that would probably be a fair bit of work.
#3
What I was thinking was a container box search, with dimensions that would encompass the entire cone I'm trying to search in, either rotated or not. This would cut the search area and possible target returns down tremendously, but I lake the coding experience to attempt as of yet.
The only other way I can think of would be to create a cone object with the correct dimensions, angle, and location, check collisions against it real quick, then delete it before it has a chance to cause any issues. I have no clue if this would even work.
Quick question, what's faster. Casting ray for LOS, or doing the dotproduct? Guessing dotproduct, but I gotta make sure.
02/03/2008 (10:25 am)
I thought about radius search then finding the angle (didn't know it was a dotproduct, I know little vector math), but it seems extremely inefficient to me. I'll probably do this to start then attempt a better method later.What I was thinking was a container box search, with dimensions that would encompass the entire cone I'm trying to search in, either rotated or not. This would cut the search area and possible target returns down tremendously, but I lake the coding experience to attempt as of yet.
The only other way I can think of would be to create a cone object with the correct dimensions, angle, and location, check collisions against it real quick, then delete it before it has a chance to cause any issues. I have no clue if this would even work.
Quick question, what's faster. Casting ray for LOS, or doing the dotproduct? Guessing dotproduct, but I gotta make sure.
#4
you're definitely thinking smartly about optimization,
but in this case i would recommend just getting it working w/ simple tools,
so that you can focus on gameplay, and optimizing later if/when you need to.
again i'd recommend good old container radius search (note it's already fairly well optimized in TGE, thanks to the spacial bin system) and then using those math utilities to determine field-of-view, and then if you want to be super accurate, doing a raycast against the remaining candidate objects.
you are correct, raycast is worlds more expensive than simple dot-product stuff,
and also raycast itself doesn't really help you determine field-of-view.
a conic field-of-view calculation is just a handful of vector operations, one of which is the humble dot product.
02/03/2008 (10:52 am)
Andrew,you're definitely thinking smartly about optimization,
but in this case i would recommend just getting it working w/ simple tools,
so that you can focus on gameplay, and optimizing later if/when you need to.
again i'd recommend good old container radius search (note it's already fairly well optimized in TGE, thanks to the spacial bin system) and then using those math utilities to determine field-of-view, and then if you want to be super accurate, doing a raycast against the remaining candidate objects.
you are correct, raycast is worlds more expensive than simple dot-product stuff,
and also raycast itself doesn't really help you determine field-of-view.
a conic field-of-view calculation is just a handful of vector operations, one of which is the humble dot product.
Torque Owner Stefan Lundmark