USER FORUM
(you are viewing a thread; or go back to list of threads)
Feature idea: intersection option for extrude (by Azial)
So, in the extrude feature you can choose between union and difference. Basically + and - operations.
Sometimes it would be useful to have an "AND" operation (intersection). Would this be difficult to implement?
Sometimes it would be useful to have an "AND" operation (intersection). Would this be difficult to implement?
(no subject) (by Paul)
On a slightly related note (NURBS booleans) I was learning some of the code by trying to implement frustum extrusion where the top of the extrusion is a scaled version of the bottom. I realize this is not a very useful feature but it's a start on learning some things. The odd thing I noticed is that sometimes the normal of a sketch is reversed and this is handled in the following part of surface.cpp
SShell::MakeFromExtrusionOf(...)
...
if((t0.Minus(t1)).Dot(sbls->normal) < 0) {
swap(t0, t1);
}
This is swapping the vectors to offset the ends of the extrusion and it causes my asymmetric extrusion to flip ends (normal and resized). It will actually flicker between the two options if I drag a point in the underlying sketch. If these lines are commented out, it will stop flipping but instead in one case the surface will be inside out (rendered as red) and it will flicker between normal and red. This seems more common if the sketch contains an arc and not just straight segments.
I have a test file that shows intermittent NURBS boolean issues where determining inside/outside seems to be at the core of the problem. I'm wondering if these are related.
Lastly, is there a preferred place to discuss this type of thing other than filing a bug on github? My code is just an experiment so reproducing the bug isn't really sensible. Also, I'd like to ask questions about the internal data structures and such - there is a lot of apparent redundancy though I think there are valid reasons for it. There is no documentation to the code and internals as far as I can tell.
BTW you might be able to reproduce the red/normal phenomenon by commenting out the swap mentioned above and dragging around points in the underlying sketch of an extrusion (make a rectangle with one rounded corner). It's not really a bug but I wonder why it happens and think it may be related to some issues.
Thanks,
Paul
SShell::MakeFromExtrusionOf(...)
...
if((t0.Minus(t1)).Dot(sbls->normal) < 0) {
swap(t0, t1);
}
This is swapping the vectors to offset the ends of the extrusion and it causes my asymmetric extrusion to flip ends (normal and resized). It will actually flicker between the two options if I drag a point in the underlying sketch. If these lines are commented out, it will stop flipping but instead in one case the surface will be inside out (rendered as red) and it will flicker between normal and red. This seems more common if the sketch contains an arc and not just straight segments.
I have a test file that shows intermittent NURBS boolean issues where determining inside/outside seems to be at the core of the problem. I'm wondering if these are related.
Lastly, is there a preferred place to discuss this type of thing other than filing a bug on github? My code is just an experiment so reproducing the bug isn't really sensible. Also, I'd like to ask questions about the internal data structures and such - there is a lot of apparent redundancy though I think there are valid reasons for it. There is no documentation to the code and internals as far as I can tell.
BTW you might be able to reproduce the red/normal phenomenon by commenting out the swap mentioned above and dragging around points in the underlying sketch of an extrusion (make a rectangle with one rounded corner). It's not really a bug but I wonder why it happens and think it may be related to some issues.
Thanks,
Paul
(no subject) (by Jonathan Westhues)
There's some discussion of intersection in particular at
https://github.com/solvespace/solvespace/issues/35
This forum here is a good place to discuss surface operations (or other internals) in general. GitHub is good for specific bugs or proposed features.
When curves in a workplane get assembled into loops to make one of the faces to extrude, the direction in which they're assembled is arbitrary, so the direction of the normal is arbitrary. We don't know at that time whether the extruded solid will be above the plane, or below the plane, or whether the loops will be used for a purpose totally unrelated to extrusion.
The SWAP(...) that you mention above makes the normal direction consistent with the extrusion direction. That SWAP(...) is a necessary piece of bookkeeping, but a really trivial one--there are two possibilities, and that line of code picks the right one.
The problem of determining how surfaces intersect in Booleans is much more difficult and complex, with orders of magnitude more cases. Incorrect classifications there (due to numerical problems, or unhandled special cases of all the ways surfaces can be inside/outside/coincident/edge-on-surface/edge-on-edge/vertex-on-surface/...) typically account for failed Booleans.
https://github.com/solvespace/solvespace/issues/35
This forum here is a good place to discuss surface operations (or other internals) in general. GitHub is good for specific bugs or proposed features.
When curves in a workplane get assembled into loops to make one of the faces to extrude, the direction in which they're assembled is arbitrary, so the direction of the normal is arbitrary. We don't know at that time whether the extruded solid will be above the plane, or below the plane, or whether the loops will be used for a purpose totally unrelated to extrusion.
The SWAP(...) that you mention above makes the normal direction consistent with the extrusion direction. That SWAP(...) is a necessary piece of bookkeeping, but a really trivial one--there are two possibilities, and that line of code picks the right one.
The problem of determining how surfaces intersect in Booleans is much more difficult and complex, with orders of magnitude more cases. Incorrect classifications there (due to numerical problems, or unhandled special cases of all the ways surfaces can be inside/outside/coincident/edge-on-surface/edge-on-edge/vertex-on-surface/...) typically account for failed Booleans.
Post a reply to this comment: