IrrPhysx 0.2 - Nvidia Physx 2.8.1 wrapper

[Malgodur]

Sometimes cloth dont collide with meshes, it sink in mesh....but it isnt a important problem

Can you explain here how can i add ms3d mdel to phyx, like those letters in one f examples? Well i tried to copy code from examples but i always iss omething importat, my mesh appear but dont fall down and don collide with otheer objects,

[Malgodur]

Got another problem....i cant shoot at floor because physx bullets collide with physx player bounding box... how can i fix it?

[JP]

I can't really explain it better than the examples.... Sounds like you might not be updating the nodes to the positions & orientations of the physx objects though... Note the usage of the SPhysxAndNodePair struct and the array of the ones created, it's important!

As I say, with the cloth, it's a limitation of Physx, you can get round it by increasing the poly count of your cloth, but that can really kill performance!

Shooting through the player's bounding box is something I thought about but I've not got round to doing anything about it yet.

[Malgodur]

Tried to add physx letters to game example. They spawn when i hit L, they fall down etc, but there are some problems with they colision, for example i cant shoot or throw a sphere trough a hole in P because it collide with other object....same with S etc..
it seems the letters have something like bounding box?? But i want to add model to physx.?

Code: Select all

SPhysxAndNodePair* createLetter(s32 letterIndex, const core::vector3df& pos, const core::vector3df& scale)
{

	scene::IMesh* mesh = smgr->getMesh(textMeshPaths[letterIndex]);

	SPhysxAndNodePair* pair = new SPhysxAndNodePair;
	IPhysxMesh* physxMesh = physxMeshCache->getMesh(mesh->getMeshBuffer(0), EMT_CONVEX, scale); //node->getScale());

	pair->PhysxObject = physxManager->createConvexMeshObject(physxMesh, pos, core::vector3df(0,0,0), 50);

	pair->SceneNode = smgr->addMeshSceneNode(mesh, NULL, -1, pos, core::vector3df(0,0,0), scale);

	pair->SceneNode->setMaterialFlag(video::EMF_NORMALIZE_NORMALS, true);

	return pair;

}

[christianclavet]

Hi, JP.

I have a basic question about IRRphys...

Can the current implementation could support basic collision? Would it be easy to replace IRRlicht occtree collisions (collision response animator done with IRRphys)

I'm wondering if I could use it for moving the cameras and other meshes (NPC, etc).

IRRlicht is pretty adequate, but sometime depending on the geometry, could have a tendancy to get stuck. (My new test level get stuck on a very simple staircase. I'm still wondering if it's the occtree or the collision system)

[Dorth]

Stairs are the uber bane of the current Irrlicht collision system. When I began using Irrlicht, I used it in a project instead of a physic engine (I know, silly me), and the results were... acceptable, that is, unless you looked at the stairs. Fudging the settings so stairs would look proper would make something else go awry. Your best bet is to remplace it altogether by a real physic engine, like bullet or PhysX and never look back. The earlier the better, too, 'cuz if you wait, it'll only be that mucch harder to patch later on.

[JP]

Well Christian what you're after is character controllers, which is what I'm working on at the moment and I've got it implemented and working and so I just need to tidy it up so I can release it... Unfortunately I have very little time to do this as I'm working 12 hour days at the moment and get about an hour at home in the evenings before I have to get to bed pretty much so no time then. This easter weekend would have been a great time for me to get the next IrrPhysx out but I'm going to be working possibly up to 3 days of the weekend and the other day I may be too busy to do anything... It's a pretty tough time at the moment for me!

Oh and stair climbing should be fine with character controllers, in the example I've knocked up I've got some boxes forming stairs and the character controller goes up and down them quite happily... It's vaguely possible that certain situations could bork it up though, I can't rule that out.. But seeing as it's Physx I would expect their implementations to be pretty good as they've got a lot more time and man power to put into it all than the Irrlicht guys do!

Malgodur, the Meshes Example uses convex meshes for the letters and that means that effectively a bounding mesh is created for the letters, so yes you won't be able to shoot through holes in the meshes as the physx convex mesh doesn't cater for those holes.

