obj2rad failing

Hi all,

I am currently testing differrent converters with what you could call 'real-world' scene files originating from differrent CAD systems and modellers. While exploring the capabilities of obj2rad I noticed that it fails on a OBJ File (exported from ArchiCAD) with the following error:

example.obj: Wavefront syntax error near line 167037: Bad face

Here is the 'bad' part of the file (line 167037 - 167041)

f 29760/83929/29760 29761/83930/29761 29762/83931/29762 29763/83932/29763
vt 42.5353 8.46865
vt 42.5353 8.474
vt 42.53 8.474
vt 42.53 8.469

Other parts of the obj file work fine:

f 29682/83789 29683/83790 29684/83791 29685/83792
vt -0.019984 -0.400179
vt 8.56333 -0.400179
vt 8.58332 0
vt 0 0

The OBJ file format specification tells me that both 'f' lines are perfectly legal:

Using v, vt, and vn to represent geometric vertices, texture vertices,
and vertex normals, the statement would read:

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

But obj2rad doesn't seem to like the 3rd number(s) vn which are supposed to represent the vertex normals. The obj2rad man page doesn't go into much detail about the 'f' statement with respect to allowed format. Running obj2rad -f (ignoring vertex normal information) also fails on the exact same line.

I will try to get ahold of some smaller ArchiCAD OBJ exports now and see if I can narrow down the problem. If anyone has some ideas or similar experiences I would sure appreciate to hear from you!
TIA,
Erwin

Hi Erwin,

The problem with that face is that it refers to vertex normals 29760, 29761, and 29763, whereas you've only defined 544 normals up until that point in the file. It is illegal to refer to an undefined index in obj2rad, hence the reported error. None of the other OBJ file converters will like it, either. The faces up until that point in the file don't use vertex normals, so they pass without complaint.

-Greg

P.S. To those of you confused by this exchange, Erwin sent me his OBJ file in a separate e-mail at my request.

···

From: "Erwin Zierler" <[email protected]>
Date: October 7, 2008 3:19:01 PM PDT

Hi all,

I am currently testing differrent converters with what you could call 'real-world' scene files originating from differrent CAD systems and modellers. While exploring the capabilities of obj2rad I noticed that it fails on a OBJ File (exported from ArchiCAD) with the following error:

example.obj: Wavefront syntax error near line 167037: Bad face

Here is the 'bad' part of the file (line 167037 - 167041)

f 29760/83929/29760 29761/83930/29761 29762/83931/29762 29763/83932/29763
vt 42.5353 8.46865
vt 42.5353 8.474
vt 42.53 8.474
vt 42.53 8.469

Other parts of the obj file work fine:

f 29682/83789 29683/83790 29684/83791 29685/83792
vt -0.019984 -0.400179
vt 8.56333 -0.400179
vt 8.58332 0
vt 0 0

The OBJ file format specification tells me that both 'f' lines are perfectly legal:

Using v, vt, and vn to represent geometric vertices, texture vertices,
and vertex normals, the statement would read:

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

But obj2rad doesn't seem to like the 3rd number(s) vn which are supposed to represent the vertex normals. The obj2rad man page doesn't go into much detail about the 'f' statement with respect to allowed format. Running obj2rad -f (ignoring vertex normal information) also fails on the exact same line.

I will try to get ahold of some smaller ArchiCAD OBJ exports now and see if I can narrow down the problem. If anyone has some ideas or similar experiences I would sure appreciate to hear from you!
TIA,
Erwin

Hi Greg,

thanks for the investigation. This means that Archicad produces faulty OBJ files or something went wrong during the export. I will have to ask the folks who gave me the file. I tried importing this file into other modellers, some of them seem to ignore all faulty objects, and some of them import everything only up to that line. But I have not checked this out in great detail. Maybe I can implement some kind of syntax checker that does some sanity checks on obj files before I throw them at obj2rad. I guess my goal will be to import at least the geometry, even if the vn or vt info is not correct.
Regards,
Erwin

···

-------- Original Message --------
Subject: [Radiance-general] Re: obj2rad failing (08-Okt-2008 7:21)
From: Greg Ward <[email protected]>
To: [email protected]

Hi Erwin,

The problem with that face is that it refers to vertex normals 29760,
29761, and 29763, whereas you've only defined 544 normals up until
that point in the file. It is illegal to refer to an undefined index
in obj2rad, hence the reported error. None of the other OBJ file
converters will like it, either. The faces up until that point in
the file don't use vertex normals, so they pass without complaint.

-Greg

P.S. To those of you confused by this exchange, Erwin sent me his
OBJ file in a separate e-mail at my request.

> From: "Erwin Zierler" <[email protected]>
> Date: October 7, 2008 3:19:01 PM PDT
>
> Hi all,
>
> I am currently testing differrent converters with what you could
> call 'real-world' scene files originating from differrent CAD
> systems and modellers. While exploring the capabilities of obj2rad
> I noticed that it fails on a OBJ File (exported from ArchiCAD) with
> the following error:
>
> example.obj: Wavefront syntax error near line 167037: Bad face
>
> Here is the 'bad' part of the file (line 167037 - 167041)
>
> f 29760/83929/29760 29761/83930/29761 29762/83931/29762
> 29763/83932/29763
> vt 42.5353 8.46865
> vt 42.5353 8.474
> vt 42.53 8.474
> vt 42.53 8.469
>
> Other parts of the obj file work fine:
>
> f 29682/83789 29683/83790 29684/83791 29685/83792
> vt -0.019984 -0.400179
> vt 8.56333 -0.400179
> vt 8.58332 0
> vt 0 0
>
> The OBJ file format specification tells me that both 'f' lines are
> perfectly legal:
>
> Using v, vt, and vn to represent geometric vertices, texture vertices,
> and vertex normals, the statement would read:
>
> f v/vt/vn v/vt/vn v/vt/vn v/vt/vn
>
> But obj2rad doesn't seem to like the 3rd number(s) vn which are
> supposed to represent the vertex normals. The obj2rad man page
> doesn't go into much detail about the 'f' statement with respect to
> allowed format. Running obj2rad -f (ignoring vertex normal
> information) also fails on the exact same line.
>
> I will try to get ahold of some smaller ArchiCAD OBJ exports now
> and see if I can narrow down the problem. If anyone has some ideas
> or similar experiences I would sure appreciate to hear from you!
> TIA,
> Erwin

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

Hi Erwin,

Importing minus the vertex and textures can be done with this command:

  sed '/^f /s@/[0-9/]*@@g' Hauk-EZ.obj | obj2rad > Hauk-EZ.rad

Seems to work for me, at least.

-Greg

P.S. I also tried putting all the vertex normals at the front of the file, thinking maybe ACAD just scattered them throughout in violation of one of the Wavefront syntax restrictions, but there were still faces that referred to vertex normal indices that exceeded the total number of vertex normals in the file.

···

From: "Erwin Zierler" <[email protected]>
Date: October 7, 2008 11:44:42 PM PDT

Hi Greg,

thanks for the investigation. This means that Archicad produces faulty OBJ files or something went wrong during the export. I will have to ask the folks who gave me the file. I tried importing this file into other modellers, some of them seem to ignore all faulty objects, and some of them import everything only up to that line. But I have not checked this out in great detail. Maybe I can implement some kind of syntax checker that does some sanity checks on obj files before I throw them at obj2rad. I guess my goal will be to import at least the geometry, even if the vn or vt info is not correct.
Regards,
Erwin