Overlapping Geometry

Discussion in 'Technologies and Hardware' started by B1lancer, Dec 30, 2010.

  1. B1lancer
    B1lancer New Member
    I have had loads of models printed from shapeways and they all include overlapping geometry, each object is solid but they intersect.

    I am trying to get some tiny parts produced, 0.3mm wall thickness, Shapeways don't do this but Printapart do, although at a much greater cost which is why a use shapeways for the main models.

    Anyway to my point, it says on the printapart website:

    "Avoid overlapping geometries: these occur when a feature is created by making a separate piece, or "shell," that has a portion of its shape buried in another piece. A common example is the posts on jewelry when they're created as individual pins, with the base of each post buried into the jewelry. To save yourself the possibility of having to pay to redo your job, unite everything into a single shell before you submit it."


    Why is this a problem when it isn't for Shapeways?


  2. GHP
    GHP New Member
    Fairly recently, Shapeways added its "MeshMedic" feature that unifies overlapping meshes when they are uploaded (or at least eliminates overlaps), in addition to trying to fix other problems with the mesh such as holes or flipped normals. However, even before that, Shapeways never said that overlapping meshes were a problem, so I'm not sure why they are for Printapart.

    I did recently receive a full-color sandstone piece from Shapeways that was modelled with various overlapping components (each with its own UV map), including some text that I had embedded into the base. Some of the text had fallen out, leaving letter-shaped holes in the base. I suspect that in an effort to "unify" the meshes, MeshMedic did a boolean subtraction of the lettering from the base, leaving the lettering as an adjacent rather than an overlapping mesh, with color mapped onto the adjacent faces as well as the outer faces. I've been assuming that color mapped onto parts of meshes that are inside other meshes is simply ignored, but maybe I'm wrong in that assumption.
    Last edited: Dec 30, 2010
  3. bartv
    bartv New Member
    GHP is correct - our MeshMedic merges overlapping parts.

    As to problems with other services - I think you should discuss those on their forums, not here ;)


  4. GHP
    GHP New Member
    I mentioned my problem with the color print because I think possibly it did arise from my use of overlapping geometry, since the letters that fell out left letter-shaped holes where their meshes overlapped the base.

    I do wonder if there would be the same problem if the meshes were allowed to still overlap when the object was sent to the printer, however. I'm not familiar enough with the process to know if the printer would still try to color the embedded faces. Does anyone else know?


    Here's an illustration to help show the problem:

    Last edited: Jan 4, 2011
  5. bartv
    bartv New Member
    Wow, that *IS* odd and could point to a problem in the MeshMedic, I agree. Could you mail me the original file and the model ID on Shapeways so I can investigate? (bart@shapeways.com).


  6. GHP
    GHP New Member
    Actually, I've realized that probably the letters didn't fall out, but were removed by MeshMedic before it was printed. I deleted the original, but uploaded a very similar one to test this theory and found in the 3D viewer that this one was also missing letters, in most cases leaving holes.

    I guess I need to be a bit more careful about checking things in the 3D viewer before printing them. :blush:

    Thanks anyway!

    (Actually, if you do want to look at what MeshMedic did, check out my test example at http://www.shapeways.com/model/196935/test_wreath.html?gid=u g28511. The text on the back should read "Mimi, Christmas 2010". I think there are also holes where there should be a couple of holly berries on the front.)
    Last edited: Jan 5, 2011
  7. Kaetemi
    Kaetemi New Member
    Perhaps you accidentally inverted the faces of some of the letters?
  8. GHP
    GHP New Member
    No, there are no inverted faces in the original WRL file, but there do seem to be numerous small holes (according to MeshLab).
  9. bartv
    bartv New Member
    I've asked our development team to look in to this - I figure it would be better to receive a warning email instead of a misprint ;)

    I've also asked Customer Support to look in to this as you did not receive the object that you uploaded.

    Last edited: Jan 10, 2011
  10. RalphVdB
    RalphVdB Well-Known Member CS Team

    can you please sent an email to service[@]shapeways[dot]com

    We will arange you a refund then ;)

    Cheers, Ralph
  11. Kaetemi
    Kaetemi New Member
    Did you downscale the mesh at some point, and with which application?
  12. GHP
    GHP New Member
    @Kaetemi: I believe I did scale it down in Blender, so that the units would be metres instead of millimetres.

    @RalphVdB: I don't think I need a refund, but thank you anyway. I paid for it originally from a coupon I won in a contest, and it wasn't really a very successful design, even apart from my problems with MeshMedic.
  13. Kaetemi
    Kaetemi New Member
    That would be the source of the problem then likely. Small geometry such as letters may get bad faces when downscaling heavily due to precision errors with the vertex positions. I recommend downscaling with MeshLab after exporting, that seems to work a lot more reliably when scaling down.
    http://www.shapeways.com/forum/index.php?t=msg&th=4317&a mp;start=0&

    Perhaps we could get a working units selection for x3d and wrl files and so on? It'd be more convenient to be able to upload colored meshes in millimeters.

    Last edited: Jan 11, 2011
  14. aeron203
    aeron203 New Member
    I understand that the unit issue has something to do with meters being the native unit for WRL/X3D, but a workaround should be possible by premuliplying x1000 (mm would have to be the standard).

    Has PLY format been considered? It is compatible with Zcorp software and has no unit limitations. The files are also much smaller (binary), and it supports both face and vertex colors as well as UV coordinates.