IrrPhysx 0.2 - Nvidia Physx 2.8.1 wrapper
Right, I've now got the nvidia PhysX sdk. After a quick look I believe it should be simple enough to get basic fluids, vehicles and character controllers implemented in IrrPhysX.
I'll start off with fluids and make a simple demo...
I'll start off with fluids and make a simple demo...
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
-
- Posts: 368
- Joined: Tue Aug 21, 2007 1:43 am
- Location: The Middle of Nowhere
First demo will use little particle objects for each "drop", as seen in the PhysX SDK samples. Let's get it working first before adding eye candy.Carama wrote:look at the board i think sb made allready metaballs
A naive metaball implementation is useless for this kind of fluid volume. I'll have up to 60000 fluid particles (as per the nVidia fluid PhysX demo). I know how I need to implement it - there are technical papers on the net - but we'll cross that bridge when we get to it.
I've just found out about Irrlicht 1.5 so I'm looking at that now for any added texture format/shader goodness.
Isn't that cloth tearable?
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
OK, I built IrrPhysX with Irrlicht 1.5 (only issue was to add a couple of vertex-index-type parameters to a couple of calls).
Built the GameExample. Camera moves like lightning, so altered its move speed to 0.5f (the 1.5 readme explains the camera change).
But, I now have a problem: the shack is oriented incorrectly. It looks to be rotated 180 degrees around Y - the shack door is "around the other side".
Built the GameExample. Camera moves like lightning, so altered its move speed to 0.5f (the 1.5 readme explains the camera change).
But, I now have a problem: the shack is oriented incorrectly. It looks to be rotated 180 degrees around Y - the shack door is "around the other side".
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
well I had exactly the same problem when compiling for 1.5.. and also when compiling the game demo I found the debug data "V" key, ie. the collision mesh was not alligned with the real displayed mesh... something must be wrong withzillion42 wrote: btw.
the svn version of irrlicht uses 7 arguments for drawVertexPrimitiveList, the last one is irr::video::E_INDEX_TYPE so I changed CDebugRenderer.cpp in line 78 from:toCode: Select all
if (indexIndex >= 65530) { // 66536 index limit so before we reach it fire off a render and reset to zero driver->drawVertexPrimitiveList(pVertList, vertIndex, pIndexList, indexIndex / 2, video::EVT_STANDARD, scene::EPT_LINES); indexIndex = 0; vertIndex = 0; }
Code: Select all
if (indexIndex >= 65530) { // 66536 index limit so before we reach it fire off a render and reset to zero driver->drawVertexPrimitiveList(pVertList, vertIndex, pIndexList, indexIndex / 2, video::EVT_STANDARD, scene::EPT_LINES, irr::video::E_INDEX_TYPE::EIT_16BIT); indexIndex = 0; vertIndex = 0; }
Code: Select all
// Walk the scene graph and create Physx objects for each node of interest
readScene(physxManager, device, objects);
rotated 180, but when walking the charater sunk into the terrain...
added...
the flag post in the game demo seemed to behave normally though, no problems with that... when shooting the flag I was even able to tear the cloth... looked good
Well, it seems something's truly busted in Irrlicht 1.5. If I alter the Irrlicht 1.4.2 LoadIrrFile SDK sample to load JP's IrrEdit file (scene.irr) it loads just fine. If I alter 1.5's LoadIrrFile sample to load JP's scene it looks different.
Purely a guess at the moment, but the physics meshes seem OK - just the render meshes. This suggests it's the internal IrrEdit scene loading that's the issue, as physics meshes are loaded individually in a separate pass of the scene.
I've read through the 1.5 changelist and didn't notice any IrrEdit-loader breaking changes, though there are a lot of changes in 1.5 so I may have missed something.
OK, I'm off to study the 1.5 changelist doc. Guess I'll have to debug it though...
Purely a guess at the moment, but the physics meshes seem OK - just the render meshes. This suggests it's the internal IrrEdit scene loading that's the issue, as physics meshes are loaded individually in a separate pass of the scene.
I've read through the 1.5 changelist and didn't notice any IrrEdit-loader breaking changes, though there are a lot of changes in 1.5 so I may have missed something.
OK, I'm off to study the 1.5 changelist doc. Guess I'll have to debug it though...
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
Did any of you manage to compile IrrPhysX with GCC/MinGW.
I modified a bit NVidia PhysX files to compile properly when IrrPhysX include them (by changing __in64 to long long, removing some #ifdef'd _asm code etc.) but I stuck at the linking of IrrPhysX DLL.
Here's error:
Any ideas for this? I added to the linker all three libraries from PhysX, so that's not the problem.
If I try to link a static library, the error is with "irrAllocator.h.text+0x0" as already mentioned before... No ideas here either.
I modified a bit NVidia PhysX files to compile properly when IrrPhysX include them (by changing __in64 to long long, removing some #ifdef'd _asm code etc.) but I stuck at the linking of IrrPhysX DLL.
Here's error:
Code: Select all
Linking dynamic library: IrrPhysX.dll
Creating library file: libIrrPhysX.a
Cannot export PhysXLoader_NULL_THUNK_DATA: symbol not found
collect2: ld returned 1 exit status
If I try to link a static library, the error is with "irrAllocator.h.text+0x0" as already mentioned before... No ideas here either.
i think if you add more flags and use my readScene method then it may not work for tearable flags... it may be using the same physx cloth mesh and that could cause problems as they're gonna be using the same memory and they shouldn't, i think the cloth example explains this and shows that you should have a new physx cloth mesh for each tearable mesh.
with the 1.5 change.. maybe the model loaders were updated to fix something or other and that's undone something i may have done to fix some orientation problems...
with the 1.5 change.. maybe the model loaders were updated to fix something or other and that's undone something i may have done to fix some orientation problems...
OK, I'm working on the fluid addition right now. A simple demo will come first (but will probably have tons of fluid particles and require HW acceleration via an Ageia card or nvdia GPU).
I spent some time with the PhysX SDK to plan out implementation of fluid, character controller, ragdolls and vehicles.
BTW Has anyone else studied Havok and PhysX? Havok seems to have better character support (controller/ragdoll transitions, IK). It's slightly putting me off PhysX. Thoughts?
I spent some time with the PhysX SDK to plan out implementation of fluid, character controller, ragdolls and vehicles.
BTW Has anyone else studied Havok and PhysX? Havok seems to have better character support (controller/ragdoll transitions, IK). It's slightly putting me off PhysX. Thoughts?
Irrlicht Demos: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=45781
-
- Posts: 153
- Joined: Mon Mar 03, 2008 8:42 am
- Location: Suceava - Romania
- Contact:
Slight problem.
So I'm attempting to make a very simple tanks game (in the spirit of the one I was writing in GameStudio years ago and with pyglet earlier this year), and I decided to try and use IrrPhysx to make everything that much more immersive (and let the player blow stuff up better, of course). I'm trying out the IrrWizard game structure while I'm at it (going well), so the whole thing is really more experiment/experience than it is game atm.
Anyway, slowly but surely I've been getting IrrPhysx to work. Gotta say, it is incredibly simple to use - anything in the examples can be duplicated and extended pretty easily by just copying out the code and changing a couple of names. So I've got a solid plane to drive around on, and a controllable tank made up of a body (animated mesh and scene node, although with no animations, with a SPhysxAndNodePair*) and turret (about the same, mesh is a child of body). My event receiver (GameManager, referenced by pManager, which holds a bunch of important pointers) passes down input to the GamePlayState, which checks it with the following:
Believe it or not, this makes my tank drive forward and backwards pretty well (except for a problem with the turret's PhysxMesh not being a child of the body's but I'm not too worried about that yet). The turning also works, but only for 90 degrees in each direction (i.e. between 270 and 90 degrees true). If you try and turn past that, it refuses to go any further, jiggles briefly (resetting to just below 90 degrees if you go over), and then crashes the program, incredibly unhelpfully, saying:
Sounds like pointers, right? Only I don't know what it could be that screws up only at this limit of rotation, and even worse, after I click break it tells me "No symbols are loaded for any call stack frame. The source code cannot be displayed." If it helps, the Disassembly says:
So I don't know what I'm doing wrong or how to fix it, or even whether it's related to IrrPhysx at all. I'm probably using some pretty bad Physx practices or something, but like I said I'm learning it from scratch. Can anyone help? Or even better, is there a better way to drive a tank around with IrrPhysx? I'm pretty much just winging it. Wheels would be nice, but I'm not touching the PhysX API with a 10 foot pole just yet.
Oh, and I'm still using Irrlicht 1.4.2 because it sounds like 1.5 breaks things Also using D3D9 with an nVidia 8800GTS on Vista x64.
So I'm attempting to make a very simple tanks game (in the spirit of the one I was writing in GameStudio years ago and with pyglet earlier this year), and I decided to try and use IrrPhysx to make everything that much more immersive (and let the player blow stuff up better, of course). I'm trying out the IrrWizard game structure while I'm at it (going well), so the whole thing is really more experiment/experience than it is game atm.
Anyway, slowly but surely I've been getting IrrPhysx to work. Gotta say, it is incredibly simple to use - anything in the examples can be duplicated and extended pretty easily by just copying out the code and changing a couple of names. So I've got a solid plane to drive around on, and a controllable tank made up of a body (animated mesh and scene node, although with no animations, with a SPhysxAndNodePair*) and turret (about the same, mesh is a child of body). My event receiver (GameManager, referenced by pManager, which holds a bunch of important pointers) passes down input to the GamePlayState, which checks it with the following:
Code: Select all
// DRIVE with W/S
if( pManager->getKey(KEY_KEY_W) )
{
vector3df velocity;
velocity.X = MAX_SPEED_BASE * sin(pManager->getPlayer()->getBodyMeshNode()->getRotation().Y*PI/180.0f);
velocity.Z = MAX_SPEED_BASE * cos(pManager->getPlayer()->getBodyMeshNode()->getRotation().Y*PI/180.0f);
//pManager->getPlayer()->setVelocity(velocity);
pManager->getPlayer()->getBodyPhysxShell()->PhysxObject->setLinearVelocity(velocity);
}
else if( pManager->getKey(KEY_KEY_S) )
{
// Same but negative
}
else
pManager->getPlayer()->setVelocity(vector3df());
// TURN with A/D
if( pManager->getKey(KEY_KEY_A) )
{
// NOTE: "shell" is what I call the magical physics gnomes around my nodes :P
vector3df rotation;
pManager->getPlayer()->getBodyPhysxShell()->PhysxObject->getRotation(rotation);
rotation.Y -= 0.1f * pManager->getDT();
rotation.Y = fmod(rotation.Y, 360.0f);
pManager->getPlayer()->getBodyPhysxShell()->PhysxObject->setRotation(rotation);
}
else if( pManager->getKey(KEY_KEY_D) )
{
// Same but negative
}
Code: Select all
Unhandled exception at 0x05a47aaf in Tango3D.exe: 0xC0000005: Access violation reading location 0x64602df8.
Code: Select all
05927AA9 mov ebp,dword ptr [esp+1Ch]
05927AAD add ecx,ebx
05927AAF cmp ebp,dword ptr [ecx+18h] <= ERROR HERE
05927AB2 mov dword ptr [esp+24h],ecx
05927AB6 je 05927B2D
Oh, and I'm still using Irrlicht 1.4.2 because it sounds like 1.5 breaks things Also using D3D9 with an nVidia 8800GTS on Vista x64.
The IrrWizard is an old half-sunk ship, get out of there while you still can!
Also, as far as this is concerned, I can see you don't test any value. Check for vectors that are too small or not unitary, test value that should be different and/or higher than 0, test for too high value. If you don't have a good debugger, then fill it with if and put breakpoints/logs in there.
Also, as far as this is concerned, I can see you don't test any value. Check for vectors that are too small or not unitary, test value that should be different and/or higher than 0, test for too high value. If you don't have a good debugger, then fill it with if and put breakpoints/logs in there.