Sunday, December 28, 2008

Wavefront OBJ Loader - Another Update


As you can see from the picture above, UV texture mapping is still not working. I'm honestly a little stumped on this right now - I've tried mapping UV coordinates to ST coordinates in different ways, but have never gotten the UV working right, and any attempt to map from UV to ST coordinates screws up the objects that are not UV mapped.

I don't see anything in the Wavefront file specification that talks about using different kinds of texture coordinates, nor do I see any difference in the OBJ file for the UV textured cube than the other objects. This leads me to think that my mistake might be in the creation of the object, rather than in my code, though I'm not certain of that by any means.

Unfortunately, I have to buckle down on some other things for the next few days and need to take a break from this project. I have an end-of-year deadline rapidly approaching, followed a few days later by a week-long trip to San Francisco for Macworld, so I probably won't be making any more changes to this for at least a week or two.

Here is the current version of the project. If anyone else figures out what I'm doing wrong with regards to UV texture mapping, please let me know. Note: There was a file missing from the first version of the zip file. If your project doesn't compile, try re-downloading the zip.

Here are the things I'd like to accomplish before I abandon this class:

  • Get UV texture mapping working

  • Switch to using VBOs for performance


It seems to me that there was at least one more thing I wanted to do with this class before stopping work on it, but it's escaping me.

There are a few warnings and gotchas with regard to this version:

Textures: both .png and .pvr4 files are supported. As always, .pvr4 files are recommended. Because of the differences in creating a texture from a compressed image versus an uncompressed one, I had to implement a little hack. If you are using a .pvr4 file, you need to include the resolution in the filename, because there's no easy way to determine the width and height of a .pvr4 file that I know of. So, if you have texture.png, and you create a 512x512 compressed texture, you should call it texture-512.pvr4. The class will automatically scan for the compressed texture using the base filename from the .mtl file before giving up and trying to load the uncompressed file specified in the .mtl file. If you don't remember how to create .pvr4 textures, you might want to re-visit this earlier posting.

Performance: If you run this on a device, it will be very slow, especially if you run it on a first generation Pod or iPhone Touch. I've been mostly working in the simulator for speed, and this app is nothing more than a testbed and tech demo. You have been warned. In general, you probably want to avoid models as complex as the plane, especially for games - if you comment out the code that loads the plane model, the performance gets much, much better and the load time reduces greatly.

Vertex Coordinates: In order to calculate the unique combinations of vertex index and texture coordinate index, I implemented a binary search tree. My first version used Cocoa collection classes and wrapper classes to keep track of the combinations, but that was to slow. This is just another friendly reminder that all of C is available to you, and sometimes it makes sense to use the lower level stuff and skip the NSxxx classes.

As always, if you find bugs or make improvements, I would love to hear from you and maybe incorporate your changes into the class. I haven't decided on the final license this will be released under, but it will definitely be non-viral, probably the BSD license or MIT license. Basically, you can feel free to use it in any project, personal or commercial, without attribution or payment. The only thing I ask is that you don't claim credit for the part I wrote.

No comments:

Post a Comment