You could use a triangle mesh but then they would be static (i.e. they wouldn't be affected by gravity or collisions, they would be un-moveable objects). I don't really know if Physx supports non-static complex meshes or not... Right now I obviously don't have the time to look into it!

[Malgodur]

Oh, man... so irrphsyx is useless for fps game? What should i use for physic and collision then?

[Steel Style]

Malgodur, the Meshes Example uses convex meshes for the letters and that means that effectively a bounding mesh is created for the letters, so yes you won't be able to shoot through holes in the meshes as the physx convex mesh doesn't cater for those holes.
[...] (BUT)
You could use a triangle mesh but then they would be static.

So Like he said if you wanna shoot through the hole you wille simply need to use triangle mesh. You can use it for an FPS game of course.

But if you wanna make them move you will need to make you own implementation.

[JP]

What's so special about FPS games that need objects with holes in them?

[Dorth]

Anyway, a concave object is nothing more than multiple convex objects together (and that means a friggin huge amount of said small objects when you want a hollow sphere )

[Steel Style]

What's so special about FPS games that need objects with holes in them?

They are nothing special with them, but I think that people like to be hidden and be able shoot that's why he plane to do some object with holes.

[JP]

Yeah no problem, you just have to use static triangle meshes... If it's for the environment he needs it then that's fine because it's never going to move.

[nixxe]

Try removing the terrain from the .irr file (or prevent the physx object for the terrain being created in ReadScene.cpp) and see if that allows it to run... For some reason some people have issues with the terrain stuff... can't think why though...

I got the same error and after removing the terrain it run fine. After some debugging I found out that it works when i removed the ROUND macro from createHeightfieldObject() in CPhysxManager.cpp. Tryed to replace the ROUND with floor but it still crashed, so I have to let the cast floor it for me .

Code: Select all

	// Smooth it out to match Irrlicht's ITerrainSceneNode's smoothing
	u32 run;
	u32 index;
	for (run = 0 ; run < smoothFactor ; ++run) {
		currentByte = (char*)heightFieldDesc.samples;
		currentByte += heightFieldDesc.sampleStride * 2;
		for (index = 2 ; index < (dimension * dimension - 2) ; ++index) {
			NxHeightFieldSample* currentSample = (NxHeightFieldSample*)currentByte;

/* Removed code
			currentSample->height = (NxI16) ROUND( ( ((NxHeightFieldSample*)(currentByte - heightFieldDesc.sampleStride * 2))->height +
											         ((NxHeightFieldSample*)(currentByte - heightFieldDesc.sampleStride    ))->height +
											         ((NxHeightFieldSample*)(currentByte + heightFieldDesc.sampleStride    ))->height +
									                 ((NxHeightFieldSample*)(currentByte + heightFieldDesc.sampleStride * 2))->height   ) / 4.0f );
*/

// Replace for removed code
			currentSample->height = (NxI16) ( ( ((NxHeightFieldSample*)(currentByte - heightFieldDesc.sampleStride * 2))->height +
											         ((NxHeightFieldSample*)(currentByte - heightFieldDesc.sampleStride    ))->height +
											         ((NxHeightFieldSample*)(currentByte + heightFieldDesc.sampleStride    ))->height +
									                 ((NxHeightFieldSample*)(currentByte + heightFieldDesc.sampleStride * 2))->height   ) / 4.0f +0.5f);

			 currentByte += heightFieldDesc.sampleStride;
		}
	}


	for (run = 0 ; run < smoothFactor ; ++run) {
		currentByte = (char*)heightFieldDesc.samples;
		currentByte += heightFieldDesc.sampleStride * dimension;
		for (index = dimension ; index < (dimension * (dimension - 1)) ; ++index) {
			NxHeightFieldSample* currentSample = (NxHeightFieldSample*)currentByte;
/* Removed code
			currentSample->height = (NxI16) ROUND( ( ((NxHeightFieldSample*)(currentByte - heightFieldDesc.sampleStride * dimension))->height +
											         ((NxHeightFieldSample*)(currentByte + heightFieldDesc.sampleStride * dimension))->height   ) / 2.0f );
*/

// Replace for removed code
			currentSample->height = (NxI16) ( ( ((NxHeightFieldSample*)(currentByte - heightFieldDesc.sampleStride * dimension))->height +
												((NxHeightFieldSample*)(currentByte + heightFieldDesc.sampleStride * dimension))->height)/2.0f+0.5f);

			currentByte += heightFieldDesc.sampleStride;
		}
	}

Can't figure out why and to make it more strange is that smoothFactor is 0 so the loop is never executed... and it do crash on the same place as before if I do a scene-reset ingame.

It crashed here:

Code: Select all

NxHeightField* heightField = PhysicsSDK->createHeightField(heightFieldDesc);

[JP]

Excellent work nixxe! Seems to be some problem with the data for the heightfield then... Maybe ROUND doesn't act quite right on some systems... I think that was a little macro I may have written myself (or maybe copied from the Irrlicht code perhaps) and it was necessary to get the heightmap data generated correctly. At least that's something I can now look into so I know where it's crashing!

EDIT: nixxe (and anyone else who has had the heightfield stuff crashing) what's your PC setup? There must be something different about it that's the root of this problem so anything you can tell me about it would be good to know!