So just when I felt like becoming productive Texas got a TON of snow Thursday and Friday that made getting work done impossible. Really this was the most snow that I had ever seen before!
Today I finally managed to get some real work done. I am using a new version of Ogitor that changes how scene files are exported and naturally that meant I had to do a bit of a recode on my scene loader. The good news is that now the scene loader is more standardized than it was so it should be the last time that I have to change it too much. Still to be on the safe side I would like to refactor the code some to make it easier to change.
Additionally in today's screenshot you will see a crate that I was playing with a few journal entries ago. This crate is actually going to be a standin "actor". I am going to be using this crate and it's interaction with the level to implement physics. The first goal is to get the crate moving and interacting with the scene and then I want to make the camera as the crate instead. Essentially it is breaking the problem down and eliminating potential problems. By focusing on making a crate move with physics I can focus on a small subset of issues and then work on a physics based first person camera implementation.
Speaking of physics, I keep bouncing back and forth between ideas of which physics engine to use. The natural inclination is to use whichever one has the working demos in my current release of Python Ogre, but from a sanity point of view the best choice is probably going to be Bullet. Bullet is a popular physics engine, it supports the Collada format (a big plus), and it is all around the physics engine that I am most impressed with upon looking at ODE, Bullet, and Newton. However the problem is that the Bullet demos for Python Ogre are broken... It is a bit of a risk because I like using libraries that have working demos but I am going to go ahead and try Bullet.
In terms of implementing the physics libraries the plan is to write a class where all of the physics binding is done and that the program calls whenever it needs to do anything related to physics... It is just going to be a bunch of methods that I build up over time and that the class will have the responsibility to implement. The plan is to make a base class and then inherit a class based on whatever physics engine I am using... This will allow me in theory to change physics engines if needed without requiring a ton of hard work and tracing through tons of code.
I also need to do some research into Blender and Collada. As appealing as trying to write a physics plugin for Ogitor is, I would rather avoid that whole mess if possible... I am sure with a bit of research I might be able to save a ton of time for myself and this project... But the first step is to get the crate in that picture to fall down with gravity and hit the "floor". That is my goal... It is my mission...and it will be accomplished!
A box shape is probably the easiest to implement. The difficult part will be turning your "level" geometry into physics geometry (i.e. Triangle Mesh shape)
Lastly, your idea of creating a base physics class and different implentations of it for different physics engines should work. The main issue is that you'll probably end up needing lots of classes. I'd say it'd be better to work the other way around and only add the base class later if you need to switch physics engines.
Did you see my comment on another of your about a simple first person character controller using Ogre on your February 5 entry?