wavefront obj import - why can only one of these two import?

I have wavefront obj two files pasted below.

They are actually the same cone. One exported out of Carrara, the other that same object then imported into ‘Daz|Studio’ and re-exported.

The first will not import into Blender when I use the included script for wavefront import. The second imports just fine.

The first will import if I use the script here:
http://jmsoler.free.fr/util/blenderfile/py/obj_io_modif232b.py
But imports as an invisible object. I can’t find it with zooming, nor with scaling up or down.

Any thoughts on what aspect of their differences is killing the Carrara version?

4x3cone.obj - fails to import

Created By Carrara 5.0

Number of vertices: 13

v 5 3.535534 3.535534
v 5 3.535534 -3.535534
v 5 -3.535534 -3.535533
v 5 -3.535533 3.535535
v 1.666667 2.357023 2.357023
v 1.666667 2.357023 -2.357023
v 1.666667 -2.357023 -2.357022
v 1.666667 -2.357022 2.357023
v -1.666667 1.178511 1.178511
v -1.666667 1.178511 -1.178511
v -1.666667 -1.178512 -1.178511
v -1.666667 -1.178511 1.178512
v -5 0 0

Number of normals: 17

vn -0.445347 0.694349 0.565283
vn 1 0 0
vn -0.445347 0.565283 -0.694349
vn 1 0 0
vn -0.445347 -0.694349 -0.565283
vn 1 0 0
vn -0.445347 -0.565283 0.694349
vn 1 0 0
vn -0.446236 0.584342 0.677804
vn -0.446236 0.677804 -0.584342
vn -0.446236 -0.584342 -0.677804
vn -0.446236 -0.677804 0.584342
vn -0.443408 0.535027 0.719121
vn -0.443408 0.719121 -0.535027
vn -0.443408 -0.535027 -0.719121
vn -0.443408 -0.719121 0.535028
vn -1 0 0

Number of texture vertices: 17

vt 0.402043 0.666667
vt 0.402043 0.666667
vt 0.597957 0.666667
vt 0.597957 0.666667
vt 0.597957 0.333333
vt 0.597957 0.333333
vt 0.402043 0.333333
vt 0.402043 0.333333
vt 0.347957 0.717953
vt 0.652043 0.717953
vt 0.652043 0.282047
vt 0.347957 0.282047
vt 0.097957 0.666667
vt 0.902043 0.666667
vt 0.902043 0.333333
vt 0.097957 0.333333
vt 1 0.5

g Vertex_Object
usemtl Texture_0

Number of Polygons: 13

f 1/1/1 2/3/3 6/10/10 5/9/9
f 2/3/3 3/5/5 7/11/11 6/10/10
f 3/5/5 4/7/7 8/12/12 7/11/11
f 4/7/7 1/1/1 5/9/9 8/12/12
f 5/9/9 6/10/10 10/14/14 9/13/13
f 6/10/10 7/11/11 11/15/15 10/14/14
f 7/11/11 8/12/12 12/16/16 11/15/15
f 8/12/12 5/9/9 9/13/13 12/16/16
f 13/17/17 9/13/13 10/14/14
f 13/17/17 10/14/14 11/15/15
f 13/17/17 11/15/15 12/16/16
f 13/17/17 12/16/16 9/13/13
f 4/8/8 3/6/6 2/4/4 1/2/2

4x3cone2.obj - imports just fine

Exported from DAZ|Studio 1.2.0.1

mtllib 4x3cone2.mtl

o 4x3cone
v 0.20505251 0.14499402 0.14499402
v 0.20505251 0.14499402 -0.14499402
v 0.20505251 -0.14499402 -0.14499399
v 0.20505251 -0.14499399 0.14499408
v 0.068350844 0.096662693 0.096662693
v 0.068350844 0.096662693 -0.096662693
v 0.068350844 -0.096662693 -0.096662641
v 0.068350844 -0.096662641 0.096662693
v -0.068350844 0.04833132 0.04833132
v -0.068350844 0.04833132 -0.04833132
v -0.068350844 -0.048331369 -0.04833132
v -0.068350844 -0.04833132 0.048331369
v -0.20505251 0 0
vt 0.402043 0.666667
vt 0.402043 0.666667
vt 0.597957 0.666667
vt 0.597957 0.666667
vt 0.597957 0.333333
vt 0.597957 0.333333
vt 0.402043 0.333333
vt 0.402043 0.333333
vt 0.347957 0.717953
vt 0.652043 0.717953
vt 0.652043 0.282047
vt 0.347957 0.282047
vt 0.097957 0.666667
vt 0.902043 0.666667
vt 0.902043 0.333333
vt 0.097957 0.333333
vt 1 0.5
g 4x3cone
usemtl default
f 13/17 9/13 10/14
f 13/17 10/14 11/15
f 13/17 11/15 12/16
f 13/17 12/16 9/13
f 1/1 2/3 6/10 5/9
f 2/3 3/5 7/11 6/10
f 3/5 4/7 8/12 7/11
f 4/7 1/1 5/9 8/12
f 5/9 6/10 10/14 9/13
f 6/10 7/11 11/15 10/14
f 7/11 8/12 12/16 11/15
f 8/12 5/9 9/13 12/16
f 4/8 3/6 2/4 1/2

why is this in blender general?

why did you simultaneously post on blender.org?

what are the errors you get?

