Load, Follow, or Get Out of the Way

By Judy Hartley (Intel) (11 posts) on September 29, 2009 at 9:01 am

p>Hi again, everyone. This is my 5th blog on my project of porting a DirectX interactive demo to OpenGL. The name of the demo I am porting is “Destroy the Castle”. I call it “OpenGL Castle Destruction” in the OpenGL version. A list of my previous blogs on this topic can be found at the bottom of this blog.

If you have been following along with me as I continue to develop this application, you know that I have started using OpenSceneGraph (OSG) as a method for loading and displaying all of the many objects I need to have for the demo. I mentioned in the last blog that I was able to load all of the object files into my OpenGL application with the use of OSG. What I didn’t tell you was that the time to load all of these files was terrible. In this case, it was taking upwards to 10 minutes before the scene was drawn and the application ready. I had to find a better way to load my objects.

After doing some research on loading the .x files directly with OSG (yes, this is possible, although I found that the .x files I have are not compatible with the .x file loader that OSG currently has), I found another tool provided by OSG called osgconv. This tool converts other formatted graphics files into “.ive” files, which is an OSG proprietary native binary format. Another neat thing about the tool osgconv is that you can convert many .obj files into one .ive file. Oh, it’s so easy to say that, but it did take me a while to figure out how to do it. I have over 400 separate blocks that make up the castle, and osgconv is a command line tool. I tried opening a text file and setting up the command in the file first, then copying and pasting to the command line. It didn’t work the first time. It didn’t work the second time I tried, either, after making some adjustments. There were just too many files. Finally, I decided to convert 10 blocks at a time. That resulted in almost 50 files. Then I combined those files into one big .ive file. That did the job. Now, with all my objects converted into .ive files, guess how long it takes my application to start? Less than 2 seconds! Awesome!

Ok, so the objects are loading fast and I now have the home view I want (see previous blog). Next step was to anchor the scene so that first the cannon was centered in the scene and then fix it so the cannon rotates and move up and down based on the movements of the mouse.

I solved this step in two sections. First, by setting up my camera so that it follows the cannon as it moves. OSG has quite a few camera manipulators in its API, and hundreds of functions. While my main irritation with OSG remains the lack of references WITH EXAMPLES, they do have some tutorials that are useful to help you learn how to use all the tools available within OSG. One of those tutorials shows how to set up a manipulator to follow a particular node or object. I used this implementation to set the camera to follow the cannon. Now all I had to do was get the cannon moving.

My first rudimentary implementation was simply to find the X and Y locations of the mouse and split the screen in half in both directions. It the mouse’s X location was greater than the half the screen length plus 10 percent, then I rotated the cannon a very small amount ( one tenth of a degree) in that direction. So then the cannon would move to the right if the mouse was clicked on the right-hand side of the screen and move to the left if the mouse was clicked on the left-hand side of the screen. If you clicked in the middle of the screen, the motion stopped. It worked, but it didn’t fulfill all of my requirements. Also, it would continue to move in the direction of the last click until the middle was clicked.

One of the really nice things about OSG is that it is open source. I was able to dip down into the manipulator code and see how mouse movement was handled there. This helped me to develop my second implementation. In this version, I calculate the angle that the cannon needs to be moved based on the X and Y coordinates of the mouse location (when it is moved or pushed, not just clicked ). To do this requires that you translate the X and Y mouse location into x, y and z coordinates and then get the angle that the cannon needs to be moved to face that location. It took me a while to figure out how it was done and even more time to take what I learned and adapt it to my code so the cannon follows the mouse. The code I am now using is in three parts (from three different files) and is shown below:

From the Matrix Manipulator Handle

From the Matrix Manipulator Handle

<

From the Handler function of PickHandler.cpp

From the Handler function of PickHandler.cpp


And Finally, the Code from the Cannon Callback Function

And Finally, the Code from the Cannon Callback Function


Last little section also from Cannon Callback Function

Last little section also from Cannon Callback Function


OpenGL Castle Destruction as it stands now

OpenGL Castle Destruction as it stands now

Until next time....

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"

Categories: Gaming, Open Source, Software Engineering, Uncategorized, Visual Computing

Comments (0)

Trackbacks (3)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*