Character gets stuck

I'm having this weird problem... Sometimes when I start a level in my game the character is stuck. I try to move it, but it doesn't work. Then I restart the level and it sometimes works fine and sometimes it doesn't. This never happens when the character is in motion, once it starts OK, it always moves just fine. I did some research and the character's position and velocity seem to be fine. What may be the problem?

I wonder if the actor in the character is falling to sleep, it shouldn't but worth a check, else there's always "actor stuck in another shape" problem you may have.

Same problem here, it's very weird, for example... <grins> if I run my "sandbox" code 10 times with floating point mode = fastest, or floating point mode = consistant , the character will get stuck at least 4 out of 10

However, if on every second try ( out of 10 ) I switch to either fastest or Consistent 10/10 works fine.. woo hoo! hmm.. so randomizing these settings in my final code ( without the Ogre dialog ) should be enough

Seriously, I have no idea why this does happen, but it does, and ( as you know) you can't have the character freezing 5/10 times in a final game

I normally don't post very often, as I can usually find what I need to help through searching, but with this problem... well, as said, very weird and at the moment ( for me ) unsolved

cheers.

Well it's a bug in PhysX or NxOgre then.

I'm still thinking it may be falling asleep or some floating point error. Either way some more information about the NxActor and Character is needed.

I have ran into the same problem.

I think it happens when the character penetrates a static actor.

It's good to know I'm not alone with this problem.

Has anyone been able to get around this? I'm still looking into it, but have had no luck so far...

What scale are you guys using? I'm using 1 = 1cm (standard is supposed to be 1 = 1m.) I've had no problems with scale so far, so I don't think that's it, but you never know...

I've been of NxOgre for the last week and a bit with other things. I may be able to replicate the bug, but I need a triangle mesh to work with (level bits, a piece of grass, etc. Something that is used in the real-world.)

Once I have NxOgre compiling again, would anyone volunteer a mesh for me?

Send me a PM of what you need for testing betajaen ( character, small scene etc etc) and I'll get it to you.

A small scene will do. I'll let you know when I need it. But I need to write the triangle mesh code before hand for it to be read!

Sometimes, I have the same problem and I noticed something very strange. If a Character is stuck, it nearly always helps to delete something in my media ordner (I have a lot of stuff there which is loaded, but not used).
If you need more testers, just send a PM.

Hi. This is what I've found out so far:

Test scene setup

I exported a simple test scene, with:
* A terrain (static actor using a triangle mesh shape)
* An obstacle (also a static actor using a triangle mesh shape)
* A character
Both static mesh shapes are created automatically from the corresponding .mesh file.

I set up the scene so that: the obstacle was lying on the ground, far from the character, and the character was flying 200 units (2 metres in my scale) above the terrain. The obstacle and the character were not touching in any way (I double checked this using the remote debugger.)

Expected behaviour: the character should fall to the ground and I should be able to make it move around freely.

First tests

In my first test runs, I found out that if the obstacle mesh had only one material, the scene would work as expected. The exact same mesh with two materials applied, resulted in the character not moving at all. It didn't fall to the ground nor let me move it in any direction.

I'm using a subclass of NxOgre::CharacterMovementVectorController to move the character which move method is very simple:

void NxCharacterMovementController::move(NxVec3& out, NxVec3& moveVector, NxQuat& direction, NxVec3& g, float t, NxOgre::Character* character)
{
moveVector.normalize();
out = ((direction.rot(moveVector) * _speed) + g) * t;
}
I added some code to output all the relevant values (moveVector, gravity, time, ...) to the screen to check they were ok, and I can assure they were. For example, the output vector showed <0, some negative value, 0> when I didn't touch any keys, which should make the character fall to the ground as expected, but didn't...

Further tests

