   Integrating PhysX into my Engine......
  I'm sure this has been covered elsewhere, but my initial searches prove futile.Basically, i have an engine (meshes, transformations, cameras, lighting, particles, etc. ). We are still missing collision detection and 3d-Ray Picking (would it be useful to do 3d ray picking with physx?). I thought since we want to use the PhysX SDK anyways that those could be implemented using the SDK. But I have a couple of questions.feel free to call me an idiot and post a link explaining this stuff =).1) I see a TON of tutorials that come with the SDK which is great, but only one (and its not absolute to me) that really talks about integration like above. Is it really a matter of taking my mesh class and adding Actor* stuff to it? using the same vertices I use to render? And how will i translate my objects around without interfering with the physics translations?!2) My game has a space aspect to it, so I dont want to have gravity acting on everything the same, could i say, register a mesh with a certain scene each with different gravity?I also have a material class for my lighting.... I think it would make sense to define a metallic material with physics properties as well as lighting properties... does this make sense?   
Quote:Original post by AverageJoeSSU1)Is it really a matter of taking my mesh class and adding Actor* stuff to it? No, stop right there. Your graphics and physics should be entirely seperated.struct SpaceShip{  Graphics graph; //contains meshes and stuff  Phyiscs phys;   //contains your actor and stuff};Quote:using the same vertices I use to render? This is possible, if the vertices remain on your client side memory. If you've shipped them off to VBO's and deleted them from RAM then obviously this will not be possible. How ever your geometry is stored in the first place should be intelligent (at least with a shared_ptr) and generic enough to be shared by both your graphics and physics system.Quote:And how will i translate my objects around without interfering with the physics translations?!void SpaceShip::SetPosition(const Vector &p){  phys.SetPosition(p);    ApplyPhysicsPositionToGraphics();}void Spaceship::ApplyPhysicsPositionToGraphics(){ graph.Transform = phys.Transform;}Quote:2) My game has a space aspect to it, so I dont want to have gravity acting on everything the same, could i say, register a mesh with a certain scene each with different gravity?This depends on the physics library and how well you design your abstraction layer above it. Assuming that phyx allows either per world, or per scene, or per object gravity, then you will just need to expose this in your implementation. But typically this is easily supported, at one of the mentioned granularities.Quote:I also have a material class for my lighting.... I think it would make sense to define a metallic material with physics properties as well as lighting properties... does this make sense?You'll need to create a material table outside of your graphics engine, probably down in the physics engine. When you reference the geometry you'll need to do a lookup and choose a suitable material from this table from which to obtain your friction, and restitution coeficients.;  Dang.. that's super helpful.. thanks.Any idea about the picking? or should i just implement that on my own turf?;  The physics engine is a pretty optimal place to do picking. How ever, most of the time the collision geometry and graphical geometry is not 1 to 1 (Trees for instance, or any other complex shape). It's not always trivial to make compute this mapping between the picked collision face and the graphical collision face, should you need that information (ex: decals).But if all you need to do is pick at the object/collision goemetry layer, the physics engine is a perfectly suitable place.If you do happen to need the graphics face, then i believe the typical method is to find the point and normal of the pick intersection on the collision geometry, and project that point onto the geometry of the graphics. Imagine a ray shooting in both directions finding the first face with a similar normal. (slow as balls)   ;  Very cool... since its an RTS i dont really see the need for object face picking, since objects can be made of a a bunch of objects (like ship, laser turret, engine, all separate) i think just being able to pick at the object level is fine.This has been a very insightful post. Can't wait to get to work.I had an idea for stuff i want to do with this engine, enough of the technical stuff lets talk about COOL stuff haha jk. I thought a plasma-napalm like weapon that sprays on ships and melts the surface would be cool, kind of a tearing like effect on the geometry with physics liquid as the weapon. And prolly what i want the absolute most, is CRAZY explosions. I already have HDR in place with deferred rendering, so lighting is taken care of. But I want objects to split and explode dynamically, and even crash land into other stuff.Those are the two unique-ish things i want to do, hopefully i'll be able to do them.   ;  Sounds like fun, good luck!   ;  I recently saw a post that has caused me to come back.A guy asked if it was possible to sync a physics mesh with a graphics mesh.... for example... if a geometry is torn (like cloth), or a softbody is altered... is there a way to sync the mesh generated by PhysX and used in graphics by the GPU? or are these separate and only can be synced by the CPU.I use a VBO created from a Mesh* . Is this trivial? creating a new mesh everytime physx alters the mesh? his question was more driven towards extracting particles for rendering.   