I am trying to import a .OBJ model from Blender into my android project. I was trying using the open source of earth live wallpaper for my OBJ reader. I am trying to import vectors, normals, textures, and faces. The OBJ imports, but it seems the faces are either incomplete or at least out of order. Even using a basic cube mesh, certain faces just don't display correctly. All of the vertices appear to be there, textures and normals show up, however with the faces being out of place I cannot see if they are correct. Using Blender 2.4.9b, I have tried making faces into triangles, and about every combination of button on the export options to get it right.

You can see the import code I am using here -

http://code.google.com/p/earth-live-wal ... phere.java

It is under the private void loadObj()

I am not sure if there is an issue with the code, or with my OBJ file. Perhaps if someone could help me make sure I am exporting it correctly I could determine if my problem lies in the export of the OBJ, or importing into OpenGL.

Any help would be greatly appreciated, and if you need any further information just let me know.
Thanks in advance!

JM33 wrote:I am trying to import a .OBJ model from Blender into my android project. I was trying using the open source of earth live wallpaper for my OBJ reader. I am trying to import vectors, normals, textures, and faces. The OBJ imports, but it seems the faces are either incomplete or at least out of order. Even using a basic cube mesh, certain faces just don't display correctly. All of the vertices appear to be there, textures and normals show up, however with the faces being out of place I cannot see if they are correct. Using Blender 2.4.9b, I have tried making faces into triangles, and about every combination of button on the export options to get it right.

You can see the import code I am using here -

http://code.google.com/p/earth-live-wal ... phere.java

It is under the private void loadObj()

I am not sure if there is an issue with the code, or with my OBJ file. Perhaps if someone could help me make sure I am exporting it correctly I could determine if my problem lies in the export of the OBJ, or importing into OpenGL.

Any help would be greatly appreciated, and if you need any further information just let me know.
Thanks in advance!

Not sure if this is your problem but this is my guess ...

I took a quick look at that code. Seems like it only works if your faces have all three indices vertex/uv/normal. Check your obj file and make sure that ALL the "f" entries look something like this:

f 1/1/1 2/1/5 4/2/5

If they don't, you may be able to make Blender output the file so that they all do or you may have to fix the code so that it can take face definitions without all three indices.

Regards

I was having the exact same problem with you when trying out the code from Earth Live Wallpaper.

First of all, I think the code assumes that the mesh was triangulated when saved. There's a button for triangulation when you export a .obj from Blender.

I have not been able to figure out why the vertices get jumbled. If you study the code, you basically end up with all the vertices in order, so the index buffer is just a string of ints from 0 to the number of faces minus one. So, you actually don't need to use drawElements. You can just use drawArrays, and it works! This leads me to think there is something wrong with the ordering of the indexBuffer, but I haven't figured it out yet. Probably don't have to though, because I don't think there's any reason to use drawElements with this code.

Thanks for the replies guys. I had fixed the issue, but I am not real sure what my problem was. I ended up just copying over the loadObj() again. I changed a few other things back and forth in my code just before that, so I am not sure the exact issue I was having, but I"ve got it working. I knew something had to be wrong on my side when I tried loading a one of the .obj files from the app. It had the same issue, and it obviously works with the app and code.

Anyways, the obj export settings I ended up using were only "Selection Only", "UV", "Normals", and "Keep Vertex Order". My UVs are inverted though, so maybe I will try triangulate to see if that helps. I"m just happy I got it working.

Thanks again!

I found the problem. Since they're using a CharBuffer for the indices, you need to use GL_UNSIGNED_SHORT as the type in drawElements. If you use unsigned byte or byte, the indices will be jumbled.

But I don't see the advantage of drawElements over drawArrays in this code. I might email the creator and ask.

This sound really familiar. I did this myself last week. One thing I noticed was the UV mapping in Blender the y-axis was inverted when i loaded my .obj model in opengl es. The easy solution for me was to included a vertcially flipped image in the drawable folder. Problem solved.

I recently found myself playing with OpenGL ES in Android as well, and found myself trying to import the obj files from Blender to Android. I personally have a hard time using someone else's code, so I couldn't use any of the object loaders, so I ended up writing my own program in C# that converts the obj file to arrays of vertices, normals, and indices. I'll port it to android soon, but the main part of writing/ understanding the code is understanding HOW the data is packed, and read. So far I'm just working with shapes and normals.

Using Blender:
File>Export>Wavefront obj File
Then click the checkboxes: Normals, and Triangulate (OpenGL ES uses triangles for everything instead of polygons). Then Export.

The data in the .objfile will look like this:

v 1.755419 1.311275 -0.107591
vn 0.251631 -0.268228 0.929912
f 494//489 504//489 506//489

the first line is the vertices, just add in commas, and remove the "v"
the second line is the normals, just add in commas and remove the "vn"
the third line is the faces/indices. This is where the main difference is.
the order is:
vertex/vertex-texture/vertex-normal
Since I dont have textures it is just
vertex//vertex-normal
NOTE Wavefront files index the arrays by 1, java uses 0 based arrays so you need to adjust the numerical order of each by -1.

float vertices[] = {
...
1.755419, 1.311275, -0.107591,
...
};

float normals[] = {
...
0.251631, -0.268228, 0.929912,
...
};

short indices[] = {
...
494, 504, 506,
...
};

After this, use the arrays in your code to generate your model.
Example:

thanks DMac,
I'm having trouble with the normals, everything else works fine.
Did you have to do anything special with them? I've created a linear ordering for the normal buffer by obtaining the 3 normal values described in the face line but the model's lighting appears wrong.

behelit wrote:thanks DMac,
I'm having trouble with the normals, everything else works fine.
Did you have to do anything special with them? I've created a linear ordering for the normal buffer by obtaining the 3 normal values described in the face line but the model's lighting appears wrong.

I'm not sure I understand 100% of what you mean. I did nothing with the normals, they are provided in the obj file. I too have my doubts of them sometimes, I'm looking into it currently. Make sure you click the checkbox "normals" and triangulate when saving the file as an obj file.

Whatever you discover, make sure to post here

Thanks DMac,

I have another question though. It is much easier as I am testing my OBJ files to use the loader than hard code all the vertices etc. each time I want to make a little change. Now when I have it finalized some of my objects are very large ~1.5mb. This is a lot of work to hard code, but the load time is cut way down. For example, a 911kb file loads in 26 seconds with the loader, and just 3 seconds by hard code. For 4 of these objects my initial load was almost 2 minutes with the loader so I would rather hard code it once it has been finalized.

What I am running into is that each java file only allows 65535 bytes (if i remember right). So I ended up having to split the vertices into 3 Classes, textures to 2, normals to 3, and faces to 8 Classes. What a mess!

Is there a better way to get around the size limitation? I thought about XML resources but the size limit was too small there also. Any ideas would be great.