[Plugin] OBJexporter v3.0 20130131
-
Thank you for the update!!
-
Thanks for this great plugin. Way better than Sketchup OBj Export.
I have one request, is it possible to also export back faces that have a color or material, and not those that don't? Say, instead of creating a new face for the back like SKP export do, can yours assing a new OBJ command? For example...
usemtl White
bf 9/9/9 10/10/10 11/11/11bf for backface!
That way, we can load the obj and detect any back faces as oppose to treat them as a new face and have duplicate triangles!
I don't know if I make any sense?
Thanks
-
Alienizer
The Pro OBJ exporter has a 'two-sided' face option BUT when you bring these into many app's the faces 'fight' as they are coplanar.
What happens is each face is effectively duplicated and one is reversed with the Back material applied to it.
An OBJ file must use 'f' to define a face, there's no 'bf' coding...
I've no plans to make a 2-sided version any time soon...I suspect that you actually want a quick and lazy way to fix a sloppily modeled SKP, where you have some reversed faces with materials on their backs instead of their fronts...
I have already written the very tool to fix that for you - 'FixReversedFaceMaterials' - it flips any faces with materials only on their backs and sorts out the material's mapping back onto the 'now-correctly-oriented-face' front etc... Read this and then download the script http://forums.sketchucation.com/viewtopic.php?p=264134#p264134 
-
Great! Thank you. I will use your other tool. What about a face with 2 materials where front and back are visible, say, the back is visible from a mirror when rendered?
FYI I found a simple model that does not convert properly. All faces are oriented correctly and it export fine with SKP obj export...
http://sketchup.google.com/3dwarehouse/details?mid=b4b51fe2bdeeeedf56c58b78d29fd8a9&prevstart=24Thanks again TIG
-
An OBJ file contains data for a face with a material.
If you want a back material you must make a second face that's reversed.
As most renderers etc expect 'solid' objects it is wise to model your SKP this way - e.g. make a window glass with two outward facing faces ~10mm apart as it would be in the real world [there are never 'single planes' in reality - all things, no matter how thin they are, have two faces each with a front, not one face with a front and a back!]I am testing your problem Allosaurus SKP - it is complex with over 800,000 lines of code in the OBJ file. The OBJexporter isn't foolproof - I'll try to see where it might be failing...
-
I found that my OBJexporter did make a correct OBJ version - which imported OK into other packages. It took ages to finish and the OBJ file was 22Mb! The Pro OBJ exporter is quicker because it's compiled etc... BUT mine is 'free'
There is a problem with my old clunky OBJimporter - it will import some of the faces flipped - it's an issue with smoothed normals.***
I suggest you try this quite new and free 'compiled' OBJimporter - it is much faster, and after some initial tweaking this version is now stable and it gave me a perfect re-import back into a SKP of Allo'... see here http://forums.sketchucation.com/viewtopic.php?p=316470#p316470 - read the thread to see how it's evolved... It could probably do with some better reporting in the Status-Bar, but otherwise I like it...
***As we now have this free 'compiled' OBJ 'FluidImporter', I probably won't bother doing any more work on my clunky version...
-
I know you are right, and I do make my models that way, but, in the 3D warehouse, you are not going to find many that follows that rule! They all use an electron thin wall, and don't even know about front/back faces! Let alone paper thin glass (no thickness)!! That's why I try to get some 3ds files, then use AccuTrans3D to convert it to KMZ so that I can load it in SKP.
However, you're obj importer is by far the best of all! Thank you, and it's free!
Your renderer looks fantastic too. Great job, and thanks for taking the time to answer my post.
-
i cannot get it into sketchup.
OS: Win 7
SU: 8what should i do. (be detailed please)
-
Put the .rb file into your ../Plugins folder and restart Sketchup.
Use Menu > File > OBJexporter
Otherwise please be more specific with your problem's description... -
TIG, I have another one for you. I created a simple Cornell box with a sphere in the middle. Sketchup OBj exporter rendered perfectly, yours seems to have not soften it! See screen shot...
-
I have another one for you...
This guy did this by the book. It renders fine when exported using SKP obj exporter, but not when using yours!
-
Are you using the latest version of my exporter [v1.5] ?
This was updated to correct some smooth-normal issues, and it seems to work on exports tested by others.
Please download it from the first post and retry your sphere/box...
[It is also very similar to my Octane exporter which renders smoothed faces as expected too]When re-importing it into a SKP you need to use this http://forums.sketchucation.com/viewtopic.php?p=318928#p318928 new tool - my old OBJimporter is now surpassed [and it never imported 'smoothness' anyway]...
-
Here's a quick test.
The SKP has two spheres one smoothed [dotted edges] and the other faceted.
It is exported as an OBJ and then used in a quick Octane render, which shows the smoothed sphere as a rounded pearl and the faceted one exactly as they are the SKP ?
Are you sure you have the latest version of OBJexporter ?
-
I also tested the 'Mullaghmore' house.
The roof carpentry [first scene] exported to OBJ fine and here's a render in Octane
compared to the original it seems perfect ?
When I exported the whole house and its site [house] to OBJ it took a while and it then loaded into Octane but after all of the materials loaded it crashed it [it does have 90 textures and then other materials, although the OBJ itself is relatively modest]. When I re-imported it into a SKP after some considerable wait I got it to import. Clearly all smoothing was lost [currently all OBJ importers to SKP ignore smoothed normals]. I could have then quickly re-smoothed and got back to something like the original. There was considerable redundancy with interior structure, furniture etc that's 'on' in the exported scene but never visible in a 'site' view - luckily the SKP is very well layered, so switching those unneeded things' layers 'off' let it be exported quickly to OBJ and then it rendered nicely in Octane too... The 'tiling' is a function of the original texture mapping rather than the export or render - just compare it with the original SKP view
I'm not getting any real issues here - only that I can't expect a renderer to cope with a zillion unneeded hidden things in the model line floor joists and WCs as it needs to calculate all of them unnecessarily... -
Thanks TIG, but I do have the latest. I think I found the problem. It is that in some instances, your exporter export some faces as back face, that is, in the obj file, f 1/1/1 2/2/2 3/3/3 is f 3/3/3 2/2/2 1/1/1. Here is how I found out. Check this model...
You see the first brown door on the right? Erase everything except that door, then remove the frame and the back door (it's a bifold). Now you are left only with the 3d rect (6 faces, not paper thin). Now, the last two line foe example, is the front...
f 21/21/21 22/22/22 23/23/23
f 22/22/22 21/21/21 24/24/24and it is reverse. a ray bouncing of the normal goes inward, not outward. Now, it I modify it like this...
f 23/23/23 22/22/22 21/21/21
f 24/24/24 21/21/21 22/22/22it now renders fine and the face if oriented properly.
Most render such as yours may not be affected by this, but mine is! The fact remain that the face is not oriented properly.
Or is it just me that's going nuts?
-
I've checked your linked SKP.
It isn't modeled perfectly - there are a few reversed or missing faces [showing as blue or 'nothing' here].
My Octane render seems much like the SKp.
My Twilight render is too [although it does auto-correct the rubbish modeling [reversed face on the end of the stone-wall and a triangle pane in particular].
This crap render from AC3D also mimics Octane's output with the expected problems
Finally here's it exported to OBJ, re-imported into an empty SKP and a Twilight render
They all seem to cope quite well with the original SKP - TW even forgives the reversed faces
What's your renderer that seems to be causing this weirdness ?
-
I was only using a simple raytrace to verify the orientation of the faces. When I click on a face, it shows me the reflected vector (also shows the normals etc), and it shows it correctly with the skp export, but with yours, it shows the reflected vector to go inwards. Not for the whole model, only for the 2 brown doors to the right. When I reverse the face (f #/#/#...) as I explained, then the reflected verctor is proper. The same thing happens with the body of the allo dinosaur, but not the head.
I know the renders takes care of that, but imho I think it's better to have a flawless obj than one the render has to fix, so I present you my findings. It seems that for those 2 doors, the triangles are CWW instead of CC (or CC instead of CCW). This makes a big difference when you do a ray/troiangle test and test for face culling or want to know if it hit the back face or not.
-
Thanks for the analysis...
The tool's 'triangulation' method is built in to the Ruby API's face / mesh methods.
There's little control over it, other than telling it what extent of detail the mesh will include - like back face UVs...
...except that there are some arcane face / edge methods 'reversed_in' etc that are used to orient faces that share an edge but face opposite directions [i.e. one is reversed].
At the moment I can't see how... BUT perhaps you could reverse an edge's vertices on a particular face that is 'wrong' before making the triangulated mesh... I wonder if the problem 'door' face has some small facets - fluking it? I'll look more closely...As it is, I see this glitch as a shortcoming of the API mesh method that is making occasional glitches in the mesh that the OBJ is then using in its exporting...
-
I see what you mean. I did a test on that door, and I can't push/pull inward, skp says it's offset is at zero! If I remove the back face of the door and keep 5 sides, then it export find in yours. I don't know why it will not push/pull, I see no triangulation in skp that would show this 3D rectangle door not being 100% rectangular. If one face wasn't the same size, other faces would be triangulated accordingly in skp, and the hidden geom would show that, but it doesn't!!
I was wondering, I know little about skp api but I've look at all the api and I was wondering if there was a better way to get the data. For example, I see that you do not use uvhelper. Maybe there is a way to get the normals and tex uv using an api rather than doing it all over? skp diplays it right, so it must be stored somewhere no?
-
It doesn't need to have a 'get_uv_helper' method because it gets the UVs directly from the
face.meshusing
f_uvs=(1..mesh.count_points).map{|i|mesh.uv_at(i,1)}###1=front
which avoids lots of complex 'getting' otherwise...Clearly there's something adrift with those bi-folding doors...
If you edit one and select-all you get 18 entities - the correct number of faces+edges for a cuboid so there's no tiny bits of stray geometry to mess with us...
If you edit one of them you you'll find that the door 'slab' is not actually a cuboid - it's slightly skewed - faces don't meet quite at right angles, so PushPulling any vertical face 'inwards' is disallowed. To see this just try making a simple skewed cube and try to PushPull a face 'in' - you can't! because it clashes with connected internal geometry; however, it will PushPull 'out' as there's no clash and it makes two new edges and faces, because the extended side faces aren't coplanar with the original they spring from. This in itself shouldn't mess with the faces' mesh/UV mapping - it's weird...
Also if you edit the door 'slab' so you can see the axes [switch them 'on' and v8 displays the actual component-axes during the edit, rather than the model-axes as in v7] you find it has been made [or at least inserted] 'upside-down' - the Z/blue axes is 'down' not and not 'up' as it ought to be...
This might also be confusing the issue, but again it shouldn't matter.
None of these issues ought to matter but it seems that they do
Advertisement