A box is a box

Published February 13, 2010
Advertisement


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!
Previous Entry Crazy
0 likes 2 comments

Comments

zarfius
Getting the crate to fall shouldn't be a difficult task using any physics engine, the tricky part is setting up the inital physics engine in the first place. There's usually a lot of code just for creating the root scene and game loop.

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?
February 14, 2010 03:11 AM
shadowisadog
Hey Zarfius,

Yeah that is sort of what I had assumed.. I am thinking for right now that I am going to try to avoid using triangle mesh for my level geometry and instead use basic collision primitives... My room right now can use cubes for the collision geometry.. Blender has Bullet built in and I am working on a Blender script to export the physics data to my own xml based format. The bad part about using DAE is then I would have to replace my entire system/Ogitor and write code to load the mesh data from that or otherwise I would have to duplicate a lot of data... I would personally rather just write my own exporter and have a separate physics file for each object that describes the collision geometry.

I just saw your post on my other journal entry when you mentioned it and I have responded to you :) .

Thank you for the tips and feedback! I have rated you up in thanks for your positive contributions.
February 14, 2010 10:49 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement

Latest Entries

Finished!

1588 views

Progress

1653 views

Resolve

1677 views

GUI

1830 views

Making a menu

2260 views

Teddystein!

1747 views

Doodles

1558 views

Tool overview

2129 views

Welcome!

1408 views
Advertisement