Thanks for the pointers!
Yeh I was going to try ActorIterator just to see what would happen. Out of interest, why use DistSquared instead of Distance? Doesn’t that just add to the complexity without giving any change to the behaviour? No idea why I used GetSafeNormal on the Forward vector, that was a boo boo on my part. You might be right about the distance/cone culling too, though I haven’t tested that yet. I did make the distance smaller (15K) since.
The test was with only two of the actor components in the world to test against. I think I might be being limited by the drawing of the missiles at this stage rather than the simulation, though I’m not sure about that, will find out in a second.
The ordnance can’t collide with each other, and they ignore the collision channel (at least, they should anyway). The collision check for the ordnance is just a small sphere primitive, setup the same way UT/Shootergame’s is. I’ll have to dig into the profiler now to figure out if the Physics engine is still testing overlaps for the projectiles.
EDIT:
The main costs appear to come from two things, I get a big spike when both Spawning and Destroying the actors, but the actual code itself seems to add less than 2ms of processing time when it has something to lock onto. I’m spawning 250 of them at once. Staggering the spawning reduces the spike when spawning, but increases the overall processing time since they’re not processing the UpdateTarget() function over one frame, it’s spread out across lots of frames.
The spawning might still be related to the overlapping however (the spike is certainly bigger than destruction), since the code checks on overlap if the overlap is the instigator or not.