[Plugin] Import OBJ with Materials v2.1 20131118

[Jim]

Since Ruby has negative array indexes already, and the .obj is imported in at least a recognizable format, it may be something simple like an off-by-one error for negative indexes.

[jsteacy]

I tried all of them including the house bird, and nothing gets imported. This is what I get from the console after I click the units to import to:

Error; #<ArgumentError; Cannot convert argument to Sketchup;;Point3d>
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;278;in `add'
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;278;in `run'
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;278;in `map'
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;278;in `run'
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;208;in `each'
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;208;in `run'
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;329
C;/Program Files/Google/Google SketchUp 7/Plugins/obj_importer.rb;329;in `call'

hope that helps

[TIG]

So if the face-indices are 'negative' then we work backwards through the face vertex lists ? - i.e we reverse the array of v's, and take the abs value as the index ?

[Jim]

Line 248:

values.each do |v|
w = v.split("/")
vvv = Integer(w[0])
if vvv <= -2 # this 
  vvv += 1
end
face<<Integer(vvv)
face_uvs.push(w[1].to_i)if w[1]

And maybe look at fill_from_mesh instead of a dd_faces_from_mesh. # Line 302. Probably left over from someone else..

I'm shocked it actually seems to have worked - it was just a hunch.

[TIG]

Here's a slightly different version that I was working on independently - it also works !
http://forums.sketchucation.com/viewtopic.php?p=172790#p172790 [v1.7 has fill from mesh changes too]

[thomthom]

Any ideas what caused these glitches? http://forums.sketchucation.com/viewtopic.php?f=323&t=20584&start=75#p264875

[TIG]

Thomthom, I assume you are referring to the size/units ?
If the file has a '# units = meters' line then the importer defaults to 'meters' [or whatever it says].
If it doesn't then it defaults to 'inches'.
However, as it starts a dialog lets you choose whatever units you'd like to use anyway [preset to those default units].
Some meshes don't form the tiny faces if the units are set too small - e.g. if you were to choose 'mm' when it was made in 'meters'. So if you are unclear about the units and none are specified then you can try out alternatives until you get a proper mesh without holes...
The reason the tool has three options is speed - 'as mesh' is fast but can fail when the OBJ code is convoluted; otherwise the textures can be added or not as desired.
The old sizing issue seems resolved.
PS: I can't tested your problem 'van' OBJ/MTL because PPartner010000.jpg wasn't in the zip file?
But I can see that its geometry seems a bit messed up around the side windows and the image file-names have spaces in them which confuses the MTL parser. I thought that you were 'recommended' to avoid having spaces in these paths/names - however, manually editing the MTL and the corresponding image-names so they are without spaces fixes that... BUT the 'PPartner010000.jpg' file is still missing altogether - see the Ruby Console error reporting

[TIG]

Busy today! Heres 1.8 - Trapped for spaces in image-names/paths.
http://forums.sketchucation.com/viewtopic.php?p=172790#p172790

[thomthom]

@tig said:

Thomthom, I assume you are referring to the size/units ?

No - it was the messed up geometry you noticed. You see it in the screenshots I posted - with the red circles.

@tig said:

PS: I can't tested your problem 'van' OBJ/MTL because PPartner010000.jpg wasn't in the zip file?
But I can see that its geometry seems a bit messed up around the side windows and the image file-names have spaces in them which confuses the MTL parser. I thought that you were 'recommended' to avoid having spaces in these paths/names - however, manually editing the MTL and the corresponding image-names so they are without spaces fixes that... BUT the 'PPartner010000.jpg' file is still missing altogether - see the Ruby Console error reporting

The OBJ was initially created by SketchUp - then edited textures in PhotoShop.

I've attached the missing texture.

Will try v 1.8

---

[thomthom]

Even with 1.8 some geometry is messed up. Seem to be the same faces.

[TIG]

I see the messed up UV textures.
I re-imported it as 'mm' and the messed geometry went.
BUT I had to edit the faulty UV mapped parts manually.
As it's symmetrical a quick mirror/copy of the correct panel on the other side fixed them.
The 'Badge' is messed up though - did you map that on separately ?
I've no idea why just those few parts fail to map properly
VAN.skp

[thomthom]

I import in mm - but it's not just the UV being messed up. It's the actual geometry.
Notice that for the incorrect mapping the face is split diagonally-crossing itself - as opposed to the mirrored side.
When you compare against the 3ds import you see that Max does not do this.

I did not do anything to the mapping other than take the OBS into PS and adding the text on the side of the van. The model came from a pre-modelled and pre-mapped third party model.

I wonder if it's the order of the vertices that's abnormal in these cases... ?

[TIG]

The cross-threading of the faces' vertices into 'bowtie' triangles - which then probably mess up the UV-mapping - must be in the OBJ file itself [?].
The OBJ Importer simply uses the f n/n nn/nn/ nnn/nnn... values to form the faces and mapping ? Unfortunately unless you can reproduce the problem in a file with relatively few faces it'll be all but impossible to plough through the data to find the problem instances... [+460+ faces here?].
I was hoping that the OBJ had some -ve face indices that were causing the problem which recent versions might have solved... but NO!
In SUp export the ordering of a face's vertices shouldn't be a problem as they should always return ordered, and in the correct 'clockwise-ness' for the face's normal direct ?

[Jim]

The vertexes in the 'f' line are out of order for whatever reason.

Creates a "bow tie":

Sketchup.active_model.entities.add_face([0,0], [1,1], [1,0], [0,1])

[thomthom]

So it's the OBJ data that's invalid... but Max manage to deal with it somehow.

I'll compare against the raw output from SU and see if it's SU or PS that mangles the geometry.

[thomthom]

It's SU generating the odd vertex order. Here's the OBJ directly from SU:

---

SU Export

[TIG]

Could you PM me the original textured SKP - I have a new embryonic OBJ-Exporter that might NOT do this glitch ?

[notareal]

Here is a model that seems to fail http://www.fileden.com/files/2009/5/30/2461193//dragon_scene_OBJ.rar (From CGTalk Frosted Glass Challenge). Maybe it's a bit large... but simlab obj importer seems to handle it.

[honoluludesktop]

TIG, Wow, nice piece of code. Lots stuff I have to learn, like next, case, when, def file.run(par1, par2), etc. Makes the code look more compact and easy to read. Oh well, if I looked here before starting what I am working on, I may not have understood:-)

Some of the stuff that's driving me nuts when writing importers, is that different exporters do not format the data exactly. SU's DxfIn treats "10", and " 10" equally, and many exporters ignore the convention that is " 10". I don't know if I should go back and fix my code to read "10" or not. It's no problem for my use, and would like to "share", but am concerned about posting something that may not work for some.

[TIG]

honoluludesktop
A DXF has alternating lines for 'code' and 'value'.
So if it's an odd-numbered line then it's always 'code' and if it's an even-numbered line it's always the previous line's code's 'value'...
It's a DXF convention to indent the 'code' number, BUT it's not necessary and any importer should strip off leading spaces anyway...

  0
SECTION
  2
HEADER
  9
etc

is the same as

0
SECTION
2
HEADER
9
etc

To see a DXF 'parser' look at my DXF Text Importer http://forums.sketchucation.com/viewtopic.php?p=194488#p194488