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

Hi. I am a programmer who has a day job maintaining a specialist 3D visualization application. I have a personal license for Sketchup Pro that I use for hobby work, and I recommend it to colleagues to use for quick 3D modeling.

Anyway, a colleague recently pointed out to be that selection behaviour in my software is different, depending on the export format from SketchUp: if they select a face on an OBJ model, then the entire object (of which that face is a part) is selected. This is the intended behaviour.

On the other hand, if they export in 3DS or FBX formats, which my software also supports, then selecting the same face only selects that face, not the entire object.

I investigated, and I discovered that SketchUp emits duplicate vertices for some export formats.

Take a simple example: create a simple cube in SketchUp (draw rectangle, push/pull into a cube, double click to make a group), then export to OBJ and also to FBX (both are text files viewable in Notepad++). In OBJ format the cube has 8 vertices, which would please my old geometry teachers. In FBX format the cube has 24 vertices. This is very inconvenient, since my app is designed to load HUGE models, so adding a step to weld vertices (which I have tried before to deal with bad models) is potentially an O(n^2) task (O(n log n) if I optimize) and adds a lot to load time.

Do you have a list of what formats are welded and what are not? Also, do you know if welding affects normal directions in these formats? I’m thinking that if some format doesn’t support edges to be sharp in renderings while also being welded, it’s better to keep the faces separated. Not sure if this is the case though.

it sounds more like an importer issue as other apps see the files correctly…

assimp recognises all three formats from SU and can do an almost instantaneous conversion between them…

it is written in C and can be included into importers/exporters for SU, or maybe your app could utilise it directly?


Apparantly I didn’t make myself clear. Both of the formats mentioned are in text format, you can view them yourself in Notepad++, so my import code is not relevant.

I also described a very easy test case.

I’ve seen warnings about duplicate vertices when viewing exports in meshlab, though it seems to be able to cope.

I made your test case and the .fbx looked correct, as did the file in Autodesk® FBX® Review…

I also converted it in assimp and reimported into SU…

it was still a single group with the x,y switched as exported…

does your app retain groups for any .fbx files from other sources…

when working on an .fbx importer for SU, my understanding was the the face data is used as part of texture positioning, but we ended up using assimp as a step in our chain…

sorry if my attempt to help offended you…


1 Like

Hi. My point is not whether or not the model “looks right”, whatever that means. I’m aware that some software can correct a variety of defects in a 3D model, but that doesn’t mean I give the source software a free pass to produce defective models, especially if I’m paying for the software!

Are you saying that your FBX export is correct, i.e. that the cube has 8 vertices? Because if your vertices list has 72 numbers (24 x 3D coordinates), then your cube has 24 vertices like mine does. A cube should not have 24 vertices. Duplicating vertices is a waste of space and creates a potential for rendering errors in the downstream software: it is also a main reason for choosing FBX over STL in the first place, i.e. the latter is simpler, but is incapable of generating anything other than polygon soup.

If SketchUp simply can’t create watertight 3D models then the puzzle is why does it do so when I export to an OBJ file? The OBJ defines a solid, watertight cube using 8 vertices, which is exactly what anyone would expect.

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.