|
I need to find out where a particle collided on the collider. I've been googling for over and hour now and haven't found anything yet. Basically, I can't use a raycast technique because the 'bullets' I'm firing aren't moving very fast. I'd like to spawn an explosion where the particle collided. It seems from what I've read that such a thing is impossible to tell. This is odd because obviously the particles can reflect off of a collider, but it doesn't seem that the position information can be passed through OnParticleCollision. Also, I don't think particles can set off OnCollisionEnter (tests have shown this to be the case) so I cannot get any collision information. This seems like such a simple thing to implement. If I can't get this information from the OnParticleCollision event, I may consider creating two dimensional meshes with box colliders, but this seems like a huge waste of CPU resources. Any ideas anyone?
(comments are locked)
|
|
We are actively working on collision messaging ATM and with any luck it should go into Unity 4.2. This will let you read collision impact points, incident velocity etc. With this data you can easily cause damage and/or apply forces to collidees. Sounds good. And can I just say (to an apparent Unity employee) that the new Cursor class is a god send :D
Mar 07 at 02:57 PM
Khada
(comments are locked)
|
|
What you probably want to do is make your "bullets" a gameobject with a rigidbody, and attach your particles to that. That way you can do normal collision detection, etc. You'll have to do movement of that object yourself, though. Hmm.. I don't know how to tag code but: http://unity3d.com/support/documentation/ScriptReference/MonoBehaviour.OnParticleCollision.html Shows an example using the 'transform.position' of the particle to create an impact force. However, when I attempt to mark this position with an explosion it occurs to the relative left of the emitter a little ways out (~30m). Odd..
Jun 27 '10 at 06:44 AM
MattA
Well I see now what that code was trying to do. I fixed my emitters so that they were in the same space I was using the Emit() function from. Now the explosions happen right at the emitter. This means the code was using the emitter position to calculate the direction to the target in order to add velocity. However, for slow moving bullets, the trajectory will be calculated from where the emitter currently is when the projectile impacts. So a bit of a dead end..
Jun 27 '10 at 07:23 AM
MattA
(comments are locked)
|
|
Ok, well I figured out how I can do it. Kinda hacky though, I hate that... Basically, each emitter object will have a script with an array of 'trackers' that track each of the emitted particles positions, velocity, and lifespan. Since I'm emitting the particles manually with a set direction, velocity, and energy, I can just use that information (provided there aren't any weird sync issues) to see where each particle is and then raytrace for a collision each frame. If one of the 'trackers' senses an impending collision, it can spawn an explosion at that spot. It shouldn't matter than the trackers don't know which particle they're tracking since the particle will delete itself upon collision, I just need to be pretty sure that particle will hit. Essentially it's just an invisible parallel particle system. Ugh, this is really hacky, if I don't dream of a better solution tonight I'll try it out tomorrow. Your array of 'trackers' sounds like the ParticleEmitter.Particles array - if it isn't, you might use this instead of storing a new one. The docs say OnParticleCollision and the messaging system add lots of overhead anyways. To avoid sync issues, you could set the framerate to be fixed or consider separate threads or coroutines which sleep/yield for some interval between raycasts, making the system framerate independent and maybe reduce the number of casts. You could even calculate close to a hit the exact interval so that the hits happen as close as possible to when they should.
Jun 30 '10 at 03:43 PM
skovacs1
Here's something I tried and it seems to work OK for collisions with the environment (e.g. blood splash). Use the particle world collider but don't process the OnParticleCollision, instead set the particle bounce to zero. Use the lateUpdate function on the particle emitter to iterate through the particles array of the emitter. If a particle's x-y velocity falls to zero, record the particle position, instantiate the splash at that position, then set the particle's, energy to -1. The trick is to let the collider stop the particle and examine the particles array for stopped particles.
Dec 11 '12 at 08:39 AM
Murpheus
(comments are locked)
|
