[Plugin] OBJexporter v3.0 20130131

Sound

Hello TIG, thank you for writing such an useful plugin. I look forward for using it in a 3D printing workflow but I noticed two problems - the first one being more serious.

Draw a cube and export it as OBJ. It contains 16 triangle facets, but I would expect 12. If you inspect the generated OBJ you'll notice that it generated a tetrahedron inside the cube by triangulating the internal space. Hence the four more facets. I think this problem needs to be addressed. What do you think about it?
Resulting OBJ files contain lots of duplicate vertices. I think this is because you don't reuse vertices but you generate new ones all time. However this corrupts the topology of the generated OBJ file. If you open it with, say, Netfabb Studio Basic (a popular free utility for 3D printing) it will report all faces as unconnected. I don't know whether SketchUp API associates a unique ID with each vertex; in case it doesn't I think you could just build your own dictionary based on coordinates and check whether you already wrote that vertex and if so, just reuse its index when defining the new facet.

Thank you for your work, and I really hope you can fix these two things.

TIG

@Sound

I am afraid you are mistaken.
I have tested this extensively and a cube of 6 faces exports as a cube of 12 facets, because they are each triangulated.
You can clearly see it in the OBJ code.
If I import the OBJ it then arrives with 12 triangulated faces too.
this occurs with many OBJ importing apps.

IF you triangulate the faces manually before exporting you can create internal 'partitions' inside the cube depending on the order the diagonals are drawn, this should only make more that the visible 12 faces

So this suggests there is something wrong with your initial cube if it indeed has 16 facets when exported, or alternatively something wrong with the app into which you are importing it? There are many apps that import these OBJ files quite acceptably without new facets or complaints about unconnected facets...
What are you using to import it ?

The code takes faces in the same context using the same material, triangulates them as necessary and produces the facets to suit. This tool is used as the basis of several rendering apps. The Pro OBJ exporter exports a simple cube with a file that is all but identical to this tool's file, so I don't think there's anything wrong with it...

Try the Pro version OBJ exporter and see it's the same...

I suspect you are either mis-modeling the cube beforehand OR not using appropriate import settings and getting spurious results... I suggest you make an OBJ made from a 1m cube in the positive quadrant of the axes, bb.min at [0,0,0]. Then compare it with mine in the ZIP, which only has 12 facets...

obj.zip

Sound

Thank you for the answer. Yes, it looks like those internal faces were already in SketchUp. A new test shows 12 facets, and that's fine.

Still, the other problem persists. Even when the exported cube results in 12 facets, the file contains 24 vertices (you can check this by opening the OBJ file with Meshlab or any other importer, or even by counting the "v" lines in the OBJ file). This looks very wrong, as the original geometry only has 8 vertices. Can you help me about this issue too? Thanks!

TIG

So no apology for putting me to unpaid trouble when it was entirely your error?
My exporter does work differently from the pro-OBJexporter, which minimizes the number of vertices by recycling them when possible.
However, my version treats each context, material and face as a separate set, and doesn't reused vertices. The coding is such that it would be very awkward to effect...
However, it has no noticeable effect on the resulting form and a ood 3rd party app should be able to cope with welding vertices etc anyway...
Get Pro if you really do NEED this functionality, and are not just being 'anally retentive'.
After all my tool is 'free' [donationware] and you cannot readily expect, let alone demand, changes to its functions...

Sound

Well, I'm just reporting a bug. A cube, having 8 vertices, is exported with 24 vertices
This is a wrong representation of the object and has a very noticeable impact on all uses of the OBJ file when topologic integrity is required (3D printing is one example).

Of course I expect nothing from you, being it freeware. Whether you want to fix this bug or leave it there is entirely up to you.

TIG

@Sound

The vertex 'duplication' isn't actually a 'bug', since that would suggest that it isn't doing what it is intended to do: and it currently does exactly what it is coded to do.
However, I do take your [inelegantly put] point that vertex entries could be 'reused' if they are 'shared' by more that one facet...

So I now have an idea on to make an adjusted version of the code that will now does this: and it can also have a few other tweaks; to reduce the file size further, to optimize the processing time etc.

I'll post it soonest...

PS: Although I do 'reserve all rights' to my code... please feel free to make your own improvements to any of my tools, and either PM me or post them here, of course for free unfettered use by all members... The only thing I ask is not to post whole scripts in the same thread as it'll cause confusion...

TIG

Here's v2.8 http://sketchucation.com/forums/viewtopic.php?p=294844#p294844
The D.P. accuracy is not now applied to 'whole numbers', and any -0 values becomes 0.
Any shared-vertex entries are now 'reused'.
The OBJ file size is minimized and the processing time is optimized.

Sound

TIG, thank you very much for working on that and for clarifying your terms about modifying the script.
I will test the new version as soon as possible and report success or failure.
Have a good day.

Sound

I can confirm this works for any model I tried.
Thank you! Exported OBJ is now topologically correct and thus suitable for a lot more uses.

TIG

Good.

TIG

Here's v2.9 http://sketchucation.com/forums/viewtopic.php?p=294844#p294844
Merging of shared vertices is now optional, as it slows down processing for larger models considerably; and it is only required by some more picky mesh-apps, but renderers etc don't seem to mind non-merged vertex data at all.

TIG

Here's v3.0 http://sketchucation.com/forums/viewtopic.php?p=294844#p294844
It has a much improved shared-vertex merging algorithm that is now slightly faster than a non-merging version, so the option 'not to merge' has been removed because it is now of no benefit.

Where possible, shared-vertex data is always reused, ensuring correctly formed geometry.
This can mean that a SKP export containing 100,000 faces and therefore potentially 300,000 vertices can be 'compacted' to use perhaps 50,000 shared-vertices [but of course this depends on each SKP's geometry, grouping etc]: this 'compaction' also reduces processing time [which will now be perhaps ~60 seconds for this sized example], and when combined with the latest optimized 'numerical-entries' gives much smaller OBJ file sizes, and faster processing in 3rd-party apps too.

andybot

Great work, as usual, TIG!! This plugin is very essential for me. Many thanks for your development efforts!

cotty

Thank you for this update!

samurai1789

What simple instructions???? What ever i do i cannot find it HELP!!!!

TIG

@samurai1789 said:

What simple instructions???? What ever i do i cannot find it HELP!!!!
They are on the download page ! http://sketchucation.com/forums/viewtopic.php?p=294844#p294844
There are also some simple dialogs as you go after the tool is started...
What problems do you have otherwise ?

thomthom

@tig said:

The D.P. accuracy is not now applied to 'whole numbers', and any -0 values becomes 0.

What made you chose to do this? Are there applications that doesn't handle these values well? I'm curious because I've been looking at the OBJ format this weekend.
(Is there an official specification somewhere? I find multiple sources around...)

pilou

See the external links at the end of the page

thomthom

@unknownuser said:

See the external links at the end of the page

Is that the official specs though? "martinreddy.net" ...

TIG

@thomthom said:

@tig said:

The D.P. accuracy is not now applied to 'whole numbers', and any -0 values becomes 0.

What made you chose to do this? Are there applications that doesn't handle these values well? I'm curious because I've been looking at the OBJ format this weekend.
(Is there an official specification somewhere? I find multiple sources around...)
It just minimizes the OBJ file size, an importer reads 0 as 0.0, so making it 0.000000 is pointless, -0==0 so it might as well be 0 !... so all trailing zeros are now omitted, it speeds up the writing by a few % and I also the importing at the 3rd party end...
There's an OBJ Wavefront Wiki...