The obj file goes in your /sdcard folder, you can send it via DDMS to the phone. If you're doing emulator instead, read up on android's site about creating a sdcard in the emu. The obj file was made and exported in Maya, it is a simple 8 slice by 8 slice sphere. I kept it this low to reduce the file size and loading time, which is roughly 13kb.

Synopsis

I had the OBJ loader working correctly but my renderer wasn't displaying it. I grabbed Google's Kube example on the android sdk site and used that instead and voila my sphere appeared!!!

It isn't textured yet, and it shows up as just a black sphere on a grey background. Using the kube framework isn't as efficient as it could be if I held the buffers directly, as my original example did. Even with my original code, large meshes were a problem because I had to use an arraylist to initially parse the data. I still use that arraylist to parse out all the vertices before passing it all to the GLShapes. I'm not really sure how to get around this.

Suffice it to say this loads magnitudes slower but at least I can see it now. You have no idea how exhilarating it was to see that black sphere show up.

I'm sure by releasing this here, others will be able to take it even farther than I. I'll keep trying to enhance it.

For anyone who doesn't know, OBJ is sort of the defacto rudimentary 3D mesh format that all 3D modellers can export and that is lightweight to load. It doesn't support by default any concepts of animation, skinning, shaders, etc. Which, if you think about it, makes it the perfect for mobile phones that need a simple mesh format. There's a lot of potential here. Hope this helps someone out!

Note: I made the mistake of using my particles project and didn't rename Particles.java (where the main activity is) when I rewrote it to load obj files. Sorry about that.

Here's the file on rapidshare in a 7zip archive just in case this forum goes down and you find this post on google cache or something lol:

http://rapidshare.com/files/183773190/objloader.7z

Aw, just noticed someone not only beat me to it, but did it better. Though, not sure how his performs. Some of the things he's doing in his code seem wasteful of memory, which is precious as hell. However, he has support for textures, animations, multiple frame obj, md2 loading, etc. He does mention in his post that his code sometimes runs out of memory, this is probably because of how much memory he's willy nilly tossing about like its free. Not that my code is great, but I think not using a string tokenizer and just splitting the strings myself probably saved me a bit of memory.

http://code.google.com/p/android-gl/downloads/list

I found his comment here:
http://groups.google.com/group/android- ... 44629324cc

Unfortunately, his code is GPL.

Mine is under MIT (which means you can do anything you want with it, no warranty/no liability) so if anyone wants to use it for any purpose, no problems. Though, it isn't in great condition right now. But, it seems that since there are no non-GPL obj loaders for android, this might be worth my time (and others) to continue working on.

If you contribute anything back to my code here in this forum, don't take it from his, please.

Doesn't matter whether he was first or not, as long as you had fun .

Well, it is fun to code for this phone. I've done some interesting things with it, like a a voice that tells you who called when you miss a call (though I need to rewrite that as a service). This obj loader is just a means to an end really, I wanted to do some interesting 3D ideas I had but I just couldn't without more complex routines that just weren't in the sdk. On the bright side, I didn't really waste my time, his code is GPL'd which makes it useless really for anything serious.

He's doing:
StringTokenizer tok = new StringTokenizer(line);
tok.nextToken();
vertex[0] = Float.parseFloat(tok.nextToken());
vertex[1] = Float.parseFloat(tok.nextToken());
vertex[2] = Float.parseFloat(tok.nextToken());

I'm doing:

if (newline.charAt(0) == 'v' && newline.charAt(1) == ' ') {
coordstext = newline.split("\\s+");
for (int i = 1; i < coordstext.length; i++)
vcoords[i-1] = Float.valueOf(coordstext[i]).floatValue();
addVertex(vcoords[0], vcoords[1], vcoords[2]);
}

I'm not sure what StringTokenizer does, but it certainly has to be consuming more memory every time he reads a face. I'd have to time it to see how much faster the technique is and how much memory it uses.

Just found this website on performance issues in java, and the author points out that StringTokenizer is slooooowwwwwww. It is the 6th one on this page:
http://www.javacommerce.com/displaypage ... l&id=18264

palisade wrote:his code is GPL'd which makes it useless really for anything serious.

Uhm what??? That's the worst thing ever to say about GPL (though I get why you are saying it) . With your statement you say Android isn't serious .

What he does is basically the same what you do. As the string tokenize probably splits the String too at a specified character. I assume your way is better, you don't construct a new object, and searching for the split character is very easy, only the creation of the array could be slow.

There might be a way to optimize it further, but its going to be hard getting around the need to parse. Perhaps a program could be written that turns the obj into a binary file that is easier to parse. Or, it could be done on-the-fly, like Just In Time but for meshes.

Steps
1) Load the mesh from the slow obj the first time through.
2) Save the mesh, this time storing back to the file system in binary (afaik there's no binary format for OBJ files, but it wouldn't be hard to invent one)
3) When loading the obj again, check for the .bob file and if it is there, then there's a faster binary version.

Though, it might just make sense to convert all these to .bob on the PC before uploading to the phone anyways.

Why not use MD2 (or 3) for binary models.

Good point.

as my practice of loading OBJ models showed me - StringTokenizer is faster then split method.
but both of this methods are still slow so i compiled obj to a binary format (basically, read obj -let's say vertices - to intbuffer, and then write it to a binary file, later you can load this int buffer in no time)

hey friends,
i m fresher at android.i don't no about OBJ Mesh Loader would you send me some tutorial or screen shots that i can learn

mortefer wrote:as my practice of loading OBJ models showed me - StringTokenizer is faster then split method.
but both of this methods are still slow so i compiled obj to a binary format (basically, read obj -let's say vertices - to intbuffer, and then write it to a binary file, later you can load this int buffer in no time)

Isn't there some "standard" binary obj file structure?

Really, i don't know - i've just created what is convenient for me

mortefer wrote:Really, i don't know - i've just created what is convenient for me

I don't know either, I was just pondering out loud .

mortefer wrote:as my practice of loading OBJ models showed me - StringTokenizer is faster then split method.

According to the docs StringTokenizer is only there for legacy support and you should use split for this...