[deathbravo]

I found some clues on my cloth crash.
the cloth is enabled to be simulated in both server and client side.
I am not sure why 2 identical clothes run in physx could cause invalid particle data.
the crash occurs while creating cloth enabled tsStatic using script in console.
the reason is Andrew's cloth code check physics world of client side while creating cloth, if the client world doesn't exist, nothing will happen. If client world exist, then create cloth in the world.
when loading the test mission with cloth in it, the server world will be created first, then load the shapes to the server side, create client world , then load shapes in client. while enabling cloth in server side, the code ask for client world, but the world doesn't exist, then nothing to do.
while create shape in the console, the client world is already there, the shape will be added twice in both server and client side, and are both created in the client world.

I tried to check isServerObject() in _enableCloth(), and it stopped crashing.

[chriscalef]

That is very interesting, @

deathbravo. I'm still very much up in the air on what to do about server/client physics in my own build. Early on, personally I took the perhaps controversial step of ignoring server physics entirely and doing everything I do on the client side only. Since I'm making a single user app rather than a multiplayer game, it makes sense for me, but I'm still very curious about the best way to manage the two simulations in the context of a game. I would think you'd want to only have things like cloth and particles happening on the client, anyway, unless you have bulletproof cloth or something that makes it actually have an impact on gameplay, and then have things like rolling boulders, player projectiles, and vehicles etc. exist in the server simulation. But then would you make them kinematic in the client sim and push positions/orientations from the server sim to all the clients every tick?

@

Timmy, how do you handle this?

[chriscalef]

OH MY GOD, YES YES YES.

Hehe, sorry, just found and fixed my bug, collisions work fine now, and my ragdolls look better than they have since PhysX 2.8. WHEW.

It was indeed a filter issue, sometime way back when I was floundering around trying to get things working at all in PhysX3, I tried changing to a CCD enabled filter shader, and it apparently fixed something or at least didn't break everything at the time, but now it was breaking everything.

The critical line I had modified was in Px3World::initWorld, and should look like this:

Code: Select all

sceneDesc.filterShader = physx::PxDefaultSimulationFilterShader;

But like I say, this was entirely my own doing, shouldn't be an issue for anybody else.

WHEW.

[chriscalef]

Hey Timmy, do you know anything about mWorld->releaseWriteLock()? I'm accustomed to locking and unlocking the scene whenever I'm going to add, delete or modify parts of the simulation, but instead we now seem to be calling releaseWriteLock() once before this sort of operation and doing nothing afterwards. I just switched everything from lock/unlock style to releaseWriteLock style in my own build, while searching for my collision bug, but can you elaborate at all about what's going on here?

[Timmy]

Oh yes that is my bad, ignore releaseWriteLocks , that static function is not used with the physx3 plugin and should be deleted. Use World->lock/unlockScene methods

[chriscalef]

Ah, okay, thanks, I'll put them back!

[chriscalef]

Well, so far so good:

https://vimeo.com/197044468

[Timmy]

Nice chris, looking good mate.

[chriscalef]

Thanks! Sorry for drifting a little off topic here, but the navmeshes are working fine now too! After a few hiccups.

https://vimeo.com/197230243

[JeffR]

Hah, that's really cool.