[Plugin] Import OBJ with Materials v2.1 20131118
-
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 $$$...
-
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
-
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 ! -
@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.
-
@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 -
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 saysline_cnt += 1which 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 thefolder_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... -
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.
-
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!
-
@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... -
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.
-
@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. -
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...
-
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)
-
How does this Plugin work on Sketchup?
-
@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 ? -
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. -
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! -
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
-
I suspect this is an issue with the encoding of the text in .OBJ file itself.
The importer needs to read in the lines of the file to process the data into SketchUp geometry.More recent SketchUp versions can often force text encoding to be Ruby compatible.
This plugin is nine years old and hasn't been changed for five !
So it doesn't do any fancy re-encoding...You can try the following manual fixes on copies of the .OBJ and .MTL files...
Use a plain-text editor like Notepad++.exe to edit the files
If you don't already have it, you can get a free installer - google it for the download...In the editors menu, under Encoding, check that it's set to Encode UFT-8, if not then use Convert to UTF-8.
Ruby needs that encoding.
Check that the text is not unexpectedly changed [e.g. weird name-changes] and that any materials in the .MTL file still reference existing image files - e.g. a jpg name containing an umlaut might need to be changed so that the file-name and .MTL entry match...
Save the files.Try re-importing it and feedback...
-
I got one more question about this version. On one of my mac it was working fine, sadly that one broke down. Now im back to my old macbook mid 2010. When i try the latest version the same model i tried earlier shows the quads half flipped faces. I had an altered version on the other mac, mac didnt seem to have an proper backup of that one.
When i check the main plugin info, it says there was an update "feature proof";
2.2 20131228 Future proofed.
Yet in the addon when added it doesnt state that. There its says this as last update;
2.1 20131118 Import of OBJ files using a -ve counter for f vertices within
sub-groups fixed. View now refreshes with each group completion.
Advertisement