Front_half, back_half.
Any reason why this gives me an error like this:
WARNING: [manifold] Minkowski failed with error, falling back to Nef
operation: bad any_cast
Code:
include <BOSL2/std.scad>
$fn=$preview ? 60 : 180;
back_half() plate();
module plate() {
cuboid([100,100,5],rounding=1.5,teardrop=true);
}
It sometimes works,and it sometimes works with front_half(),
and I have yet to have it work with both.
Do I have to go back to just differencing them with a cube?
Larry
On 8/17/26 2:35 PM, larry via Discuss wrote:
Any reason why this gives me an error like this:
WARNING: [manifold] Minkowski failed with error, falling back to Nef
operation: bad any_cast
Code:
include <BOSL2/std.scad>
$fn=$preview ? 60 : 180;
back_half() plate();
module plate() {
cuboid([100,100,5],rounding=1.5,teardrop=true);
}
It sometimes works,and it sometimes works with front_half(),
and I have yet to have it work with both.
Do I have to go back to just differencing them with a cube?
back_half/front_half are literally just differencing with a cube. Fun
problem you got there :). (I assume you know it comes from the
rounding/teardrop)
Cory
On Aug 17, 2026, at 3:48 PM, Cory Cross via Discuss discuss@lists.openscad.org wrote:
back_half/front_half are literally just differencing with a cube. Fun problem you got there :). (I assume you know it comes from the rounding/teardrop)
Cory
Technically, they are intersection()ing with a cube. And yes, the cuboid() with the teardrop rounding internally does a minkowski(). I don't know why minkowski occasionally fires that message, but it should be harmless.
- Revar
On Mon, 2026-08-17 at 17:42 -0700, Revar Desmera via Discuss wrote:
On Aug 17, 2026, at 3:48 PM, Cory Cross via Discuss
discuss@lists.openscad.org wrote:
back_half/front_half are literally just differencing with a cube.
Fun problem you got there :). (I assume you know it comes from the
rounding/teardrop)
I definitely did not know that.
Technically, they are intersection()ing with a cube. And yes, the
cuboid() with the teardrop rounding internally does a
minkowski(). I don't know why minkowski occasionally fires that
message, but it should be harmless.
Thank to both. I'll change the bottom to have no rounding.
I agree it should be harmless, but after I get the warning, it often
(perhaps always) needs to be forced to exit.
Larry
On Mon, 2026-08-17 at 17:42 -0700, Revar Desmera via Discuss wrote:
Technically, they are intersection()ing with a cube. And yes, the
cuboid() with the teardrop rounding internally does a
minkowski(). I don't know why minkowski occasionally fires that
message, but it should be harmless.
Small tip:
I've found that "intersection" somehow is much slower than difference.
So whenever I do a "half" of something I will difference out the half
I don't want as opposed to intersecting with a cube across the part
that I do want.
Same with Minkovski. It is usually very slow.
So instead of
minkovski () {
cube ([x,y,z], center=true),
sphere (r);
}
I will rather do:
hull () {
mz () dup4 () translate ([x/2,y/2,z/2]) sphere (r);
}
where mz mirrors a copy in z direction, and dup4 rotates around z to
produce 4 copies. (I also have dup2 (), dup3 () and dupn (n) . )
(live-coding while writing an Email: The rounded cube becomes bigger
than the xyz provided. Doing a real project I'd correct for that.)
Premature optimization is the root of all evil.
But in this case, the optimized code isn't all that unreadable,
and it will speed up your development cycles as you'll be quicker
to see you've made a mistake, fix it and try again.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
On 8/19/2026 3:08 AM, Rogier Wolff via Discuss wrote:
I've found that "intersection" somehow is much slower than difference.
So whenever I do a "half" of something I will difference out the half
I don't want as opposed to intersecting with a cube across the part
that I do want.
Same with Minkovski. It is usually very slow.
Minkowski is very slow.
I think that intersection is slow only for preview, not for render.
Previewing is black magic. I understand how union works in preview - it
draws all of the pixels, and retains the one that's closest to you. I
have occasionally understood how difference works in preview, kind of.
How intersection works is beyond me, but my understanding is that
combinations involving intersection can make the complexity of the
preview processing skyrocket.
On Thu, Aug 20, 2026 at 04:41:02PM -0700, Jordan Brown wrote:
I understand how union works in preview - it
draws all of the pixels, and retains the one that's closest to you. I
have occasionally understood how difference works in preview, kind of.
How intersection works is beyond me,
Ahhh! That makes sense! But I still care about preview speed: That is
what influences my development cycle.
In fact, I have a background process running that will start a render
and export-to-stl behind the scenes, so whenever I've convinced myself
I'd like to go ahead and print my design, the background process will
have finished rendering my project. So almost never do I have to wait
for that to finish. (I can even start arranging things in the slicer
and if I'm afraid I was too quick and didn't catch the last change, hit
F5 in the slicer once the rendering has finished.
But since "manifold" renders of more than a few seconds are a thing of
the past. (With occasionally preview-rendering problems, I wish there
would be an "auto-render" as well as the "auto-preview" that I use
now).
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.