Posts Tagged ‘Programming’

The .obj file format, demystified

November 27, 2007

If you have ever thought of doing any 3D games programming, your first thought might be how the graphics are done. From the highly polished Final Fantasy games, to the abstract look of Geometry Wars, the answer varies. But more often than not, you would need to use visual assets that were made with other programs. For 3D modeling programs the formats widely vary, but out of all these, the .obj (or object) file format is the most generally accepted. Think of it like the PDF for 3D modelers. Most popular packages will support this format, so it’s easy to pass along without worring too much about what software others are using. The following text is an introduction for people that are not yet familiar with this format.

The .obj file format is one of the easiest to work with in programming 3D games, since .obj files are all text and the data is organized in a very straightforward manner. A typical .obj file would contain the following:

  • Vertex locations in x, y, and z coordinates
  • Texture mapping in u and v coordinates (optional)
  • Orientation of normals in x, y, and z coordinates (optional)
  • Face represented by a set of one or more indices

An .obj file can have either texture or normal data, but it must always carry vertex data. They are represented as an array of values, each line being a new entry in the array. This line starts with “v” followed by the coordinates. Optionally, you have lines for the vertex texture data (starts with “vt”) and vertex normals (starts with “vn”). Near the end of the file, the face data is represented, as a group of integers. Each line starts with “f”, and each number corresponds to the item on the data list in the order that it’s displayed. A line containing the numbers “1 4 3” correspond to the 1st, 4th and 3rd entries of that data group. There’s something important to note here: There is no index numbered “0”, so keep this in mind when parsing .obj files.

Each line contains indices for exactly one face, whether a triangle, quad, or other convex polygon. Furthermore, the indices can be grouped as single numbers, pairs, or triplets. The grouping depends on whether any texture or normal data is given. The following groups are possible:

"n n . . . n" - vertex location only
"n/n n/n . . . n/n" - location plus texture, or vertex plus normals
"n/n/n n/n/n . . . n/n/n" - location, texture, and normals

It should be clear that in a set of pairs or triplets, the location indices are listed first. Following that are the texture mapping coordinates and then the normal coordinates.

Finally, there might be some relevant information about grouping polygons into sets (lines starting with “g”) and usage of materials specified by the program that made the file (lines starting with “usemtl”). These may be used for programming model renderers, but they are not really crucial for displaying the geometry, so we won’t talk much about them here.

Well, that’s it for understanding the structure of .obj files. In a future post, I will show you how to apply this information to create your own .obj file parser.

Advertisements

Wanted: A Good Mapmaker

November 22, 2007

No, I’m not making a post about looking for good game mapping talent (though that wouldn’t hurt), but what I am talking about is the need for a way to make maps for my upcoming quick reflexy action-puzzler. My game has finally come this far to crave this need. So it’s time to do some extensive gameplay bug testing, which would be far easier if I can make any sort of game levels without having to go back every time to code in some more polygons and re-compile. It will be my first time making a game level editor of any sort, since my past projects weren’t complex enough to really need one.

I can take two approaches:
– Script the levels with my own easy-to-read syntax in a text editor
– A fully graphical editor, with a GUI, that produces the files (either text or binary will do)

Whatever way I choose I’ll have to build the file parser first. The graphical editor is more exciting but will take some more time. I’ve looked into CEGUI as a possible solution to building a level editor, which will then take advantage of having everything rendered in OpenGL and it will blend with the game as well. I really don’t want to tinker with the obfuscated (in my opinion) Windows API to handle the interface.

So I’ve already downloaded CEGUI and hoping to play with it soon enough. If anyone has any more suggestions, I’d like to hear ’em!

Other stuff along the way

November 13, 2007

While working on my PSP game, I’ve been thinking of continuing a few not-so-related projects.

First is PSPMyAdmin, which was supposed to be a tool to help you manage MySQL databases. Due to the lack of having a server on the PSP, the program uses SQL files and parses them to produce an image of the database structure. So it’s like editing an actual database, without the need to login or access a server. I’ve put this off a couple months ago but I could be returning to it, and use the Danzeff OSK with it. It would really cut down on time to make an interface for the program. I haven’t played with the source yet, but hopefully it should be easy to change its appearance to blend in with my program a bit more.

The next thing I’ve been working on is a simple OBJ parser. It’s based off the code from PSPMyAdmin so I got a head start there. Currently I’m working out some bugs with producing some vertex information, but it is almost done. This tool would actually be useful in helping others produce 3D homebrew games.

Code snippet – frame of collision

November 8, 2007

I whipped this little program in about an hour which helps you find the collision point of a circle to a line, and the normal in which it reflects. This principle works the same in 3D. You must have Java enabled in your browser to view the applet. The blue points connect the shortest distance between both lines, and the light blue circle shows the point of impact projected from the current path. Refreshing the applet makes a new random surface.

View applet

You can view the source files here: CircleLineCollision.pde Vert.pde
The code is written in Processing, but it’s easy to adapt to most common programming languages.

Keeping the ball rolling with this game

November 3, 2007

Screenshot

For my first Monkey Ball clone update, here’s a screenshot of what’s coming up so far. Last week I’ve tested some textures and using my own state manager display to handle the switching between parts of the game. That would be put aside until much later. And for obvious reasons, I won’t actually be using the monkeys in the game.

Right now I have to work on the controls. Using the PSP’s single joystick makes sense for tilting the level in this game, and already took care of the “dead zone” in the middle. I’m still not set at the maximum angles in which it should tilt, though. The camera would have to be just far enough so that the floor won’t completely obscure the player’s view. Using the camera to point where I want it to was easier than I thought.

As a test for the bounce, I have the ball falling from a great height to the floor and having the camera rotate to follow it. That worked pretty well. The actual tilt doesn’t move the ball, though. For debugging purposes, the ball is moved with the D-pad around a fixed camera. This creates a movement area where the player can circumnavigate with Left or Right, the preferred control scheme for a fixed camera. In practice, the camera would be following the moving ball as the floor is tilted. But more on how that will work for another day. Next on the list, polygonal collision detection. Hope you like math…