[Plugin] Import OBJ with Materials v2.1 20131118
-
See this which discusses what I did with your suggestions/comments in mind:
http://www.thearender.com/forum/viewtopic.php?f=93%26amp;t=18766%26amp;start=20
-
Sorry @Bob I can't access that forum.
Can you précis it ?Did it work ?
-
I got another question about this importer. If im correct it would show vertices or some sort of count in the bottom left corner. It doesnt no more for me on mac, but im not sure if it was with this script
Ive used this script before and always sort of worked. Now i got this model which is in Meters. WHen i import it in Meters nothing happens, at least on mac SU becomes non responding. But thats normal i believe for this script. When i use Inch, it does work only a lot of the mesh is cut off and not showing.
Im using SU8 on osx 10.11.2
EDIT
after checking on using inches again. It does show some progress in the bottom left. It seems with meters some errors apear.Ive zipped the part with the textures, perhaps you can check or see. If you like
https://www.dropbox.com/s/ihpnays8veufcpm/plant%20part.zip?dl=0EDIT2
When i use inch it also goed much faster. I did let it go now for 20min orso and than it did the meters. Not sure why the difference in time??? Also centimeters go much faster than meter. -
In the bottom left of the status-bar it shows a count of the lines of text it has processed in the OBJ file - in your case:
Processing line 1234 of 139564
About a third of that relate to vertices, the remainder are normal maps, face creation etc.It took my PC 23 mins to import it in meters [which I believe to be the correct units, though the OBJ file's header does no define any units at all!].
The faces are triangulated and reversed [see screenshot], making the application of materials somewhat pointless... The blue faces are reversed.
It is an enormous file for a small plant - this kind of geometry is not very suited to use in SketchUp - a single plant that is bigger in Mb than many users' entire building projects seems excessive...
It's ~20Mb !
It had three errors that were fixed using statistics - coincident edge vertices - here were no errors in processing reported in the Ruby Console as it was processing...
-
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
-
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?
-
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?
Advertisement