Physics improvement

[jhooks1]

Emailed Tom, got a good response.

Me

Hi, this is jhooks1 for the openmw project. I have looked into Project Aedra and in many ways it is better than openmw. I am a windows user myself and Project Aedra does look interesting.

Your physics system is superior to ours. Currently we are having problems climbing up stairs and getting stuck on certain spots. Some stairs can't by climbed up at all. Both our projects use Bullet, but yours uses a modified Bullet. What major components are modified? To get good physics do we need to use your modified bullet? Or is there a way to get it working good with the standard Bullet?

We use a btKinematicCharacterController, is that part of the problem? I noticed aedra does not use one.

Any hints for a Bullet newbie?

Thanks,
Jason

Tom

I initially looked into using Bullet's kinematic character controller
for Aedra and decided that I didn't like the feel of it (plus it had
quite a few problems). So I ditched that and decided to do what I did
which is to use Bullet as a collision-detection system only and then
to do the collision-reaction system for characters, spells, etc.
in-engine instead of in Bullet. So no, you do not have to use Aedra's
modified Bullet (in fact, if you want to use Bullet for anything other
than collision detection, you'll probably want to use the unmodified
Bullet instead). Furthermore, there's still problems with the Aedra
physics code that needs to be resolved before it's ready to go -
namely that there's still random jitter that I need to get rid of,
other various physics smoothing that needs to be done, and also better
physics network synchronization. Speaking of which, I didn't modify
Bullet very much - I really just changed how a few small things worked
because I wouldn't accept that Bullet doesn't support 2-byte mesh
indices (which it now does in my version). Lemme know if you have any
other questions - I'd be glad to answer them

Looks like we may need to stop using btKinematicCharacterControllers, which will require a lot of reworking/recoding.

[jhooks1]

Starting to slightly understand Aedra. Pmove.cpp is the brains of physics movement. It queries trace.cpp, which interfaces with bullet, to check for collisions.
It seems that Pmove() in pmove.cpp is the master function that gets called from the outside, and uses numerous (20+) helper physics functions.

[ElderTroll]

Awesome work J!

I can't wait to roam around the landscape devoid of moving life (if we get physics and terrain prior to adequate AI). "The Day the Nirn Stood Still"

Damn the fact that we don't have release names. JK

[jhooks1]

Should I make a branch from next? I think my current physics branch was from master.

[Zini]

Yes, please.

[jhooks1]

Been working on bringing in the physics code from Aedra, and have made a few commits. A lot of windows and direct3d specific things have to be changed to use the Ogre API. We have to change the physics code from using Aedras data structures/classes to our existing openmw structures/classes. There's a lot of rethinking and redesigning to be done before we can even get anything to compile.

First implementation will be very simple, for now I am commenting out player movement sounds.

[jhooks1]

Seems like the update function (which seems responsible for rendering/controlling of everything) of Aedra is called 60 times a second
// Keep in mind that if a client falls behind the net session's gameticks,
// then it'll need to catch up by calling GameUpdate() twice (or more) in a row
// Similarly, if a client is running ahead of the other clients, it needs to slow down by not calling GameUpdate()
// at all sometimes

So if we fall below 60fps, some frames may have to call the Aedra physics pmove code twice or more. Would be nice to get rid of this hard-coded limit, but for now we will have to work with it. If Aedra gets ahead of 60fps on certain frames it goes to sleep (similar to vsync?)

[raevol]

Non-technical person here, but for a single player game, that sounds super hacky. Couldn't the physics update loop be called whenever, and just do its calculations based on a time delta from when it was last called?

[jhooks1]

Should be able to, but it would require some modification (not sure how much yet). Probably could work right now, calling it for every frame, but the player's speed would be different depending on framerate.

[raevol]

but the player's speed would be different depending on framerate.

Well, that's why you do a time delta between the current call and the last call. Again, I'm not a programmer, so maybe I am talking nonsense, but when I was working with the love2d engine, that's how they did things. So if your last frame was a second ago, you do physics calculations for a whole second. If it was a millisecond ago, you do calculations for a millisecond.

But again, just taking a stab at the dark here, I'm not qualified to be talking about this...