STL imports below plate and cannot be moved

TheArtsyArtificer commented 3 years ago

Version

2.3.1

_Use `About->About PrusaSlicer PLATE R1.zip

Operating system type + version

Windows 7

3D printer brand / version + firmware version (if known)

Prusa MK3 s

Behavior

Describe the problem
I have been trying to import a part saved from solidworks, and it imports far below the build plate. thousands and thousands of inches below the build plate. I can manipulate the object in the X and Y axis, but not the Z axis.
Steps needed to reproduce the problem
Import the file.

Is this a new feature request? No

Thank you!

neophyl commented 3 years ago

Thats not the only problem. Note the listed size of the object. Its all zero.
I'm not sure exactly whats up with the model as its fully manifold and otherwise looks great. I took it into Blender and looked at it at the vert level and for the life of me I couldn't see anything wrong. Even re-exporting it causes the same problem.

I did find that if I used the delete redundant verts in Blender (which simplifies the whole thing) and then exported it that it would then load into PS fine with the correct size and placement. Hopefully the dev's can figure out what exactly it is.

TheArtsyArtificer commented 3 years ago

It said 0 on worlds coordinates and had size on local for the size. I saved it from a solidworks solid model.

Thank you so much for looking into it!

On Thu, Jul 1, 2021, 15:55 neophyl @.***> wrote:

Thats not the only problem. Note the listed size of the object. Its all zero. I'm not sure exactly whats up with the model as its fully manifold and otherwise looks great. I took it into Blender and looked at it at the vert level and for the life of me I couldn't see anything wrong. Even re-exporting it causes the same problem.

I did find that if I used the delete redundant verts in Blender (which simplifies the whole thing) and then exported it that it would then load into PS fine with the correct size and placement. Hopefully the dev's can figure out what exactly it is.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/6668#issuecomment-872509875, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUWG6QDKYGH767LTHWTYJ5DTVTBZZANCNFSM47VF2WYQ .

bubnikv commented 3 years ago

TriangleMesh TriangleMesh::convex_hull_3d() const fails to produce a convex hull. The code which centers an object on loading does not expect that.

bubnikv commented 3 years ago

This is how qhull complains about the input:

Qhull precision error: Initial simplex is flat (facet 4 is coplanar with the interior point)

While executing:  | qhull Qt
Options selected for Qhull 2015.2.r 2016/01/18:
  run-id 1206531982  Qtriangulate  _pre-merge  _zero-centrum  _max-width 2e+02
  Error-roundoff 0.00015  _one-merge 0.0011  _near-inside 0.0053
  Visible-distance 0.0003  U-coplanar-distance 0.0003  Width-outside 0.0006
  _wide-facet 0.0018

The input to qhull appears to be less than 3 dimensional, or a
computation has overflowed.

Qhull could not construct a clearly convex simplex from points:
- p7(v3): 1.2e+02 2e+02    80
- p27(v2):    80     0 1.2e+02
- p4(v1): 1.3e+02 1.8e+02    70
- p0(v0):    70 1.7e+02 1.3e+02

The center point is coplanar with a facet, or a vertex is coplanar
with a neighboring facet.  The maximum round off error for
computing distances is 0.00015.  The center point, facets and distances
to the center point are as follows:

center point    99.76    138.5    99.76

facet p27 p4 p0 distance= -7.6e-06
facet p7 p4 p0 distance= -7.6e-06
facet p7 p27 p0 distance= -7.6e-06
facet p7 p27 p4 distance=    0

These points either have a maximum or minimum x-coordinate, or
they maximize the determinant for k coordinates.  Trial points
are first selected from points that maximize a coordinate.

The min and max coordinates for each dimension are:
  0:     70.36     129.2  difference= 58.8
  1:         0     201.9  difference= 201.9
  2:     70.36     129.2  difference= 58.8

If the input should be full dimensional, you have several options that
may determine an initial simplex:
  - use 'QJ'  to joggle the input and make it full dimensional
  - use 'QbB' to scale the points to the unit cube
  - use 'QR0' to randomly rotate the input for different maximum points
  - use 'Qs'  to search all points for the initial simplex
  - use 'En'  to specify a maximum roundoff error less than 0.00015.
  - trace execution with 'T3' to see the determinant for each point.
  - recompile qhull for realT precision(#define REALfloat 0 in libqhull_r.h).

If the input is lower dimensional:
  - use 'QJ' to joggle the input and make it full dimensional
  - use 'Qbk:0Bk:0' to delete coordinate k from the input.  You should
    pick the coordinate with the least range.  The hull will have the
    correct topology.
  - determine the flat containing the points, rotate the points
    into a coordinate plane, and delete the other coordinates.
  - add one or more points to make the input full dimensional.
Unable to create convex hull

bubnikv commented 3 years ago

I did find that if I used the delete redundant verts in Blender (which simplifies the whole thing) and then exported it that it would then load into PS fine with the correct size and placement.

There are no duplicate vertices in the model. It may be that some vertices are very close, thus it causes the QuckHull library to fail on some numerical error. Interestingly enough just reshuffling the vertices helped. As I am seeing this issue for the first time, I may just try to reshuffle the vertices couple of times on QuickHull failure, which may reduce probability of the issue close to zero.

TheArtsyArtificer commented 3 years ago

That is a very interesting outcome. Solidworks is obviously generating some funky meshes. I have had other exports straight from solidworks that are non manifold. Thank you for looking into the issue. I will get blender loaded on my work computer!

Scott

On Mon, Jul 5, 2021, 05:28 Vojtěch Bubník @.***> wrote:

I did find that if I used the delete redundant verts in Blender (which simplifies the whole thing) and then exported it that it would then load into PS fine with the correct size and placement.

There are no duplicate vertices in the model. It may be that some vertices are very close, thus it causes the QuckHull library to fail on some numerical error. Interestingly enough just reshuffling the vertices helped. As I am seeing this issue for the first time, I may just try to reshuffle the vertices couple of times on QuickHull failure, which may reduce probability of the issue close to zero.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/6668#issuecomment-873959913, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUWG6QDLNVOSD2NZ2WKCKOLTWF3MRANCNFSM47VF2WYQ .

bubnikv commented 3 years ago

I cannot say that Solidworks generated a mess. Computational geometry algorithms are very sensitive to degeneracies (very close vertices, one vertex close to a plane given by other vertices and such). The QHull library we use for calculating convex hull is not stable to handle all the cases, however as I said, I am seeing a failure such as yours for the first time, so QHull is quite good.

I am looking into some pre-processing of the vertices before passing them to QHull, however it will not be a one liner and it will require careful testing.

po 5. 7. 2021 v 15:47 odesílatel TheArtsyArtificer @.***> napsal:

That is a very interesting outcome. Solidworks is obviously generating some funky meshes. I have had other exports straight from solidworks that are non manifold. Thank you for looking into the issue. I will get blender loaded on my work computer!

Scott

On Mon, Jul 5, 2021, 05:28 Vojtěch Bubník @.***> wrote:

I did find that if I used the delete redundant verts in Blender (which simplifies the whole thing) and then exported it that it would then load into PS fine with the correct size and placement.

There are no duplicate vertices in the model. It may be that some vertices are very close, thus it causes the QuckHull library to fail on some numerical error. Interestingly enough just reshuffling the vertices helped. As I am seeing this issue for the first time, I may just try to reshuffle the vertices couple of times on QuickHull failure, which may reduce probability of the issue close to zero.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/prusa3d/PrusaSlicer/issues/6668#issuecomment-873959913 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AUWG6QDLNVOSD2NZ2WKCKOLTWF3MRANCNFSM47VF2WYQ

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/6668#issuecomment-874127390, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMPSI2EWEIPYOEETDMRSFLTWGZW5ANCNFSM47VF2WYQ .

prusa3d / PrusaSlicer