Sketchup Exports Bad 3D Models - but only in some formats

I haven’t used these formats a lot so I ask again, is there any potential reason for the exporter not to weld the vertices? Would e.g. a renderer prefer the cube to be 6 separate meshes with separate normal directions? It’s impossible to say if this is a bug or an intended behavior without knowing this.

It seems to me obvious that if the vertices are shared in the original SketchUp model created by the user, then I can’t imagine why they should be separate in the exported version. That would mean that the format was incapable of describing what the user created in SketchUp, which I’m certain is not the case.

FBX supports both vertex and face normals, so I’m pretty sure that whether you want smooth or sharp edges doesn’t affect the expected connectivity of the mesh.

Guess: the SketchUp devs licensed the FBX library from Autodesk, and they are calling an API function to add faces one at a time, described by vertices (not vertex indices), and the FBX library does not weld vertices. Only problem with that guess is that I use the option to triangulate faces. If SketchUp was adding 12 triangles then I would have expected to see 12x3 = 36 vertices in the FBX.

It’s pretty much expected when exporting a file that all data created in the original format isn’t exported. This is what separates an export from a save. Most formats have their unique concepts that doesn’t map perfectly to those of other formats.

SketchUp doesn’t save any normals but calculate them when needed from the vertex coordinates. Creating an object in AutoCad with explicit normals and export it to SKP would cause that data to be lost.

Does FBX have smooth edges? If not it could very well make sense to have each SketchUp surface, rather than whole Entities collection, map to a mesh in FBX, and let the normals be calculated from the point coordinates later.

FBX is an animation export format and was added to SU for that purpose…

SU exports are correctly formatted files for that purpose, it is not a faulty file just because your app wants a manifold 3D printable object…

and as you can export .stl, .obj, or .dae for manifold objects, why should you choose an animation format…


1 Like

Can you tell me where in the documentation it says that FBX should be used for animation only? And why would animators want defective 3D models? Seriously, that seems like a very weak argument to me.

As regards export vs save. Well naturally I understand that an export will export only the model, and not necessarily all of the associated metadata that SketchUp maintains about a project.

However, duplicate vertices is a bug, end of. No matter what purpose the model has, it should never be necessary and it cannot be correct to export the same vertex two or more times.

Incidentally, YOU may consider FBX to be an animation format, but I can assure you that it is a widely used format far beyond that domain. In particular if you export huge 3D construction models from Navisworks Manage then FBX is the only option.

I never said ‘only’ , I have used it myself for other purposes…

I simply stated SU intentions for the format…

documentation of .fbx export form SU…

and the intro from that page…

In SketchUp Pro, you can export a SketchUp file to the FBX format, which is a proprietary Autodesk format.

The idea behind FBX is that, if you’re creating a film, game, or similar 3D content, you (and a team of other people) likely need to use several applications in your workflows. The FBX format enables all those applications to share 3D data. Because SketchUp Pro can export an FBX file, you can create scenes or movie sets in SketchUp and then export that data to FBX for use with other applications that support FBX.

the bottom line is that it’s unlikely that the exporter will be modified to suit your app, but you as a programmer can modify the data during your import, I suggested an easy way…

this is the results from an assimp conversion…

if the SU FBX specification had a bug, assimp would not produce a valid file, which it does…

assimp export: select file format: 'obj' (Wavefront OBJ format)
Launching asset import ...           OK
Validating postprocessing flags ...  OK
Importing file ...                   OK 
   import took approx. 0.00285 seconds

Launching asset export ...           OK
Exporting file ...                   OK 
   export took approx. 0.00191 seconds
# File produced by Open Asset Import Library (
# (assimp v4.1.0)

mtllib face_verts.mtl

# 8 vertex positions
v  0 0 0
v  1268.900024414062 0 0
v  1268.900024414062 1174.099975585938 0
v  0 1174.099975585938 0
v  1268.900024414062 1174.099975585938 -2629.199951171875
v  0 1174.099975585938 -2629.199951171875
v  0 0 -2629.199951171875
v  1268.900024414062 0 -2629.199951171875

# 13 UV coordinates
vt 0 0 0
vt 1268.900024414062 0 0
vt 1268.900024414062 1174.099975585938 0
vt 0 1174.099975585938 0
vt 1268.900024414062 2629.199951171875 0
vt 0 2629.199951171875 0
vt -2629.199951171875 0 0
vt -2629.199951171875 1174.099975585938 0
vt 2629.199951171875 0 0
vt 2629.199951171875 1174.099975585938 0
vt -1268.900024414062 0 0
vt -1268.900024414062 1174.099975585938 0
vt -1268.900024414062 2629.199951171875 0

# 6 vertex normals
vn 0 0 1
vn 0 1 0
vn -1 0 0
vn 1 0 0
vn 0 0 -1
vn 0 -1 0

# Mesh 'Mesh1' with 6 faces
g Mesh1
usemtl FrontColor
f  1/1/1 2/2/1 3/3/1 4/4/1
f  3/2/2 5/5/2 6/6/2 4/1/2
f  7/7/3 1/1/3 4/4/3 6/8/3
f  2/1/4 8/9/4 5/10/4 3/4/4
f  8/11/5 7/1/5 6/4/5 5/12/5
f  8/13/6 2/11/6 1/1/6 7/6/6

but as the saying goes…

I would like to agree with you, but then we’d both be wrong


1 Like

I just wonder if you have used the same kind of export settings for all the formats you have tried.

