4,391 Posts served

10,712 Conversations started

One Step Forward, Two Steps Back

By Judy Hartley (Intel) (13 posts) on December 8, 2009 at 10:25 am

It’s been a while since I’ve written a blog. I’ve wanted to, but when I blog I want to have something relevant to say. Makes sense, right? I’ve written 6 previous blogs on the same topic as this one, specifically, porting a DirectX demo to OpenGL with an eye on running it on a netbook eventually. You can find links to my previous blogs at the end of this one in case you want to start at the beginning or catch one you missed.
I was going gangbusters on implementing the animation and collision detection code in the DirectX code. I was able to get both Open Steer and ODE to compile as libraries in the project, and to get the main code to compile. Where I got stuck was in Linking. Originally, I got one error. One of the libraries couldn’t be found. When I fixed that, all of a sudden I had 11 linkage errors. Fixed some of them and got 3 more linkage errors than I had before. And so it went. After two weeks of intermittently fixing errors, searching for error meanings on the web, or generally trying things to fix the errors without success, I took two steps back and took another look at what I was attempting to accomplish.
I wanted to get approximately 100 bugs to run in and out and around the castle while it is being destroyed. I also want to be able to move the blocks that make up the castle as they are being hit by cannonballs. Thirdly, I want the bugs to avoid running “through” the blocks that have fallen down. If a cannonball or a block hits a bug, I want them to “die” and flatten as if they were smashed. Additionally, I want the cannonballs to act properly under the influence of “gravity”.
I was pretty much unfamiliar with both ODE and Open Steer, and although I did delve into the code a bit to figure out how it worked, I ran into trouble because the old version of code used in the DirectX “Castle” demo was significantly different from the newer versions available on the web. Using the older code exclusively seemed to work except for the linking difficulties.
I finally asked myself why I was trying to use other libraries when OSG has some API already in place for creating animation paths and handling collisions. The only thing I’m not sure it can do is handling the gravity. I’ve just looked it up on the site and there is a reference to gravity in the particle sections that may do what I need. I’ll just have to see.
So, what I’ve done now is to create one animation path that travels around the castle. The bug pauses at intervals and then moves on. I’ve tried it with more than one bug and because I set random times, it does pretty well. My plan is to develop at least 3 more paths and randomize their usage. That should make the bugs look fairly realistic. I took the picture below while the demo was running.

With One Animation Path Running With A Few Bugs

Update 12/7/09: I’ve now completed a second animation path and restructured the code so that the paths are now read from individual files. This allows me to easily change directions and angle percentages on the fly. I've posted a second picture below this paragraph. I’m currently working on a third path, and soon I will start putting in the collision code. It is very interesting work, but I’m finding it more and more difficult to set aside time to work on this project. I’m hopeful that I’ll be able to complete it near the start of 2010. I’ll blog again…

For those of you who missed the previous blogs, here are some links:

Blog 1: "Threaded Graphics to MID: A New Journey"
Blog 2: "From DirectX to OpenGL - Wheels Up"
Blog 3: "OpenGL Graphic Formats and Conversion"
Blog 4: "Scene Graphs and Instancing"
Blog 5: "Load, Follow, or Get Out of the Way"
Blog 6: "Round and Round, In and Out"

With 3 Animation Paths Going

Categories: Uncategorized

For more complete information about compiler optimizations, see our Optimization Notice.

Comments (0)

Trackbacks (0)

Leave a comment