I went on to do some other tests, given I had found a situation in which the problem appeared always (that is, having that two-material obstacle, which wasn't touching the character in any way).

I found out two interesting things:

1. The problem only happens in Release mode. All I described earlier doesn't happen in Debug mode in any case, it always works fine.

2. It appears as if the order of creation of the obstacle and the character affects the problem too. Back in Release mode, if I created the character after the other two actors, it would get stuck. But if I created the character first, it'd work just fine.

Conclusions so far

So, this seems to be one of those nasty Release/Debug bugs.

The bug may be in NxOgre or in my own code. I discard a problem in PhysX because the library is the same in both Release and Debug.

I lean towards a problem in NxOgre because: first, it seems to be happening to other people too and second, as I said, the numbers that come out of the move method of the character movement controller are ok.

I hope this is helpful. I'll do some more tests as soon as I can.

Thank you, I will look into it.

That is a much better bug report than "IT DUSENT WORK! FIX IT!"


In other news, NxOgre 1.01-1.1 will have a new character system, these are the plans. It's a little cryptic but see what you guys think.

I'm still looking into this bug... Typically Release/Debug problems have to do with uninitialised variables. While searching for those I found this bug that was preventing NxOgre from being shutdown and recreated properly (which I needed for changing resolution):

NxOgreError uses a singleton pattern with a static mError variable, which is initialized to NULL and then set to this in the class constructor. But, in the class destructor, it's not set back to NULL so when you try to reinitialise NxOgre you get an error as getInstance() returns the previous (deleted) instance of NxOgreError.

The solution, just add mError = 0; in NxOgreError::~NxOgreError. I hope that helps.

Also, I was wondering if this character stuck bug may have to do with something like this...?

Thankyou. Added the change.

Also, I was wondering if this character stuck bug may have to do with something like this...?

Do you mean bug with the error system, effects the Character controller? No it won't. But if you mean a uninitialised variable, maybe. However I think it may be down to frame rates, timing and sleeping.

A little update on the results that I'm getting with NxOgre now.
My eldest son gave my code a good bashing while I was eating my tea tonight ( he's my personal little beta tester/game breaker ) lol

He stopped at 60 runs, and the character didn't freeze once
The problem is, I'm not sure if I can be helpful to you guys in finding exactly what I did to fix it!

The only things ( I can remember ) changing in my code over the last few days are:

- Recently adding Squirrel scripting, coll meshes etc are now loaded through scripts.

- Adding the above error fix.

- Updating without a frame listener i.e ... simulate() and render().

- Changing setStaticFriction on the material ( can't remember what it was before though ) Basically I was giving the Rag doll code that is posted in the other thread a go.

- Set the characters Y start position to a much higher value.

- putToSleep() then wakeUp() before the coll mesh was loaded.

I can't think of anything else, but everything is now working like a charm for me right now

I would say one of these did it:

Updating without a frame listener
Changing setStaticFriction on the material
Set the characters Y start
putToSleep() then wakeUp()

Give your son a cookie from me.


Has anyone tried constantly waking up the NxActor in the Character every frame?

I am having the same problem with my game... its a 4 player party game and every now and again one or two players get stuck on spawning... it seems quite random, and ive tried all types of hacks to stop it from happening but to no avail. I havent tried to wake up the nxactor in the character every frame, would i have to edit your source code and recompile the libs for that?

My game is a side on platformer, basically filled with static box actors to jump around on. I can also vouch for it only happening in release mode, debug is very slow fps but this never happens. Maybe some thing to do with the nxogre release project settings??

It is very simple to "wake up" a character.


mCharacter2->getNxController()->getActor()->wakeUp();


Just put this code in the "FrameStarted" or wherever you call your render/physics updates.

Hope this helps you.

I have had this problem off and on for the last half year. I have stopped working with characters in NxOgre, as I am waiting for some of the new features to be implemented.

I have had to "wake up" vehicles as well.

instead of calling wakeUp() every frame you can call it once with a very high value like
.. ->getActor()->wakeUp ( 10e30 );

this value should be high enough to ensure that the actor will never fall asleep

unfortunately, waking up the character every frame didnt work

One thing that i observe happening is that i have a function to destroy the character and recreate it in another position, and when i run it the players that were frozen in the start stay frozen consistently. I tried to randomise their name string everytime. The only thing that really stays consistent in my player class is their CharacterMovementVectorController. so mabye mCharacter->setMovementVectorController(this); might be screwing up??

my movement vectorcontroller has been simplified quite a bit as i wanted more of the control myself. moveVec being the amount of movement offset.

Maybe i could test the theory by moving the player by myself, but setnextrawmovementdirection() looks damn confusing


void Player::move(NxVec3 &out, NxVec3 &moveVector, NxQuat &direction, NxVec3 &g, float t, NxOgre::Character*)
{
out = NxVec3(moveVec.x, moveVec.y, 0);
}


here is a picture of a player getting stuck, they should fall to the floor like all the others.. all of the 4 players take a random turn each at getting stuck for the round. and sometimes its 2 or 3 in one go. and even if i have an empty physics scene with no other bodies except the players.

I have the same issue.. One of four tested characters doesn't seem to do anything. I've tried many combinations of random things with no such luck. Additionally, I've tried mine without calling setMovementVectorController(), but the same result occured. Also note that the exact same character exhibits this behavior (it's not an issue of which order they're created in, atleast to a certain extent). I hope this information helps.

-Denny

P.S. I think that since the issue will occur on the exact same character even after creation and destruction multiple times (including using fresh names), the problem starts in the constructor of the Character class (an issue of the xth character being created, perhaps depending on certain variables specific to each program or in some cases, instance of a program).

Here's my solution... I don't know if it will work for others, fairly hacky, but it works for me and it's worth a try. I first create all of my needed characters. I then wait until a couple of frames into each character's life to test it's last position compared to it's next position. Assuming the character isn't somehow positioned perfectly to the ground, it should fall at least a tiny bit. If the character's position changes, then it verifies it as good and leaves it to do as it will. If it sees no movement after 10 frames, then I verify it as bad. If it's bad, the node detaches all objects and I make it stop updating (for performance reasons) but I leave the created character alone. Disable collisions is probably also desirable. I then create another character and assign it to this one's position etc. This seems to work fairly well for me, however, a better way would probably be to perform a movement test during those first few frames in case it is positioned perfectly on the ground.

EDIT: Now uses a test movement to detect a change in position.

if( initial )
{
if( iter > 2 && iter < 10 )
{
character->addMovement(NxOgre::Character::DR_Forward); // In case too close to ground.
if( last_position != character->getGlobalPosition() )
{
// The physics works for this character.
initial = false;
}
}
if( iter > 10 )
{
// The physics isn't working on this character... Hide it but leave it here so no more objects mess up due to this.
character->getNode()->detachAllObjects();
Ogre::Root::getSingleton().removeFrameListener( this );

NPC *npc = EntityManager::getSingleton()->createNPC( mType ); // Make the replacement for this failure.
npc->setPosition( character->getGlobalPosition() );
npc->scale( character->getNode()->getScale() );

initial = false; // Just making sure this doesn't magically get called again.
}
last_position = character->getGlobalPosition();
iter++;
}


I hope this helps.

-Denny

You've probably tried it, but when you have a stuck character have you tried setting the position to somewhere else, and check if it comes alive?

You've probably tried it, but when you have a stuck character have you tried setting the position to somewhere else, and check if it comes alive?

Yes, with no luck.

Okay, I had a glance at the old character code (old for me). Add this to NxOgreCharacter.cpp

mCharacter = 0;

It's about line 62ish.

Create your characters until one gets stuck, then post the contents of the log.

I put the line right below "mMass = 100"


NxOgre::PhysXDriver::PhysXDriver#142T0 F34

NxOgre (NxOgre 0.9-38) Started, working with:

- PhysX => 2.7.2
- Ogre => 1.4.5 'Eihort'
- Platform => Windows

NxOgre::VariableSceneController::init#87T0 F34

VariableSceneController Initalised

NxOgre::Scene::_registerCharacter#1334T0 F34

Scene Character registered

NxOgre::Scene::_registerCharacter#1334T0 F34

Scene Character registered

NxOgre::Scene::_registerCharacter#1334T0 F34

Scene Character registered

NxOgre::Scene::_registerCharacter#1334T0 F34

Scene Character registered



I was hoping it would say "Cannot create character controller".

Before we start submitting tickets to Ageia complaining that there Character System is broke, one last thing.

If you could have your application somehow tell you what character is broken (say putting on the screen the last character's name), then could you add this piece of code in:

void Character::simulate(float t) {

NxVec3 moveVector, gravity;
moveVector.zero();
mScene->getNxScene()->getGravity(gravity);

// Calculate next movement.
mMoveVectorController->move(moveVector, mNextMovementDirection, mDirection, gravity, t, this);

// Move it
mCharacter->move(moveVector, mMove_ActiveGroupsMask, mMove_MinDistance, mCollisionFlags, mMove_Sharpness, &mMove_GroupMask);

// THIS BIT.
std::stringstream s;
s << mName << "(" << t << ")" << mNextMovementDirection.x << " " << mNextMovementDirection.y << " " << mNextMovementDirection.z;
NxDebug(s.str());
/// END OF THIS BIT..

// ...And reset.
mNextMovementDirection.zero();
}


Then look in your log (it'll be huge). Search for the Character's name, and see if it's in there. If it's not, it's NxOgre otherwise it's PhysX.

The character name is in there. Here's a link to the log if you'd like to have a look.
http://rapidshare.com/files/70509038/Nx ... g.zip.html

By the way, the failing one is named "npc_nurse_physics_object_1"

-Denny

Interesting. Did you try and move the npc_nurse character?

And here it is with NxOgre::Character::addMovement(NxOgre::Character::DR_Forward); called each frame.
http://rapidshare.com/files/70657092/Nx ... g.zip.html

Looks like PhysX is to blame then, it's not responding to the move vector. Just to make sure. Can you add this change to piece of code to what you've added?

std::stringstream s;
s << mName << "(" << t << ") MoveVec => " << mNextMovementDirection.x << " " << mNextMovementDirection.y << " " << mNextMovementDirection.z << ", Pos => " << mCharacter->getPosition().x << " " << mCharacter->getPosition().y << " " << mCharacter->getPosition().z;

Run the program again with a forward movement on the nurse and then post back with the log.

http://rapidshare.com/files/70711551/Nx ... g.zip.html

Yep. PhysX is bork.

I can submit a ticket to Ageia if you like, but it'll be later on today or tomorrow when I get around to it, or if you want to. Ageia may pay a bit more attention to me though.

Yeah, plus you probably know a bit more about the way PhysX works, etc. (since I've never used it directly =P). If you think it would help, I can submit one as well though.

I forgot to post a ticket, but I'm going to delay until the same error exists in the new PhysX 2.7.3 SDK. Ageia has done some work with the Character, so it may of been fixed.

Anyway let me know.

I upgraded PhysX to 2.7.3 and rebuilt nxogre but still having the same problem

Could you fix the problem? I get a similar problem with NxOgre v0.9-38, when I compiled in release mode.

Ageia have released the source to the NxCharacter class in PhysX 2.8.0, you may be able to fix the error yourself.

Either way; it won't be much of a problem for those who use Bleeding - I am writing my own character controller from scratch.

I've been having this problem forever now and just recently found this thread. Has there been any progress? Has betajaen made a new character class for bleeding yet? If so the only reason I wasn't going to upgrade to the lastest NxOgre is because it lacks character support.

My findings with this are. If i previously make a character:


NxOgre::CharacterParams Params;
Params.setToDefault();
Params.mType = NxOgre::CharacterParams::CT_Box;
Params.mSkinWidth = 0.5;
Character* mCharacter = mScene->createCharacter("MrTest", NxOgre::Pose(Vector3(-5,10,0)) , Params);


then i create my characters after. I don't get any dud guys... but it still is hacky. If anyone has made any further progress please post.

Also if you run you app in visual studio. Like in release mode but with the debugger following it. I NEVER seem to get dud characters.

No, I haven't started the Character code yet - although I have it planned out in my head. I'm very sure it's the code in NxCharacter.dll, considering I we have access to it now, and I'm going to rewrite it - the bug should be squashed.

OK .

How easy would it be for me to copy the 0.9 character code to bleeding(as a temporary fix)? I haven't really worked with bleeding (other than just playing around) so i am not too sure how different it is.

Hi guys

It seems that the bug were in the NxOgre initialization of the Character, where the mMove_MinDistance member variable were left uninitialized.

Running from the IDE the system memory automatically picked up a reasonable value, but running from outside it picks a too small value, what explains that the bug only occurs when running outside from de IDE.

So, to correct it, just put this line anywhere in NxOgreCharacter constructor:

mMove_MinDistance = 0.001;

Maybe betajean can provide a more accurate value.

Hope it works for you

You could certainly try.

Couple of ideas of porting

- Any references to Body should be Actors.
- Try and use the NodeRenderable/RenderableSource stuff.
- Try and follow the bleeding callback style.

If it works and turns out well, I'd be more than happy to give it out as a patch until I finish the new Character system.

Hi guys

It seems that the bug were in the NxOgre initialization of the Character, where the mMove_MinDistance member variable were left uninitialized.

Running from the IDE the system memory automatically picked up a reasonable value, but running from outside it picks a too small value, what explains that the bug only occurs when running outside from de IDE.

So, to correct it, just put this line anywhere in NxOgreCharacter constructor:

mMove_MinDistance = 0.001;

Maybe betajean can provide a more accurate value.

Hope it works for you

OMG I have been looking for this forever. I haven't tested yet but it seems that this is the problem. I haven't once had a dud character yet.
The bug was ignorable until I got to netcode. Thank you so much maiconb.

@betajaen: What would be a reasonable min move distance?

Your kidding that, mMove_Distance wasn't initialized? That stupid bug was because of that? Holy Bananas.

But for your question, I would think centimeter minimum and 10 cm maximum are reasonable values. Say 0.05cm.


Also; You will be glad to hear I've finally started on the CC code. I'm working outside NxOgre at the moment, using an OpenGL application - it's faster to develop and make small changes than it is to the behemoths; Ogre and NxOgre. And I'm using the new game "Mirrors Edge" as much as my inspiration.

Your kidding that, mMove_Distance wasn't initialized? That stupid bug was because of that? Holy Bananas.

But for your question, I would think centimeter minimum and 10 cm maximum are reasonable values. Say 0.05cm.


Also; You will be glad to hear I've finally started on the CC code. I'm working outside NxOgre at the moment, using an OpenGL application - it's faster to develop and make small changes than it is to the behemoths; Ogre and NxOgre. And I'm using the new game "Mirrors Edge" as much as my inspiration.

I checked out mirrors edge just because of this post. It looks cool. What were you going to copy? The gameplay? visual style?

No, not the style - more like the game-play.

I'm going to attempt to make the Character's actor switch between kinematic and not kinematic in certain situations i.e. the character swinging on a rope, falling (and controlling orientation of your fall), and so forth. Perhaps, I can even tie up a ragdoll up to the character and fold it inside the character whilst it's kinematic and unravel it when it's needed - or even partially.

This is exactly what we need!
Still waiting eagerly...

BTW: How will you manage ragdoll properties? Do you plan support e.g. for Scythe or is there an API planned?

I really don't know yet (most likely an API and file format). I did have a quite lucid dream last night of the final product; I put out a video on the forums demonstrating the new character controller using Cake. In the first scene; the character was just walking along (using a standard walk) animation when suddenly he falls of the edge; the code senses a fall and switches the character from an animated state to a ragdoll state - the physics kick in and the character turns horizontally (as you may do in reality) and slams into the floor. The second scene featured the character being hit by a truck and thrown backwards, and a third scene featured weaponry. Of course it was a dream, but at least my subconscious knows what the Character System should be like - so I will follow that. In the form of SleepCoding!!

But good news; I have written a small/fast to compile GL application, using OIS as an input system, and a really really small very of NxOgre is included (one file!). I plan to use that as a base to develop the Character controller system, then merge it into the main source code when it's complete. I'm even planning to post the executable here now and again for everyone to try it out.

Just another quick update. PhysX and OpenGL wrapper is complete so I can start some real work on the Character System.

I decided to start my work first on the Skeleton system; which ideally is used for rag dolls, but in many situations could be used for other things i.e. moving bridges, or opening car doors. The idea is; each NxActor is represents a bone which is joined together via joints.

I've already written a some basic skeleton and bone classes, and have it represented in the 3D application now. At this stage it's more planning than programming, and since I have to do it right the first time - it's best to plan a lot. I've decided upon a number of classes for the Skeleton system.

- ManualSkeleton
- Bone
- Skeleton
- SkeletonRenderable

And with Ogre; OgreSkeletonRenderable.

The file extension for saved skeletons is "xsk", and hopefully will be generated by flour from other file formats using the ManualSkeleton class.

I would show screenshots; but there isn't much to see.

Sorry to dig this up.

Regarding the original problem (the NxCharacter doesn't move when spawned (0.9, intermittent).. well i've found a cheap-and-dirty fix. Quite simply, we changed how we load our scene: We load the scene mesh, load the physics scene, load all the entities. This is because, we use this scene as a background for our menu (Like Half-life 2). Then when the user clicks new game, we destroy everything (including the physics scene) and make it all again, this time with the map that the user selected. Since we started doing this, we never have the NxCharacter-stuck-on-spawn problem..

However, i look forward to character support in future versions

Interesting approach. The Intermittent character spawning problem was due to an uninitialized variable, there has been a thread or two recently describing the problem and a fix.