I’m sorry John, I am trying to remain polite, but you seem intent on spouting defensive nonsense. As I already said, the fact that some other software you have (assimp) can repair the defects in the 3D model, does not prove that the defects are not there. You need only look at the model file to see proof to the contrary.

And is it really your contention that it is better for the downstream software to have to approximate a repair every time a model is loaded, with the CPU overhead and loss of precision that vertex welding entails, rather than fix the problem at source? Seriously - that is your position? And what exactly is your role here? Are you speaking for the SketchUp devs?

I said in my first post why I didn’t want to do vertex welding in my own code.

Yes, I use the same options for all exports. Same as yours except “triangulate all faces” is selected (makes no difference as already discussed above), and “swap yz” is not selected.

I have never suggested you need to weld vertex…

it’s a text file, manipulate the data not the model…

# given the ary from the .fbx file, all it takes in ruby to convert to 8 vertices

other languages may even be simpler…

assimp does this using C…


Everyone who has commented in this thread are users and not employed or payed by SketchUp. However I think all of us others have met the devs at various SketchUp events.

There seems to have been a misunderstanding in this discussion. I came here to report an easily reproducable bug, nothing more. I am not interested in hearing about workarounds, especially really stupid ones that I could never recommend to our clients.

If you are saying that the Trimble people never care about bugs then fine, I’ll get our doc team to remove SketchUp from the list of recommended third party apps.

It’s not necessarily a bug per se. Optimally an exporter would target minimal file size which means that a Sketchup cube with 6 materials would be exported as a lists of 8 vertices, 6 normals and 24 uv:s; these would then be referenced by indices on a per polygon basis. I think FBX allows for this, so I think you are right in that the Sketchup export could be more compressed. The problem may however be at the other end. If someone is writing an importer for a 3d application that only allows for one uv and normal per vertex in a connected mesh, they need to split the mesh in the FBX into six meshes for their application, however, they may feel it’s not worth the trouble and therefor defer this responsibility to the exporters or modelers of other applications. Thus, in the presence of such “weak” importers for important applications you may be forced to write a weak exporter that sacrifices file size for compatibility.

I don’t know whether this is in fact the case but it’s one possibility.

Regarding welding, I think that this should be closer to an O(1) operation in this case; since you are looking for vertices with identical coordinates (they emanate from the same vertex in Sketchup) you could use a regular hash with the coordinates concatenated as a string (x+y+z) as key and look for numerical identity within each list of values.


I’m sorry, but that makes no sense to me. It is computationally trivial to split up a mesh if that’s what you want. It doesn’t even require a search, you just do it. It is not computationally trivial to find a nearest neighbor, which is what you need to do in order to weld vertices. That is why I don’t want to impose this burden on my own software when it already has to deal with large models, e.g. 24 million triangles is typical - in the SketchUp universe that would be 72 million vertices to search for nearest neighbors. Even if my algorithm is O(n log n) that’s still a significant overhead.

And it is certainly a bug: if you export to OBJ the vertices are shared, if you export to FBX or 3DS then the vertices are unshared, connectivity information is lost. All of these formats have similar capabilities in the current context (i.e. the can all encode connectivity without relying on infinite floating point precision). They can’t all be an optimal representation of the same model.

Sorry, I meant 0(n). In this case you are not searching for a nearest neighbor in the normal sense where two points are considered equal if they are within a specific tolerance, you are looking for vertices with identical coordinates (by virtue of stemming from the very same vertex in Sketchup) which means that you can omit sorting or space hashing and instead use a normal hash.

For example, a vertex with coordinates (10.3, 15.1, 8.7) is inserted in a hash with key (string) “10.3,15.1,8.7” and data is the new common vertex for all vertices with these coordinates. The cost of bunching together 10 vertices with identical coordinates is 10 lookups in a hash. The welding can be performed with a single pass through all vertices.

Whether the exporter exhibits a bug or not, well, we really don’t know. Maybe it’s because of laziness, but as I see it, there may be a legitimate reason for duplicate vertices. However, I personally agree that an FBX export should reflect the connectivity of the Sketchup model and the format by itself does permit it. It would be interesting with a comment from the Sketchup team.

1 Like

Sorry, that is not correct. Even if you only test for equality (which would be unreliable with floating point), it’s still comparing every vertex with every other vertex, which is O(n^2). In the example model given earlier, that is (72,000,000 * 72,000,000 * 3) floating point comparisons just for this function.

That is actually worse than the O(n log n) full algorithm I had in mind, i.e. keep the vertices in sorted order of X say, and only compare against the other vertices which fall into the required range. Or use a hash table to eliminate the need to sort.

The fact that we are looking at identities makes the problem similar to counting the number of occurrences of specific letters in the array [“a”, “b”, “b”, “b”, “a”, “c”, “c”]. You iterate the array once and fill a hash on the fly. In ruby it would be something like:

hash = ["a", "b", "b", "b", "a", "c", "c"].inject({}) { |hash, char|  
	hash[char] = hash.has_key?(char) ? hash[char] + 1 : 1
puts hash.to_s 

And the result is:

{"a"=>2, "b"=>3, "c"=>2}

So, you make one iteration through your list of vertices O(n) and make a hash lookup for every vertex O(1) (ideally…).

Now, can we treat floating point numbers as strings? Well, in this case the answer is probably yes since the numbers come from the same source. They are not processed through different transformations and so on. I would give this welding scheme a shot at least.

1 Like


Be aware that I have taken your recommendations and I have entered them into our system for the improvement of our exporters.


1 Like

@ChrisDizon: thank you very much for that good news.


This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.