New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid "The mesh has naked edges" error #683
Comments
This is interesting, it looks like a coincident surfaces or edges issue. Not only does save/reload make it go away, but weather if fails or not depends on the length of the last extrusion. It's failing in raycast.cpp just below the section of code with this comment:
What does that mean? I've read this before and don't understand the comment, maybe because I don't fully understand what it's trying to do yet. |
Oh I had your if(vm < 0) { // happens when we revolve with negative theta
of = of.Minus(v);
v = v.ScaledBy(-1);
} in my tree an thought that was the reason. So I removed it and I still can not make it fail (wrong.zip) - shortening the last extrusion, deleting it an re-creating it - it works?! |
another test case (3.0~bcb8cd2c) |
@starsolaris What OS are you using? I don't have any problems wrong3 on Fedora Linux. I even asked it to show naked edges and none were found. |
@phkahler Windows 10 20H2 (19042.630) |
I can reproduce it as well (Windows 10) on 3.0.rc1 and my own master compile. |
Can either of you try a 64bit windows build? That should not be the fix, but if it works that could be a clue. |
@starsolaris I noticed that group g004 in the file wrong3 has one degree of freedom. I then found the following point can still be moved: It was visually on top of the corner point until I dragged it, but having points unconstrained when you want them coincident isn't really a great thing. Either make the 2 long lines in g004 eQual length, or delete the H constraint on that line and constrain the points coincident (select both and press O) - you only have 1 DoF left for that point, so you can't just make the points coincident without removing the H. See if this helps the problem with the later extrusion. |
@phkahler this is not help with the later extrusion |
@phkahler Ha! On one of my machines with MSVC 2019:
The exact same source (942bf3f) on the same machine with the same compiler version! WTF!?!?! My "favorite" type of problem... |
x86 uses the old x87 floating point unit where x64 mandates SSE2 and disallows x87. Contrary to what some people think, the fact that IEEE754 is a standard does not mean all floating.point operations produce the same result on different hardware. x87 uses 80 bits of precision internally for example. I suspect the issue here may be a comparison for exact equality somewhere that maybe should use an epsilon,, or something like that. Or maybe it's related to my changes in removing short segments, but I doubt that's it. It could be anywhere. |
What about the x86 "Release" target working? Probably compiler optimizes floating point math to SSE2 (64 bit floating point)... In fact there was a lengthy discussion on 80bit vs. 64 bit doubles back in March #565 and at the time Whitequark forced SSE2 on GCC and Clang in 645353c . My 32 bit (x86) Clang 11 (release) build on Windows works :-) |
System information
SolveSpace version: 3.0~6894b0c9
Operating system: Windows 10
Expected behavior
I should not see any errors
Actual behavior
After extruding
After save - load
If remove last extruding layer and create extruding again the error will be shown.
Additional information
wrong.zip
The text was updated successfully, but these errors were encountered: