Following a character from above

I have a character which I'm controlling moving around on a 2D plane. I want the camera to follow the character around from above. There are two ways I've found of doing this:
A. Each frame, set camera's position to be 20 units above the character and point the camera at the character
B. Attach the camera to the character's node and move it 20 units up at the init.

A is a hacky method, but works as expected except that the camera regularly jitters, causing heavy tearing and general unpleasantness.
B doesn't seem to have the jitter, but the camera rotates with the player, but I want the camera rotation to stay still whilst the player appears to rotate on screen.

How might I go about fixing either of these issues?

I hear you're doing an overhaul of the character class in 1.1, is there an ETA for 1.1 within the next month? (As that's when this project has to be completed)

It won't be finished by then, sadly.

B is probably a better choice than A, if you can set the orientation of the camera to whatever after moving it should work. The main Ogre forums should help you out a little with that.

B is a better choice. If you don't want the camera rotating with the character, you should restructure your node hierarchy.

Structure 1:

BaseNode
-> CharacterNode
-> CameraNode
-> Camera


Rotations are only applied to the CharacterNode, so they don't affect the camera at all.

Structure 2:

BaseNode
-> CharacterNode
-> CameraNode
-> Camera


In this case, the camera node will rotate with the character. To stop this from occuring, call mCameraNode->setInheritOrientation(false);

Or you can use whatever works.

Ah, thanks for this, I should have know Ogre's clever Node system could help here.
Structure 1 would just attach the camera to the Root node, so would be the same as A.
Structure 2 works very nicely though, doing this:
mCamNode = playerObject->objectCharacter->getNode()->createChildSceneNode("PlayerToCameraNode");
mCamNode->attachObject(mCamera);
mCamNode->setInheritOrientation(false);
mCamera->setPosition(0,20,2);
Fixes the problem, and there isn't any nasty jittering.


As a followup question, if I wanted to make NxOgre simulate with my own time per frame (say I changed to use a more accurate timer), is there a way of doing this without recompiling NxOgre?

mWorld = new World("framelistener: no");

///

mWorld->getPhysXDriver()->simulate(deltaTime);
mWorld->getPhysXDriver()->render(deltaTime);


deltaTime is read in seconds.

Cheers, it's significantly smoother now.

Are character controllers suitable for crowd physics?

I've got 50 characters which move in a crowd, all bumping into each other, and it seems to slow the game down significantly.
Removing attachMesh() doesn't improve performance much, so it's not a graphical instancing problem.
What ways could I increase performance? Should I be using dynamic bodies instead of characters? Can I reduce the accuracy of the physics?

Hmmm....You could try using upright capsules like Newton does, but you won't get all the benefits though, such as stair or rough ground movement, or worrying about friction, etc.

You could try adjusting the "SolverIterationCount" in the NxActor of the Character, try it at 3 or 2. Otherwise I would ask on the Ageia forums and see what they see.

I doubt it's an NxOgre problem though. One last question, you are judging this in a Release mode of your application?

objectCharacter->getNxController()->getActor()->setSolverIterationCount(2)
Doesn't seem to change anything for me.

All I'm wondering is if PhysX can handle this at a good framerate, or whether I'd be better off writing my own basic collision detection - seeing as it's a very simple simulation - all on a flat plane with capsule characters and box-walls.

I am using Release, seeing as it doesn't like PhysXLoader in Debug for whatever reason.

I'll check around Ageia to see if there's a good optimisation.

I would imagine it would handle 50 actors perfectly fine. So there must be something else. I wonder if the log says anything, or is even the cause of the slow-down.

By 'significantly' I don't mean that it brings the game to a halt, it just runs at 500FPS without them and about 70FPS with 50 of them. I was hoping to have many more of them on screen, and I'm trying to find the most efficient way of doing it.

In the log, all I get is:

NxOgre::Scene::_registerCharacter#1334T0 F0

Scene Character registered

I checked through my own advance() code and took out everything but
objectCharacter->addMovement(Character::DR_Backward);
And the framerate is the same. If I comment this line so that none of the characters are moving, the framerate is about 300FPS.

That is significant, PhysX wouldn't normally sweat with 50 actors, so why would it cry in pain with 50 characters?

Besides doesn't UT2008 have Multiplayer with that amount of characters in it? I'd see what Ageia thinks.

I think the problem is when characters bump into each other while in motion. This is going to cause the characters recursion, they will continuously try to "solve" the problem, you might be able to help by changing the minDist in the nxcharacter move function. I would expect you would need to implement some other logic.

One idea: stop and go
Give the characters a collision sphere to detect a "collision" before the character collides with the other character. In this case order one of the characters to move (the other stops) until there is no longer a collision, you would probably want to need to set up some "priority system".

Slighty OT here. But some progress of the new Character System.

These are the classes I've decided so far, and their hierarchy.


CharacterSystem
+ Character
- uses: CharacterController
+ NxActorController
+ NxCharacterController
+ Performer (Character with a SceneNode, like Body is to Actor)


Characters use CharacterControllers (an abstract class), which uses either a NxActor or a NxCharacterController version. NxActors are like Actors; used for low-tech or low-priority Characters, otherwise NxCharacterController are the same as before.

Characters, like Actor don't have visualisation, so you have a Performer if you want a quick Actor with a SceneNode/Mesh.

There is still a lot more planned classes like CharacterModels and CharacterMovementModels, which allow you to directly specify movements such as Walking, Sidestepping, ladders and so forth, and how they relate to each other, and further supporting animation of meshes or game logic.

[Edit]

Oh, and I want it to dynamically support things like walking up walls and ceilings, etc.

The new character system sounds very cool, I like the idea of automated ladder climbing, but it's less applicable for my simple simulation.

I think Aiursrage is right, that it's because all the characters are in a crowd, and they're colliding a lot. By setting mMove_MinDistance to 0.01, I get an increase in framerate from 50FPS to 80FPS when all the characters are in a group. Although this is an improvement, it isn't as big as I was hoping for.

I might try a stop and go test and see if that helps.