[Plugin] Import OBJ with Materials v2.1 20131118
-
Please make a ZIP of the OBJ, MTL and textures-subfolder [including its image-files].
Then either attach it to a post here, or onto a Private Message sent to me.Any messages in the Ruby Console ?
If the OBJ refers to the MTL, and that MTL refers to the texture image files then it should work...
-
Will this plugin work with SU2015? I have a large .obj with 219 different UV textures, and so far this hasn't worked (fails to import). Or do I need to be using 2013 in order for the importing and mapping to work appropriately? I get this file to import correctly using SimLab's plugin, but the materials are all wonky because the mapping is incorrect. Any help would be appreciated.
-
It works in all currently available SketchUp versions.
Without the OBJ/MTL/Textures it's difficult to say what your issue is.
Sometimes OBJ files do not follow the prescribed format and are awkward to parse [e.g. -ve vertex referencing] - although those main variants are catered for already in its code...
If it ZIPs to <= ~4Mb you can attach it to a Post or a Private-Message...
Or use a Dropdown etc and PM me a link...BUT alternatively you could think about getting Blender [free], importing the OBJ into that, exporting from that as a DAE and finally importing that into your SKP using the native Collada Importer ??
See if that helps.
But if that OBJ/MTL/Tetxures is inherently flaky - as your SimLab experience suggests - then perhaps it's inevitable ? -
We just released FluidImporter 3.1.0. You can get it here.
Here's what's new:
- Faster import
- FluidImporter is now a full .rbz extension, with a single file for Windows/OSX
- You can access FluidImporter funtionality through the menu Extensions -> FluidImporter
- Added edge smooth option
- Options are now saved so you don't lose your settings when closing SkechUp
-
I have tried with obj files this week, the import with materials fails to bring all the geometry across and import as geometry loses faces but at least keeps the lines for the geometry. Is there something I can do to get all the geometry?
Link to models. http://www.colacola.se
Link to topic http://sketchucation.com/forums/viewtopic.php?f=81%26amp;t=62675 -
I've only looked at one downloadable model.
The most recently added OBJ [bazze...] is poorly set up.
There is no units 'clue' in its header.
There is no call to an MTL file inside the OBJ.
There is no MTL file - which would be used to define Materials.
The two images are not referenced, as there is no MTL file to call them - also they typically go inside a subfolder with the OBJ and MTL files...So using that you will never get materials included.
If you guess the units to be 'meters' then all of the geometry might get made...
With smaller units, any tiny edges will not get created, and any reliant faces will also no make it through... -
Thanks TIG, I am guessing that as the modeller is European that metres is the correct scale, especially as the subject is reasonably large. I have SOME of the models translated with Turbocad but the older aircraft tend to be more complex and that is where the problems lie.
-
It worked after a few attempts, very slow but that is understandable with all the detail. I will have to work out how to wrap the textures next. Thanks againTIG, I appreciate your quick response.
-
Hi TIG,
I've been using this wonderful plugin for quite a long time, apparently it wouldn't work nicely in 2016 Make (I haven't tested in 2016 Pro) but it's working like a charm in 2015 Pro. So is there a plan to make it work under 2016 Make?
When I say it wouldn't work it's not bringing all the geometry, just some random faces from the whole model.
Cheers
erkan -
I'm unsure why you are having issues with v2016...
It should be compatible, even though its RBZ hasn't yet been signed to run in all v2016's security-policies...
I haven't tested it though !
So, is the exact same OBJ working differently in v2015 and v2016 ?
Can you ZIP the OBJ etc, and PM it to me, so I can test it here... -
Hi TIG!
Thank you so much for the plugin.
I finally installed old frecle Tree[D] that I had downloaded when still available... I think it's great and easy to use to generate 3d trees, so your plugin is perfect to be able to import OBJ + Material into my sketchup 2016.
Tree[D] is still a MUST HAVE in 2016 or there´s new stuff? vs 3D Tree Maker? Free is better... -
I purchased a model in .obj format from Turbosquid. Within the OBJ folder are .obj files and .mtl files. In addition to the OBJ folder there is a TEXTURES folder containing .tif files.
I've tried several ways to import the model into SU. The only time anything was actually imported was when I used "Import as Mesh", but some of the model was missing (size=feet) and there were no textures or materials.
The Cortaderia_variant1.obj file contains identification of the .mtl file:
==========================================================================
Wavefront OBJ format exported by Red-i Productions' "Riptide Pro"
(a commercial plugin for Cinema 4D PC & Mac, R9.6 or later)
Red-i Productions
http://skinprops.com
==========================================================================
mtllib Cortaderia_variant1.mtl
o si3d_0031_leaf01
v -0.00283137 0.010224 0.114454
v -0.000566467 0.00851267 0.116015
v 0.00263311 0.00845039 0.116518
v -0.0110162 0.0498717 0.168671
v -0.00835776 0.0478127 0.170411
v -0.00461871 0.0477404 0.171001
v -0.0204793 0.0850494.....................The mtllib Cortaderia_variant1.mtl file contains:
==========================================================================
Wavefront Material file
Exported by Red-i Productions' "Riptide Pro"
(a commercial plugin for Cinema 4D PC & Mac, R9.6 or later)
Red-i Productions
http://skinprops.com
==========================================================================
newmtl default_Mat
illum 2
Kd 0.800000 0.800000 0.800000newmtl si3d_0031_leaf01
Ns 50.781250
illum 2
Kd 0.800000 0.800000 0.800000
map_Kd si3d_0031_leaf01.tif
bump si3d_0031_leaf01_rel.tif
map_d si3d_0031_leaf01_a.tifnewmtl si3d_0031_leaf02
Ns 50.781250
illum 2
Kd 0.800000 0.800000 0.800000
map_Kd si3d_0031_leaf02.tif
bump si3d_0031_leaf01_rel.tif
map_d si3d_0031_leaf01_a.tifetc,
.
.
.
.
.The textures folder contains:
-
Have you also tried the [faster] Fluid OBJ Importer ?
I suspect the OBJ's units are meters ?
The vertex spacings seem very small otherwise.Any Ruby Console error messages when importing it ?
In my version the mesh option ignores textures - so that's expected.
At first glance the MTL materials seem to be defined OK, although the bumps images etc will be ignored.
However, themap_Kd si3d_0031_leaf01.tifdoes NOT include the actual path to the 'textures' folder.
I suggest you copy that folders' image files into the main folder with the OBJ and MTL files...
Then retry, using meters as the units...Have you tried importing the OBJ into Blender and then exporting it as a DAE.
That DAE might then import into a SKP... -
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 $$$...
Advertisement