I know what you’re saying. A couple years ago I found that whatever version of Blender I was using wouldn’t import Wings3D .obj files, so I wrote a Java program to convert. I think the problem had to do with that one version started counting vertices and faces at 0, and the other started at 1. Also I think one used // to separate values and the other used /.

I don’t remember all the details, but the solution is to create the exact same object in Blender, export to a .obj and then find the elements that need to be changed to convert an outside version of .obj into something Blender can read. I recommend a cube instead of a cone because it’s a more regular object and will have fewer faces to deal with.

Then write a python script (or a program in some other language) to convert files to a form Blender can read.

Where else would it go other than general?

I didn’t see a forum for 'import/export questions, and this one was labeled as “Questions and Answers about Blender”.

Posted it in the other place, never got an answer, so posted here as well on the presumption of different crowds.

No errors, just with the one that doesn’t import, it claims the import is done and there there is nothing in the scene.

I check under the scene browser and that lists all the objects I have save for the item I had desired to import, and of course 3d-view is also empty.

Something in that data is just not ‘blender friendly’, and I’m wondering what so I can devise a method to avoid it. I’ve tried editing out all the derences in the two in a text editor - removing the ‘vn’ lines from the ‘bad one’, and adding ‘o’ and ‘g’ lines. No luck there…

I presume it is something about the numbers themselves… and if I could find out what, maybe I could set up Carrara to not export that way. :slight_smile:

-shrug-

Where else would it go other than general?

I didn’t see a forum for 'import/export questions, and this one was labeled as “Questions and Answers about Blender”.

Posted it in the other place, never got an answer, so posted here as well on the presumption of different crowds.

No errors, just with the one that doesn’t import, it claims the import is done and there there is nothing in the scene.

I check under the scene browser and that lists all the objects I have save for the item I had desired to import, and of course 3d-view is also empty.

Something in that data is just not ‘blender friendly’, and I’m wondering what so I can devise a method to avoid it. I’ve tried editing out all the derences in the two in a text editor - removing the ‘vn’ lines from the ‘bad one’, and adding ‘o’ and ‘g’ lines. No luck there…

I presume it is something about the numbers themselves… and if I could find out what, maybe I could set up Carrara to not export that way. :slight_smile:

-shrug-[/quote]

Um…did you read my earlier post?

Here’s a cube I exported from Blender as a .obj:

Blender v241 OBJ File: ShapeKeyTest.blend

www.blender3d.org

mtllib Cube.mtl
o Cube_Cube
v 1.000000 1.000000 -1.000000
v 1.000000 -1.000000 -1.000000
v -1.000000 -1.000000 -1.000000
v -1.000000 1.000000 -1.000000
v 1.000000 0.999999 1.000000
v 0.999999 -1.000001 1.000000
v -1.000000 -1.000000 1.000000
v -1.000000 1.000000 1.000000
usemtl Material
s off
f 1 2 3 4
f 5 8 7 6
f 1 5 6 2
f 2 6 7 3
f 3 7 8 4
f 5 1 4 8

Notice how the faces aren’t delimited with a /. Try modifying the file you want to import so that it looks like this one. Note: the numbers in the faces list correspond to the vertices listed above with the v.

As you said, the double ‘//’ is part of the key.

This seem to come down to blender’s included obj import script won’t import if there is data for normals, either the ‘vn’ lines, or the third entry in the ‘f’ lines.

Specifically:

One, blender will not import if there are lines for normals (‘vn’ lines)
Two, blender will not import if the face (‘f’) entries have either;
*** three numbers: 1/2/1
*** two numbers with two slashes: 1//1

Carrara exports with three numbers, Wings exports with two numbers and two slashes. But if Wings imports Carrara and then exports, it retains the Carrara method.

Oddly, a wings export was lacking the ‘vt’ lines…

I know how to auto-correct what wings is doing to Wings-native content… a search and replace can get that. The Carrara one is a bit trickier as I’m not so good with scripting something for wildcards. And the Carrara one is the one that is critical to my needs (Carrara has a very limited vertex modeler, but other parts of the app appeal to me, and I need to get content out of it into something I can work it in - Blender - and then later get it back in).

Plus, a script to remove all normals and to adjust all faces would get unwieldy when dealing with the import of file in the several megabyte range.

Daz|Studio, a free Poser knockoff application, with normally poor import and export, does seem to be able to convert things to a format Blender likes - so I may just have to put everything through it as a second stage until I stumble upon a working script or find a spare year of free time to learn a programming language (python)… :slight_smile:

But, at least I know -why- it is happening now, and as above, I can fiddle my way around that. :wink:

I’m glad you found the solution. Like I said, I came across this problem a while back, but I doubt I still have the conversion program I wrote. It was intended for Wings .obj files anyway, and now Wings files (last time I checked) work with blender, so no need for me to have that around.

By the way, Python is actually fairly simple to learn. The beginner’s tutorial on the python.org site got me up and running well enough until I broke down and bought a book for the finer points (I prefer to learn from a book, rather than a computer screen).

Best of luck with everything.

Some trivia I found while working on a script to import poser/daz.

Seems daz creates an incorrect face record, according to the wavefront obj file format doc.

A face record should be:

f v/vt/vn v/vt/vn v/vt/vn v/vt/vn

where v = vertex, vt = uv texture, vn = vertex normal. They are index numbers (no zero offset).

If you do not have any uv mappings then the correct format is:

f v//vn v//vn v//vn

daz is doing f v/vt. I found you can make it correct by always checking the box “export vertex normals”