USER FORUM
(you are viewing a thread; or go back to list of threads)
What do the red lines mean and how to overcome them (by James Cotsell)
Hi, I have been using SolveSpace for a while and there is something I have always been confused about. Sometimes when drawing a sketch on a face and then extruding it as a difference, I get a red line and one of the faces disappears. I am not sure why this happens. As an example I have attached a simple sketch I did to illustrate the point. I am sure someone will have a good explanation and many thanks for it.
(no subject) (by Daniel Engineering Solutions)
James,
This is a NURBS issue (basically a geometry calculation issue). In the property browser if you select "Force NURBS to Triangle Mesh" the red will go away. This will limit you to only exporting .stl files but if that's not an issue then it's what I would recommend. If you need to export .step files then there's a couple small work arounds but they're less than ideal. I believe there's a group of folks doing coding that are working fixing a majority of this issue for the future.
This is a NURBS issue (basically a geometry calculation issue). In the property browser if you select "Force NURBS to Triangle Mesh" the red will go away. This will limit you to only exporting .stl files but if that's not an issue then it's what I would recommend. If you need to export .step files then there's a couple small work arounds but they're less than ideal. I believe there's a group of folks doing coding that are working fixing a majority of this issue for the future.
(no subject) (by Paul)
Try starting over. Your file shows the problem, but I've tried to reproduce it from scratch twice with no luck. I tried drawing the second sketch on 2 different faces of my first extrusion. It worked fine both times.
This is a rare case of Solvespace NURBS failure that does not involve curved surfaces. I'm not sure why this is happening and really not sure why it's so difficult to reproduce.
This is a rare case of Solvespace NURBS failure that does not involve curved surfaces. I'm not sure why this is happening and really not sure why it's so difficult to reproduce.
(no subject) (by Paul)
On further investigation I found a new clue. I drew a rectangle and extruded it. Then drew a triangle on one side of the extrusion - by side I mean face perpendicular to the original rectangle sketch. Be sure the triangle includes one side aligned with the original sketch. For simplicity I tied all 3 points of the triangle to points on the box. Extrude the triangle as a difference. Everything is fine. But when I look at the triangular face and drag the extrusion in the opposite direction - the other side of the first sketch plane - it fails. Dragging back and forth it clearly fails only on one side but not the other.
This is also true with your sketch. Pull the extrusion in the opposite direction of the Z-axis and the problem will go away.
This is also true with your sketch. Pull the extrusion in the opposite direction of the Z-axis and the problem will go away.
(no subject) (by ruevs)
In don't see any naked edges (red lines) in this model. I'm on the phone so I opened it in the Web version here http://orthogonal.cc/solvespace/solvespace.html
When I'm on a PC I'll try with the Windows version.
When I'm on a PC I'll try with the Windows version.
(no subject) (by Paul)
I can't reproduce it on the web version drawing from scratch either. This is weird.
(no subject) (by Paul)
@ruevs I rebuilt the desktop version without OpenMP and drew a problematic sketch and it worked. Saved that sketch. Recompiled with OpenMP, opened the saved sketch and it was broken. Looks like something isn't thread safe.
I tried this because I remembered the web version is single threaded...
I tried this because I remembered the web version is single threaded...
(no subject) (by Paul)
@ruevs if we comment out the line:
#pragma omp parallel for
from the function SShell::CopySurfacesTrimAgainst() the problem goes away. I'm busy this weekend, so I'll try to chase it down next week. Very strange that it comes and goes when the extrusion is flipped AND it's a concurrency issue.
#pragma omp parallel for
from the function SShell::CopySurfacesTrimAgainst() the problem goes away. I'm busy this weekend, so I'll try to chase it down next week. Very strange that it comes and goes when the extrusion is flipped AND it's a concurrency issue.
(no subject) (by ruevs)
Paul, that's a great find! I'll be away from PCs next week but it will be VERY interesting what you find. This being a thread safety problem is indeed unexpected.
(no subject) (by Paul)
I've opened an issue on github for this one here:
https://github.com/solvespace/solvespace/issues/1619
https://github.com/solvespace/solvespace/issues/1619
Post a reply to this comment: