[Plugin] Import OBJ with Materials v2.1 20131118

rombout · 23 Feb 2016, 22:06

Thanks for looking into it. My problem is that i got that timer showing with other models, but with this particular model it doesnt show. BLender doesnt seem to add it metric number, it was indeed meters.

PS why is using inch much faster than meters?

Could i use your tree_fix.rb to get the back material on the mesh?

This is not my model, i would use this as a proxy and use a 2d of this model

rombout · 23 Feb 2016, 22:59

I read somewhere back that someone was testing a updated loading info. Ive tried using his code but got some errors.

How can i change the update response, set it lower, so su is perhaps more responsive?

The normals etc are correct iin this model, they point upwards. Do you think if the dimensions/measurements are added in the OBJ file it would go faster?

TIG · 23 Feb 2016, 23:00

You could try the 'fix' rb - no promises...

Inches is probably quicker since the read number is taken as inches, otherwise it has to be converted to another unit-system.
Every vertex has x/y/z and there are lots of them so 100k processes add up time-wise !

There is the Fluid OBJ Importer, which is faster as it's written in C, but it is $$$...

rombout · 24 Feb 2016, 04:57

yes i know, but i always try the crapp out of free before im pushed for the payed.

But you dont have any idea why the count doesnt show up.

Im wondering though how i can get the model inside SU in inches than???

PS OBJ doesnt have a unit or dimension header, did some checkup about that. It only uses 1 1 1 but no measurement system. Thats whats causing all the fuzz about people importing huge models exported from different modelers

TIG · 24 Feb 2016, 11:37

Maybe it's a MAC thing ?
The status bar updating is known to slow down MAC processing compared to PC, so perhaps it's skipping it ??

An OBJ file has coordinate values set up for the vertices, in the form:
x y z
Although usually the OBJ's y & z axes are flipped when compared to a SKP - hence the plugin's final prompt to change them around.
The x/y/z values are set off from an 'origin' - just like in a SKP, so:
0 0 0
and
1 0 0
are ONE unit apart in the x direction.
A good OBJ has a line in its header, saying something like:
units = "meters"
My plugin looks for this and uses it as the default units.
If it's missing then it defaults to "inches" [the correct default for non-headed OBJs].
The ONE unit is then taken as the assumed distance - e.g. 1m or 1"
If you know it's a "meter" OBJ, then you should use meters and it then imports at the correct size.
If you assumed it's "inches" then it'll be far too small.

The problem in using a smaller sized unit that the coordinates specify can fall foul of the SketchUp tolerance issue. If two points are within 1/1000" then they are assumed coincident, and so the related edges/face is not made. So if it's a "meter" OBJ and two vertices are 0.001m apart, and you chose "meters", they will get processed and a small facet is created - since 1mm is considerably more than 1/1000" [actually ~39/1000"]. However, if you mistakenly chose "mm", then the calculations assume they are now 0.001mm apart and since this is considerably less than 1/1000" [], they are not processed.
The units used in the OBJ are converted into the correct size in the SKP, so if it's a "meter" OBJ and you are importing it into a SKP set up for "inches" it doesn't matter - the 1m tall object specified in the OBJ, is made 39.37..." tall in the SKP.
If you are uncertain of the dimensions used in an OBJ then I recommend using say "meters", since even if you are wrong, its over-sized geometry will get created, and you can always scale the imported geometry down to the correct size [using the Tapemeasure tool method]. But if you choose a tiny unit like mm when it is set up in m you will almost certainly get missing faces, not to mention that it will be 1000x too small !

Bob James · 24 Feb 2016, 17:25

@tig said:

Sorry @Bob I can't access that forum.
Can you précis it ?

Did it work ?

My post from Thea forum:

Today I bought FluidImporter Pro and used it on a model from TurboSquid. As TIG suggested, once I put all of the files in one folder (obj, mtl and tif), FluidImporter did a very fast job of importing the model into SU. I'm in the process of rendering each variation of the model in Presto AO. Then I'll convert them to Thea models and make SU proxies to use with Skatter.
The TurboSquid model also came in fbx so I gave that a try: MUCH faster import with FluidImporter Pro.

However, I've not been able to successfully import XFrog files in obj: just doesn't work. A real frustration since I have so many XFrog plant and tree models.

Of course the best of all worlds, IMO, would be an easy, efficient way to import fbx models directly into Thea and make proxies for SU. I don't think XFrog provides fbx (I may be wrong) but they're not the only makers of good plants and trees.

rombout · 25 Feb 2016, 02:58

@tig said:

Maybe it's a MAC thing ?
The status bar updating is known to slow down MAC processing compared to PC, so perhaps it's skipping it ??

An OBJ file has coordinate values set up for the vertices, in the form:
x y z
Although usually the OBJ's y & z axes are flipped when compared to a SKP - hence the plugin's final prompt to change them around.
The x/y/z values are set off from an 'origin' - just like in a SKP, so:
0 0 0
and
1 0 0
are ONE unit apart in the x direction.
A good OBJ has a line in its header, saying something like:
units = "meters"
My plugin looks for this and uses it as the default units.
If it's missing then it defaults to "inches" [the correct default for non-headed OBJs].
The ONE unit is then taken as the assumed distance - e.g. 1m or 1"
If you know it's a "meter" OBJ, then you should use meters and it then imports at the correct size.
If you assumed it's "inches" then it'll be far too small.

The problem in using a smaller sized unit that the coordinates specify can fall foul of the SketchUp tolerance issue. If two points are within 1/1000" then they are assumed coincident, and so the related edges/face is not made. So if it's a "meter" OBJ and two vertices are 0.001m apart, and you chose "meters", they will get processed and a small facet is created - since 1mm is considerably more than 1/1000" [actually ~39/1000"]. However, if you mistakenly chose "mm", then the calculations assume they are now 0.001mm apart and since this is considerably less than 1/1000" [], they are not processed.
The units used in the OBJ are converted into the correct size in the SKP, so if it's a "meter" OBJ and you are importing it into a SKP set up for "inches" it doesn't matter - the 1m tall object specified in the OBJ, is made 39.37..." tall in the SKP.
If you are uncertain of the dimensions used in an OBJ then I recommend using say "meters", since even if you are wrong, its over-sized geometry will get created, and you can always scale the imported geometry down to the correct size [using the Tapemeasure tool method]. But if you choose a tiny unit like mm when it is set up in m you will almost certainly get missing faces, not to mention that it will be 1000x too small !

Is there a way/method i can take that status update from the code? It used to work but now somehow never appears no more.

Im testing a different model know. 9k vertices and is still slow, ive done a lot of models and never was experiencing this... dont understand what happened.

PS where did you see that about a header in OBJ, it says nothing on wiki about this??? or some others i checked about explination on OBJ. I thought i check some background info on OBJ perhaps it could help me as well.

I do noticed when you run the impoter a second time it is somehow much slow than the first time? Is there some cache problem

PS
Bob you need to make sure that OBJ imports in other app correct. I remember a version of Xfrog has bad exported OBJ files which dont contain the correct textures assigned in the MTL file

TIG · 25 Feb 2016, 12:17

If you export an OBJ from SUp the header says this:

` # Alias OBJ Model File

Exported from SketchUp, (c) 2000-2012 Trimble Navigation Limited

# File units = millimeters

mtllib Untitled.mtl

g Mesh1 G_2016_1 Model

usemtl Mirror_01

v 223.781 841.405 0
vt -1.99553 9.71584
vn 0 0 -1
v 195.802 797.206 0
vt -0.893997 7.97573
v 195.802 831.592 0
vt -0.893997 9.3295
f 1/1/1 2/2/1 3/3/1
...`

So it is possible to indicate the units used in the OBJ in its header - in this case ' mm' ...
https://en.wikipedia.org/wiki/Wavefront_.obj_file
It is just good manners to the OBJ's user...

If you want to remove the status_bar updates, edit the RB file in a plain text editor - like Notepad++ [PC] or TextWrangler [MAC] and find the line #228 saying:
Sketchup.set_status_text("Processing line #{line_cnt} of #{lines.length}")
Type a # at the start of the line to stop it loading...
To optimize the calculations you can also skip the counter by adding a # before the previous line #227 which says line_cnt += 1 which will save a few milliseconds on the now unneeded increment...
Save the file and restart SketchUp to see the change...

OBJs define geometry, they are supplied with a linked MTL file defining the materials: this almost always resides in the same folder as the OBJ [the name of the MTL file is given near the start of the OBJ's text].
That makes each material - where it is textured it indicates a reference to an image-file.
Good OBJ exporters will usually write these texture-files into a folder, which is shipped with the OBJ/MTL files.
Good OBJ exporters will also include the relative path to that folder when specifying the texture-file, e.g.
newmtl Mirror_01 Ka 0.000000 0.000000 0.000000 Kd 0.725490 0.725490 0.725490 Ks 0.330000 0.330000 0.330000 map_Kd **Untitled/**Mirror_01.jpg
However, with some poorly set up OBJ exports the image files are put in a subfolder, BUT only the file-name is included in the MTL e.g. map_Kd Mirror_01.jpg
In which case the texture-file in the folder is not found and the material is just made plain-colored.
The way to fix this is either to edit the MTL to include the folder_name/ before each file-name - or probably easier, either move the OBJ/MTL into the image-files' folder, OR move the image-files into the same folder as the OBJ/MTL - either way the required image-files are then found and used...

rombout · 25 Feb 2016, 21:31

Thanks for the answer, i did manage to comment the line out already. Cant see if it is different though

PS when i do just one small part of a model it imports correct and nicely in quads. Now when i do a bit larger chunk i gets messed up. Model is some sort of easy, no difficult edge flows or so.

Ive tried scaling it up 100x in blender and than import as inch, perhaps i would go faster i thought. The inch models go like lightning speed.... but they have a lot of triangulation and messed up UVs.

ghostphalanx · 4 May 2016, 20:00

Hey! I would really like to know if it's possible to have the normals and smoothing groups preserved instead of having all the faces smoothed? Is that something that would require a core change in the code?

The main reason is that defining hard and soft edges is super easy in Maya (and many other software) but it's a drag in Sketchup. That's because selecting multiple edges, edge loops and edge rings is easy in other apps but in Sketchup is a painstaking edge by edge process.

Great plugin btw! Works great otherwise!

TIG · 14 Jun 2017, 17:55

@filibis said:

Hi TIG, thanks for the plugin!
But i can't make this .obj work in the attachment. It doesn't even ask for units in the beginning, just nothing happens. I suspect it's because .obj includes Turkish characters (Ö,Ç,Ğ,Ş etc.), might that be the reason?

I exported an .osm map and converted it to .obj and it worked without problem for USA areas.
There was no attached OBJ ??
Certainly non-ASCII characters in files etc can cause all sorts of unexpected issues...
If it's just the file-name you can fix that easily.
If the file itself contains non-ASCII characters, then try editing the OBJ using a plain-text editor like Notepad++ and globally replacing those - so Ö becomes O etc...
If there's an associated MTL file and you have changed its name, then ensure that the OBJ file's reference [at the start of the file] uses the same MTL name.
If the MTL makes materials, then ensure their names are ASCII, and also that the equivalent use in the OBJ match.
It the MTL uses image files then ensure that its filenames are ASCII and that the actual image-files' names match...

filibis · 15 Jun 2017, 06:24

Hi TIG, thanks for the plugin!
But i can't make this .obj work in the attachment. It doesn't even ask for units in the beginning, just nothing happens. I suspect it's because .obj includes Turkish characters (Ö,Ç,Ğ,Ş etc.), might that be the reason?

I exported an .osm map and converted it to .obj and it worked without problem for USA areas.

test_obj.zip

filibis · 15 Jun 2017, 06:37

@tig said:

There was no attached OBJ ??
(...)
If the file itself contains non-ASCII characters, then try editing the OBJ using a plain-text editor like Notepad++ and globally replacing those - so Ö becomes O etc...
If there's an associated MTL file and you have changed its name, then ensure that the OBJ file's reference [at the start of the file] uses the same MTL name.

Sorry, i somehow failed to attach. It should be there now.
There are quite amount of non-ASCII characters inside .obj file (only appears in .obj), so manual editing will be painful. And i ensured that .mtl file reference is correct.

TIG · 15 Jun 2017, 15:59

It only took a minute to edit th OBJ although it is nearly 95000 lines long!
I used Notepad++'s Regular Expression with Find [^ \r\nA-Za-z0-9._-] on the file displayed as Turkish
Which spots the Non-western characters.
I then substituted them with an equivalent so Ç >>> C etc with Find+Replace for the problem characters in turn.
The fixed OBJ file is attached...

The MTL was OK.

Try it and report back...

test2fixed.zip

filibis · 21 Jun 2017, 08:34

Cool, now it asks for units but when i chose meters (which suggests inside .obj), nothing happens (it only works if i choose 'as mesh' feature. This option works with other units as well).

Also if i chose anything other than meters, it visually imports everything in viewport, counts numbers at bottom left, but then gets erased at the end and gives this error: (happens both 'with textures' and 'no materials' option)

Bri11 · 22 Aug 2017, 19:21

How does this Plugin work on Sketchup?

TIG · 22 Aug 2017, 19:47

@bri11 said:

How does this Plugin work on Sketchup?
Have you installed it ?
Have you read the instructions near the beginning of this thread ?
What problems are you experiencing ?

Unexpectediteminbaggingarea · 30 Mar 2018, 12:56

Hi,
Installed fine and mesh comes through fine if I pick a big enough unit.
But no textures at all come through no matter what I try.

Unexpectediteminbaggingarea · 30 Mar 2018, 13:22

Update.
I was exporting an OBJ from SketchUp and it was generating an MTL file but not the textures as .jpgs that were referenced IN the MTL file.
I exported the textures manually from SketchUp via Photoshop into the same file, re-imported and it all worked!
Thank you very much!

ritcho · 10 Apr 2018, 10:00

Hallo.. i'm trying to import a .obj file into SU2017 but nothiong happen...
i mean, it seems to load but after a little my draw is empty..

on ruby appears that..

the problem should be the error :" Error: #<ArgumentError: invalid byte sequence in UTF-8> "

how could i solve it?!

Thanks

Ritcho