MeshLab DAE export error when importing into Sketchup

Sketchup model.

  • Length Units Decimal Inches
  • Created a cube 25.4 x 25.4 x 25.4 : cube25p4onside.skp
  • Exported as a .date : cube25p4onside.dae
  • Imported the mesh into MeshLab
  • MeshLab: Filters » Cleaning and Repairing » Remove Duplicated Vertex
    — Results were 16 duplicated vertices removed. Explanation : Each face of the cube has four vertexes. Where three faces join there is a corner shared by all three faces – a common vertex. For the cube that means the same vertex has been duplicated three times so two are redundant. A cube has eight corners or sixteen redundant vertices.
  • Exported the mesh as cube25p4onside.stl
    — A STL file does not contain data stored as a specific system of measurement – inches, mm etc. It is simply stored as numbers. For this cube then it is stored as 25.4 .. that is all. The trick is that Sketchup exports in inches without regard to the Length Units the model is created in. If you created a cube with Sketchup set to Decimal mm you would have a cube 25.4 mm on a side. When you export the DAE file it would be in inches .. 1 x 1 x 1. By creating the model in Decimal Inches but using mm for lengths .. we have a cube that actually is 25.4 x 25.4 x 25.4 INCHES. Exporting the DAE and importing into MeshLab then saving as a STL we have simply a file with sides of 25.4 UNITS. When we upload to Shapeways we simply tell them that the model is in mm. There are two reasons for doing this.
    — (1) Sketchup has a problem with radii smaller than 0.018″ – it will refuse to draw a circle and has problems with interseting mesh at that size. In O scale that 0.018″ is equal to 0.864″ Full-Size. Obviously this would be a problem. If we multiply that 0.018 x 25.4 we get 0.4572 which obviously is way outside the 0.018″ radii issue. In fact if we close one eye and look at it sideways .. with us modeling in Decimal Inches but using mm lengths .. that Sketchup minimum radii issue of 0.018 (call it Pseudo mm) converts back to 0.0007″ for O scale or 0.034″ Full-Size. QED – Problem Solved!
    — (2) The Shapeways materials information pages give you the information to design a model for 3d printing. In this are minimums for each material which include things like ‘Minimum Supported Wall Thickness” and “Minimum Supported Wire” and “Minimum Embossed” amoung other data. This is all expressed in milimeters. That means we can quickly check the width of a wall to ensure it meets the minimum for the material we are working in. If I am designing for FUD (Frosted Ultra Detail) which is my “Go To” matrial for my projects, the minimum wall thickness is 0.3 mm – which again means that I simply have to use the ‘Tape Measure Tool’ to make a quick check that I am within the minimum.
  • * Exported the mesh as cube25p4onside.dae
    — This is one of the points for this exercise.
  • Imported cube25p4onside.dae into Sketchup
    — Now we use the ‘Tape Measure Tool’ and we see that with our Sketchup universe set to Decimal Inches .. the cube measures 1000.000 on a side. What is up with that? To continue let’s use netfabb
  • Open cube25p4onside.stl in netfabb.
    — The netfabb dashboard sees the cube as 25.4 mm on a side (it defaults to mm on import). In netfabb we can export a STL file as STL (ASCII) – so let’s do that – cube25p4onside_ascii.stl – which we can open in Notepad.
    — cube25p4onside_ascii.stl – just a bit of the code – the first 15 lines:

    solid cube25p4onside
    facet normal 0.000000 0.000000 -1.000000
    outer loop
    vertex 25.400000 25.400000 0.000000
    vertex 0.000000 0.000000 0.000000
    vertex 0.000000 25.400000 0.000000
    endloop
    endfacet
    facet normal 0.000000 0.000000 -1.000000
    outer loop
    vertex 0.000000 0.000000 0.000000
    vertex 25.400000 25.400000 0.000000
    vertex 25.400000 0.000000 0.000000
    endloop
    endfacet

    — We can see from this that within the STL file we have the vertices numbered as 25.400000 – again .. when uploading a file to Shapeways telling the website that the file is in milimeters works great

  • So the question is .. how did MeshLab get from a STL file with a cube of 25.4 units on a side to exporting a DAE file with 1000 inches on a side?
    — Let’s open up the DAE file as exported from MeshLab and look at the two ‘source’ loops ..

    <float_array id=”shape0-lib-positions-array” count=”24″>25.4 25.4 0 0 0 0 0 25.4 0 25.4 0 0 25.4 0 25.4 25.4 25.4 25.4 0 0 25.4 0 25.4 25.4</float_array>
    <technique_common>
    <accessor count=”8″ source=”#shape0-lib-positions-array” stride=”3″>
    <param name=”X” type=”float”/>
    <param name=”Y” type=”float”/>
    <param name=”Z” type=”float”/>
    </accessor>
    </technique_common>
    </source>
    <source id=”shape0-lib-normals” name=”normal”>
    <float_array id=”shape0-lib-normals-array” count=”36″>0 0 -1 0 0 -1 0 1 0 0 1 0 1 0 0 1 0 0 0 -1 0 0 -1 0 -1 0 0 -1 0 0 0 0 1 0 0 1</float_array>
    <technique_common>
    <accessor count=”12″ source=”#shape0-lib-normals-array” stride=”3″>
    <param name=”X” type=”float”/>
    <param name=”Y” type=”float”/>
    <param name=”Z” type=”float”/>
    </accessor>
    </technique_common>
    </source>

    — First Loop: Appears that it is happily reporting 25.4 units. It referrs to – array count=”8″ – “-positions-array” – accessor count=”24″ (followed by 24 numbers, 12 of which are 25.4 and 12 which are 0. Since a cube has 8 vertexes and each needs a x,y,z coordinate I am *assuming* that count=”8″ is the number of vertexes and count=”24″ is the x,y,z coordinates of each of those vertexes.
    — Second Loop: This time the array count=”36″ followed by 36 numbers – 0, -1 or 1 – and the accessor count=”12″ – with a reference to ‘normals’. A normal is if you are looking at the outside or inside of a face (3d talk). It was at this point my brain began to shut down. A cube has six sides so I can *guess* (close cousin to assume) that the count=”12″ is referring to the outside and inside of each of the six faces. What about the count=”26″ .. well .. something to do with the vertexes of each of the 12 outside/inside faces .. and my brain tried to do a re-boot at ths point.

  • So .. we already know that Sketchup exports a DAE file as inches no matter what Length Unit you modeled in. Importing a DAE file back into Sketchup it is doing something different .. obviously, changing that 25.4 to 1000.
    — if 25.4 * X = 1000 …. then …. X = 1000/25.4 .. so X = 39.37~ .. and why does that seem familiar. Ah Ha! 1 meter = 39.3701 inches.
    — 0.0254 meters = 1 inch
    — AND multiply both sides by 1000 and we get 25.4 meters = 1000 inches. Soooo. Sketchup is taking that DAE file adn thinks the 25.4 is meters and converting to 1000 inches. Huh. That made no sense .. I can export a DAE file from Sketchup all day and import it back without the units getting mixed up .. and .. and .. Ooooo. Exported from Sketchup .. the DAE file I imported was created in MeshLab … (pause for effect)
  • The files are different with the Sketchup DAE file adding various Sketchup specific items such as materials. What caught my eye was this:
    — from the MeshLab exported DAE file:
    <up_axis>Y_UP</up_axis>
    — from the Sketchup exported DAE file:
    <unit meter=”0.0254″ name=”inch” />
    <up_axis>Z_UP</up_axis>
    — The change in which axis is UP is no problem .. BUT .. look at the additional line that Sketchup added .. . To which I go .. Okaaaayyy. This DAE file was exported with a cube 25.4 inches on a side with the Units set to Decimal Inches (reason in the first paragraph).
    — So I went back to Sketchup and created a cube using Units as Decimal Milimeters and exported the cube. The line is exactly the same. The difference is that the units exported are 1 and 0. The units exported when the Units are Decimal Inches are 25.4 and 0.
    — So. With Units as Decimal Millimeters the length is 1. Sketchup converted the 25.4 mm internally before export ..and then exported as inches .. so the length of a side is 1. When I had Sketchup set to Decimal Inches but sides to 25.4 it exported the Length of a Side as 25.4 .. in both cases then when importing the DAE back into Sketchup it uses that bit of code. To repeat .. <unit meter=”0.0254″ name=”inch” /> .. or let’s look at it in mm ..

To repeat without all the Gobbly Gook ..

The problem is that MeshLab exports what appears to be a vanilla COLLADA file. Sketchup uses their own version which adds information such as for materials. As was stated by TIG the Sketchup DAE file has that line .. < unit meter=”0.0254″ name=”inch” /> which is not in the MeshLab DAE file. Without this Sketchup goes nuts with the sizing as it has no instructions.

I exported a 1 inch cube as a DAE .. brought it into MeshLab .. conveted to STL and saved as STL. Reloaded the STL and then exported back to DAE. I then imported that MeshLab DAE into Sketchup. The cube NOW measured 39.370 on a side (some rounding going on here by the way)

That is when I saw the missing ‘conversion code’. If you rework that formula a bit for millimeters you get <unit millimeter=”2.54″ name=”inch” /> .. which in a roundabout way let me to – 1000/25.4 = 39.371 (and change). which is the number of inches in a meter.

Sooo. Take the crazy dimension you get on a MeshLab DAE after importing into Sketchup and divide by that 39.370 (applied the rounding) to convert back correctly.