Hello Chaps,

I've been trying out obj importing into an ArticulatedModel using
fromFile using a simple textured cube generated in Blender 2.61. The
log file opens the obj geometry OK, but reports that the material file
cannot be found. It shows the reported path includes an erroneous
space in front of the file name, which breaks the path. Sure enough,
when I debug in, the TextInput class in ArticulatedModel::initOBJ
correctly identifies the 'mtllib' token but returns the whole of the
remaining line (including the whitespace separation between the token
and the value). This is then appended (with no trimming) to the root
path for the file operation, resulting in an incorrect file path.

This *appears* to be quite a fundamental problem with OBJ loading, but
I can't find anything obvious when searching this forum, which makes
me suspect that I must be the one doing something wrong here? Any
advice gratefully received.

The offending obj file contents are as follows (.obj, followed
by .mtl):

# Blender v2.61 (sub 0) OBJ File: ''
# www.blender.org
mtllib untitled.mtl
o 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 1.000000 -0.999999
v 0.999999 1.000000 1.000001
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

and:

# Blender MTL File: ''
# Material Count: 1
newmtl Material
Ns 96.078431
Ka 0.000000 0.000000 0.000000
Kd 0.640000 0.640000 0.640000
Ks 0.500000 0.500000 0.500000
Ni 1.000000
d 1.000000
illum 2

Cheers

E

I rewrote the OBJ loader from scratch for 9.00; it is now very robust.
 I recommend:

* Upgrade your G3D
* Port the 9.00 loader backwards (it is a standalone class, ParseOBJ)
* Try ASSIMP

-m

Prof. Morgan McGuire
Computer Science Department
Williams College
http://cs.williams.edu/~morgan

Many thanks for the quick response Morgan - you've obviously saved me
from flogging a bit of a dead horse!

I rather want to keep graphics card requirements to a minimum with my
projects, so I'm going to stick to G3D 8 and have a go at porting the
ParseX classes as you suggest, (although ASSIMP does look like a great
project too, thanks for that tip).

I'll let you know how I get on, in case anyone else is interested in
the outcome. Cheers,

E

Hi Morgan,

Bit of a epic, but I successfully got the new OBJ loading up and
running in G3D8 last night - I've learned a lot on the way!

Unfortunately... you're not going to like me... because *I think*
there is a small problem with the latest parseMTL (BETA3), which might
still be worth taking a look at in your G3D 9 branch. Blender pumps
out a few empty lines at the end of its MTL files (easily reproduce-
able by hand) and this causes TextInput to throw an unhandled
exception during ParseMTL::parse. I've resolved this locally by
sticking ti.readSymbol(); in a try/catch block that swallows the lot -
but obviously this is a bit crap :)

I hope this is still useful info and I'm not becoming too irritating!

E

Bug reports are greatly valued.  Can you send me a simple OBJ + MTL that
hits the bug?

Note that TextInput did change a little between 8.01 and 9.00--I recall
squashing at least one bug related to exactly this problem, and may have
done so by changing the way that hasNext() works.

-m

Prof. Morgan McGuire
Computer Science Department
Williams College
http://cs.williams.edu/~morgan

Morgan kindly tested my file on the latest version and confirmed the
bug is squashed :), but I thought I'd just update this thread for the
benefit of other readers who might be using Blender.

The fix actually turned out to be in ParseMTL, which now checks and
ignores the Token::END's caused by the blank lines, but this must have
just missed the G3D 9 Beta 3 release I had initially been using. A
slooow SVN checkout of the bleeding edge code, followed by a very
quick file copy of ParseMTL.h/.cpp and everything is working really
well.

Thanks again for the great support.

E