OBJ mesh loader!! YAY!!!! I DID IT!

Quickly share your Android Code Snippets here...

OBJ mesh loader!! YAY!!!! I DID IT!

Postby palisade » Thu Jan 15, 2009 6:45 pm

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. :D

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.
Attachments
OBJLoader.zip
(120.27 KiB) Downloaded 1512 times
Last edited by palisade on Thu Jan 15, 2009 7:15 pm, edited 1 time in total.
palisade
Freshman
Freshman
 
Posts: 8
Joined: Thu Jan 08, 2009 11:24 pm

Top

Re: OBJ mesh loader!! YAY!!!! I DID IT!

Postby palisade » Thu Jan 15, 2009 6:46 pm

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
palisade
Freshman
Freshman
 
Posts: 8
Joined: Thu Jan 08, 2009 11:24 pm

Re: OBJ mesh loader!! YAY!!!! I DID IT!

Postby palisade » Thu Jan 15, 2009 7:14 pm

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.
palisade
Freshman
Freshman
 
Posts: 8
Joined: Thu Jan 08, 2009 11:24 pm

Postby MrSnowflake » Thu Jan 15, 2009 7:17 pm

Doesn't matter whether he was first or not, as long as you had fun :).
User avatar
MrSnowflake
Moderator
Moderator
 
Posts: 1439
Joined: Sat Feb 16, 2008 3:11 pm
Location: Flanders, Belgium

Postby palisade » Thu Jan 15, 2009 7:19 pm

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
Freshman
Freshman
 
Posts: 8
Joined: Thu Jan 08, 2009 11:24 pm

Postby MrSnowflake » Thu Jan 15, 2009 8:17 pm

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.
User avatar
MrSnowflake
Moderator
Moderator
 
Posts: 1439
Joined: Sat Feb 16, 2008 3:11 pm
Location: Flanders, Belgium

Top

Postby palisade » Thu Jan 15, 2009 8:47 pm

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.
palisade
Freshman
Freshman
 
Posts: 8
Joined: Thu Jan 08, 2009 11:24 pm

Postby MrSnowflake » Thu Jan 15, 2009 8:52 pm

Why not use MD2 (or 3) for binary models.
User avatar
MrSnowflake
Moderator
Moderator
 
Posts: 1439
Joined: Sat Feb 16, 2008 3:11 pm
Location: Flanders, Belgium

Postby palisade » Thu Jan 15, 2009 9:14 pm

Good point.
palisade
Freshman
Freshman
 
Posts: 8
Joined: Thu Jan 08, 2009 11:24 pm

Postby mortefer » Thu Jan 15, 2009 11:51 pm

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)
mortefer
Experienced Developer
Experienced Developer
 
Posts: 54
Joined: Sat Dec 20, 2008 11:24 am

Postby kali » Wed Jan 28, 2009 7:20 am

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 :roll:
kali
Experienced Developer
Experienced Developer
 
Posts: 62
Joined: Tue Jan 27, 2009 1:31 pm

Postby MrSnowflake » Thu Jan 29, 2009 10:48 am

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?
User avatar
MrSnowflake
Moderator
Moderator
 
Posts: 1439
Joined: Sat Feb 16, 2008 3:11 pm
Location: Flanders, Belgium

Postby mortefer » Thu Jan 29, 2009 11:12 am

Really, i don't know - i've just created what is convenient for me
mortefer
Experienced Developer
Experienced Developer
 
Posts: 54
Joined: Sat Dec 20, 2008 11:24 am

Postby MrSnowflake » Thu Jan 29, 2009 11:42 am

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 :).
User avatar
MrSnowflake
Moderator
Moderator
 
Posts: 1439
Joined: Sat Feb 16, 2008 3:11 pm
Location: Flanders, Belgium

Postby MrSnowflake » Thu Feb 05, 2009 4:42 pm

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...
User avatar
MrSnowflake
Moderator
Moderator
 
Posts: 1439
Joined: Sat Feb 16, 2008 3:11 pm
Location: Flanders, Belgium

Top

Return to Code Snippets for Android

Who is online

Users browsing this forum: No registered users and 4 guests