Hey guys what's happenin, nothing like coding video games on a Friday night.

Anyways So I'm to a point where I want my missile to behave like a missile when it collides with something. Right now it's collision hull is a rectangle so usually when it's head hits the ground it'll end up standing up side down (which is what I'd expect a rectangle to do).

What I'd like to do is use the AddPointCloud method of the physics simulator (which I don't think is currently used in GCC4), however it needs a list of vertices. Do I have to hard-code this list or should I pull it from the vertex buffer? Is there a better / easier way to go about this?

(The missile model has 1392 vertices)

Thanks!

Hey man thanks for the reply.

I'm kind of taking things step by step so I didn't think about how that many vertices would affect the performance of the engine but you're absolutely right that would never work in the long run.

Both of your ideas are good ones, I just took a look and Bullet supports a capsule shape natively which should work pretty well for a missile. Storing point cloud vertices in an XML file sounds like a good approach for the long haul so I'll definitely look into implementing that down the road (though it sounds pretty tedious to have to first create the model using a tool like Blender, then manually figure out the point cloud vertices and have to change them if / when the model changes. Oh well, guess that's what designers are for huh?)

I did have one more thought, have you ever experienced a design in which point clouds were never used but instead the model's collision hull was made up of several collision hulls? For example, a capsule doesn't perfectly fit a missile because the bottom of the missile is flat, but combining a capsule with a box on the bottom where the capsule and box overlap would work perfect...

If this sounds like it might be a good approach, what would be the best way to fit it into the GCC4 architecture? Maybe we create an abstraction for the collision hull shape that wraps bullet's shape, then the PhysicsComponent takes an array of these abstractions as opposed to a single one??

Thanks for the feedback!

Hey guys another question on collisions, this time in regards to handling them.

Right now I have an actor that shoots a missile in an arc, so I set it's animation component to an implementation that SLERPs the rotation of the missile over time so that it starts pointing positive 45 degress from the horizontal and ends pointing negative 45 degrees from the horizontal.

Start: /

End: \

(Note this isn't the actual movement of the missile across the screen as that is handled else where, this is just the rotation of the missile itself.)

Anyways, if it collides with something I want the animation to stop so initially I had setup an event listener in the Missile object who would then compare ActorIds and if it found that it was itself that collided, it would essentially kill it's own animation component. However at this point (probably for obvious reasons) I'm thinking this is not ideal and want to re-factor...

I'm thinking another possible approach would be a single event listener in the GameLogic who pulls the actors that collided, then executes some kind of ICollisionHandlerComponent abstraction if the actor has one in it's components collection and does nothing otherwise.

Do you guys have any opinions on which approach is better? Or perhaps ideas on a more flexible approach?

Thanks!