<J1A84>
so seems not to be so simple that "scale" knows if it scales a 2D object
<InPhase>
J1A84: That's in a list of such issues. Compare preview and render: rotate([30, 20, 10])translate([3,3,23])scale([1,1,20])square(5);
<InPhase>
Yet magically if you do this, they become equivalent again: projection()linear_extrude(1)rotate([30,20,10])translate([3,3,23])scale([1,1,20])square(5);
<J1A84>
had the impression that a projection is made for any 2D object before extrude or render
<J1A84>
render()scale([1,1,20])square(5);
<InPhase>
Well if you treated that 2D object as shown in preview like a 3D object and did a projection on that, you'd get a very different result than the equivalency obtained here.
<InPhase>
Instead the projection()linear_extrude(1) causes it to be processed in the specified OpenSCAD engine way instead of in the preview display system way.
<J1A84>
oh you can't do a projection on a 2D object
<J1A84>
moving 2D in 3D is probably a bad idea in general or rotating .. but scale is something used more often
<InPhase>
Yeah, they should probably all be restricted in principle. There is probably code out there making use of this bug, as usual.
<J1A84>
skewing and z translations are just removed when rendering
<J1A84>
i am using rotate on a colored square to get the color right for backgrounds because of that diagonal lighting
<InPhase>
And if you want me to prove the current behavior is insane, compare these: https://bpa.st/KZ2Q
<InPhase>
preview vs render again
qeed has joined #openscad
<InPhase>
Basically, if you do any of these operations, your preview is just wrong, and only gets more horribly wrong the more such things you stack onto it, unless you add something that undoes the crazy.
<J1A84>
the translate just uses xy then it will match
<J1A84>
but translating z for polygons can be helpful to layer them with color - but using a 3D object would work too .. is there any advantage of using 2D instead of 3D in preview?
califax has quit [Remote host closed the connection]
<InPhase>
I think the preview system we use doesn't handle 2D, so we fake it with a fixed width.
<J1A84>
and boolean fail if not coplanar
<InPhase>
The proper "fix" for this is to just make sure every 2D operation does not do the bad things, or collapses them like the offset operation does. (Which if I'm remembering correctly makes use of clipper, and thus does some sort of transformation of data to get there.)
<InPhase>
Or alternatively, we should probably just render all 2D top-level objects.
<InPhase>
I don't think I have EVER seen an OpenSCAD design where rendering of a top-level 2D object was too slow to just render it.
califax has joined #openscad
<J1A84>
not sure about fractals but in general it probably would be a solution - and education like .. you want to do 3D stuff .. use 3D objects
<J1A84>
i mean could be a feature that is default on .. and can be deactivated
califax has quit [Ping timeout: 268 seconds]
califax has joined #openscad
teepee has quit [Quit: bye...]
teepee has joined #openscad
califax_ has joined #openscad
califax has quit [Ping timeout: 268 seconds]
califax_ is now known as califax
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
Guest48 has joined #openscad
<Guest48>
I need a can smasher
Guest48 has quit [Client Quit]
jonasbits has joined #openscad
teepee has quit [Quit: bye...]
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
teepee has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
califax has quit [Remote host closed the connection]
TheAssassin has quit [Remote host closed the connection]
<JordanBrown>
WRT 2D, I think that maybe we should change the 2D preview to preview the same way that incomplete polyhedra are previewed - as zero-thickness objects. That *might* also suggest allowing 3D operations on them.
<joseph_>
InPhase: I saw your comment about the failing tests. I will try running them locally as you suggested, in addition to working more on a fix for the color and edge bugs. I think the edge issues might be part or all of what is causing the tests to fail at this point, because now the default shader in F6 mode shows edges when it shouldn't be
teepee has quit [Remote host closed the connection]
TheAssassin has quit [Read error: Connection reset by peer]
aiyion1 has quit [Write error: Connection reset by peer]
califax has quit [Write error: Connection reset by peer]
<JordanBrown>
Perhaps 2D objects would be their current special objects, except (a) transformed into incomplete polyhedra for preview, and (b) transformed into incomplete polyhedra when used in a context where a 3D object is required. That latter might (or might not) include anything that moves them off the XY plane.
<J1A84>
scale([1,1,.00005])square(5);
<JordanBrown>
Yeah, but (a) that's not the default and (b) very thin is not the same as zero thickness.
<JordanBrown>
We can preview zero-thickness objects; why not use that capability for these objects that are theoretically zero thickness.
<J1A84>
it is just a preview - so it really doesn't matter
<JordanBrown>
To be clear: my polyhedron() example above was not intended for any production use, but rather to demonstrate what I meant by using an incomplete polyhedron to represent a 2D object.
<JordanBrown>
Somebody was just expressing confusion about the Z behavior of 2D objects, right? Making them be real 2D objects might help.
<JordanBrown>
Then you could scale them in Z all you like, and they wouldn't change.
<J1A84>
do that again when it is moved .1 in Z .. the problem is in the hole chain
<J1A84>
in theory we could remove all 2D object and just use projection for 2D output
<JordanBrown>
I don't understand what problem you're referring to when you talk about moving 0.1 in Z. Example?
<JordanBrown>
What's the problem? That looks like the result is exactly right.
<JordanBrown>
It's a zero-thickness object that's 0.1 up from the origin. When scaled by 10,000x it's still a zero-thickness object and the offset from the origin has been scaled to Z=1000.
<JordanBrown>
The problem that I see is that our existing 2D objects aren't really 2D. They are 2D for some purposes, but not for others. It would be better if they were 2D for all purposes.
<JordanBrown>
Actually, that's not quite right. I *would* allow 2D objects to be moved around in 3D space.
<JordanBrown>
Though I am not sure how that would then interact with operations that require 2D objects, like linear extrude and offset.
<J1A84>
then you get problems for boolean operations as rotations can cause floats and you will get z-fighting
<JordanBrown>
There are, I am sure, a ton of questions to be answered.
<JordanBrown>
Indeed, what is the result of boolean operations on 2D objects that are not on the XY plane?
<J1A84>
it could open a way for multi level/layer 2D files
<JordanBrown>
Yes.
<J1A84>
with lazy union you already can export two overlapping polygons
<JordanBrown>
But the first thing, I think, is that preview shows 2D objects with a non-zero thickness, and that causes problems.
<JordanBrown>
As noted, 3D scale on 2D objects behaves wrong.
<J1A84>
i can't see how this solves the problem that scale will scale z on 2D objects
<JordanBrown>
scale() on my sq() object seems like it behaves exactly correctly.
<J1A84>
because your sq() is a 3D object
<JordanBrown>
Yes, but why is square() getting scaled in Z? I assume that at some level the previewer is turning it into a 3D-ish object with height 1, and *after* that the scaling gets applied.
<JordanBrown>
If that magic transformation instead turned it into a 3D-ish object with height zero, equivalent to sq(), then scaling would behave correctly.
<J1A84>
as InPhase already said render() solves all these problems.
<JordanBrown>
render() is a hack.
<J1A84>
no preview is the hack
<JordanBrown>
OK, I can accept that too.
<J1A84>
Ü
<JordanBrown>
But any time you need render() indicates a flaw in preview.
aiyion1 has quit [Remote host closed the connection]
<J1A84>
sure because the display of 2D objects is obviously already a hack
aiyion1 has joined #openscad
<JordanBrown>
And would be less of a hack if they were displayed as zero-thickness 3D objects.
<J1A84>
and everytime you involve an new operation on the 2D object like offset it get reset
<JordanBrown>
"it" being the thickness?
<J1A84>
no the z value
<J1A84>
offset(5)translate([0,0,5])square(10);
<JordanBrown>
Yeah, I don't have a strong opinion on what should happen in that case.
<J1A84>
sure the scale (z) also gets reset .. or better to say a new 2D object is generated without the flaws introduced by the 3D operations before
<JordanBrown>
I think that maybe offset() should have an implied projection().
<JordanBrown>
But also I suspect that those are mostly independent of the pseudo-thickness that 2D objects get.
<J1A84>
how we later display 2D objects - if with zero height to vanish in side views .. or centered with height 1 is independent from that
<JordanBrown>
Yes, I think so.
<JordanBrown>
I'm a little surprised that scale() affects the pseudo-thickness of 2D objects.
<J1A84>
yeah i was too .. more that is has consequences for a difference
<JordanBrown>
because it's clear that scaling gets applied *after* the pseudo-thickness gets added.
<JordanBrown>
Boolean operations on 2D objects that have been moved off of the XY plane are not obvious.
<J1A84>
no but if you remove a square from a scaled square .. as both centerlines are still on z=0
<JordanBrown>
Sure. When both are still on the XY plane the operations are obvious 2D operations.
<JordanBrown>
and all that is, I think, correct today.
<JordanBrown>
I don't know what the behaviors all are when you move 2D objects off of the XY plane and then do boolean operations on them. I wouldn't be surprised if they are ... not entirely obvious.
<J1A84>
it is just the order of commands , scale should get a 2D object not a 3D object
<JordanBrown>
And I assume that all works correctly today.
<J1A84>
try it
<JordanBrown>
But that didn't involve moving the 2D objects off of the XY plane.
<J1A84>
issue 1646 is about this
<JordanBrown>
Eww.
<J1A84>
and open since 2016
<J1A84>
besides the z fighting on the vertical faces
<JordanBrown>
Yeah, but that's a symptom of the deeper problem, that the 2D objects got turned into 3D objects and that a 3D difference is being done on them.
<JordanBrown>
There shouldn't *be* any vertical faces.
<J1A84>
yes in a perfect world
<J1A84>
so annoying that calculations with computer floats is such a flawed thing
<JordanBrown>
You don't even need scale() to get the Z-fighting; it happens on a straightforward difference() {square(5); square(2)}.
<J1A84>
yes .. it also shouldn't on 3D objects (in theory)
<JordanBrown>
For some reason I thought that Boolean operations on 2D objects were handled using a 2D subsystem. Maybe that's only for the full render.
<J1A84>
from what InPhase said i understand that preview is a 3D system that can't handle 2D
<J1A84>
not sure if we get issues when 2D are used a polyhedra with 1 face or manifold faces
<JordanBrown>
Well, I was just experimenting with difference() on my sq() function, and that yields ... interesting ... results.
<JordanBrown>
First, from above, the smaller square doesn't get removed.
<JordanBrown>
Second, from below, the whole thing disappears.
<JordanBrown>
Well, that kind of explains why preview uses a non-zero thickness.
<J1A84>
difference(){sq(5);translate([3,0])sq(5);} is not working in preview (and sure not in render)
<J1A84>
}
<JordanBrown>
Render doesn't like sq() at all, because it's not closed.
<JordanBrown>
But that aspect seems tied up in the magic that preview uses to turn 2D objects into pseudo-3D objects.
<JordanBrown>
More precisely, and what I hadn't realized, is that preview's boolean operations can't handle true 2D objects.
<JordanBrown>
Preview can *display* a true 2D object just fine, ref sq().
<J1A84>
again this is not a 2D object (and a boolean operation is not working on it )
<J1A84>
only because something looks like 2D doesn't make it 2D
<JordanBrown>
I think that's a terminological problem.
<J1A84>
your sq has a thickness of 0 .. so it is 3D .. what you need is the lack of thickness as in 2D
<JordanBrown>
square() yields an object that OpenSCAD calls 2D, but that is previewed, and preview operations on, as if it was 3D.
<JordanBrown>
sq() yields an object that OpenSCAD calls 3D, but that is previewed in 2D.
<J1A84>
because preview can only handle 3D objects .. all 2D must be extruded to be displayed .. you sure can do this with 1 or with .001
<J1A84>
you need to understand that a face of a polyhedron is part of a 3D object
<JordanBrown>
preview can *display* zero-thickness objects like sq(). But it can't operate.
<JordanBrown>
Can't operate on them, that is.
<J1A84>
you can export those and they save as 3mf/stl but not as svg
<JordanBrown>
Yes, I understand that OpenSCAD considers sq() to be a 3D object.
<JordanBrown>
But preview, as long as you don't try to do any boolean operations on it, shows it the way that a 2D object should be shown: with zero thickness.
<J1A84>
this is why i wrote scale([1,1,.001])square(5); because this is a 2D object that is displayed with 0 thickness
<JordanBrown>
but it's not zero thickness... it's just very thin. scale([1,1,10000]) scale([1,1,0.001]) square(5) will still behave poorly.
<J1A84>
scale([1,1,0]) shouldn't be a problem for 2D objects ..
<JordanBrown>
one would hope not, though now that I'm seeing these preview issues I wonder if it is.
<J1A84>
you can use scale([1,1,0.0000000000000000000000000000001]) ..
<JordanBrown>
Yeah, if you also magically squash the Z scale to 1 when the children are 2D. Otherwise your difference() { scale(2) square(5); square(2); } example will still misbehave.
<J1A84>
the precision can be far over the precision of stl/3mf/svg or even scad .. so is the question if there is a 3rd dimension left
<JordanBrown>
It might work if you get down below the resolution of some of the processing, but I wouldn't be surprised if the result is Z-fighting.
<JordanBrown>
difference() {
<JordanBrown>
scale([1,1,0]) square(5);
<JordanBrown>
}
<JordanBrown>
scale([1,1,0]) square(2);
<JordanBrown>
works, kind of, but Z-fights.
<JordanBrown>
If the zero was instead some very small value, smaller than the resolution of some of the processing, then I suspect it would *be* zero for the purposes of that processing.
<JordanBrown>
In particular I suspect that the previewer has a depth resolution, and if the depth difference between two objects is smaller than that depth resolution, you'll get Z-fighting.
<JordanBrown>
But hmm.
<JordanBrown>
linear extrude apparently really does the 2D boolean operations before constructing a 3D object.
<JordanBrown>
preview of a 2D object could do the same thing.
<J1A84>
causes warnings here so it doesn't work but you can use so small values that they can't be inflated anymore https://bpa.st/CRNQ
<JordanBrown>
how many zeroes is that on the right?
<J1A84>
a lot ..
<JordanBrown>
64-bit float has a smallest value of 10^-300 or so.
<JordanBrown>
10^-308 is closer. But when you're talking about numbers that small, 8 orders of magnitude isn't much :-)
<J1A84>
it is just to argue that this is previewed as 2D object as no scale value can make it thicker
<JordanBrown>
But is it different from a Z scale of zero?
<J1A84>
yes it will not produce a warning
<J1A84>
and sure it is a flaw or hack
<J1A84>
but float and precision is already a flaw in math
<JordanBrown>
Eh, not clear that we're seeing any float issues here.
<JordanBrown>
float is overrated as a supplier of problems.
<JordanBrown>
but the reason that your outer scale didn't scale it up unreasonably is that your inner scale is about 10^-196, while your outer scale is only 10^45 or so. Your object is still ~10^-150 thick.
<JordanBrown>
and yes, the result will be that no reasonable scale() will bring it back up to a visible thickness.
<JordanBrown>
but scale(2) will still make it twice as thick as scale(1) and so difference will misbehave.
<JordanBrown>
Or it will be below the depth resolution of the previewer and will Z-fight.
<J1A84>
No try to make the outer scale bigger .. you will not be able to
<J1A84>
and i don't mean "reasonable" i mean it is not possible
<JordanBrown>
Why do you say that?
<JordanBrown>
I just made the outer scale be ~10^214 and it worked OK, and displayed something stupid.
<J1A84>
the number is under the precision of scad so it is 0 and there is no number you can multiply 0 to get more
<JordanBrown>
which "precision of scad"?
<JordanBrown>
In a full render there's a grid snap, but does preview have that?
<JordanBrown>
Floating point is perfectly capable of multiplying 10^-196 by 10^214 and getting the right answer, give or take a very small amount.
<J1A84>
the point is that scale should detect a 2D flag and only use scale.xy
<JordanBrown>
when exporting, sure, there are various resolution limits. But the resolution limits on scaling operations are very different.
<J1A84>
the limit is scale([1,1,.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001])
<JordanBrown>
and very hard to reach.
<JordanBrown>
Yes, *that* is small enough to hit the limits.
<J1A84>
if something gets small enough not to cause problems .. the problem is gone. e.g z-fighting in games is solved with some of these approaches as you can not get rid of it but you can prevent it from beeing seen.
<J1A84>
so if preview can not handle 2D objects .. but you want zero height .. it is enough to reduce the height to a value that it will not become big enough to be drawn as a pixel
<JordanBrown>
but making squares that thin mean you have Z fighting on difference() { scale(2) thin_square(10); thin_square(10); }.
<J1A84>
probably the reason why preview uses height=1
<JordanBrown>
well, yeah, except that we've seen that preview Z-fights even simple 2D differences :-(
<JordanBrown>
But what I want to know is what linear_extrude does first, to get the actual outline of the 2D object after the boolean operations. It must do a 2D equivalent of render().
<JordanBrown>
Doing *that* before previewing a 2D object, *after* applying the Boolean operations, might be the ticket.
<JordanBrown>
But I need to go understand how 2D objects really work.
<J1A84>
only on vertical walls relative to the object even if turned 90° rotate([90])difference(){square(10);square(9);}
<J1A84>
you do remember that i told you that "render()" solves this and you argued .. and now you came up with that solution and it is ok for you - Ü glad we found your solution
<JordanBrown>
Having OpenSCAD do it internally is very different from asking the user to do it in their OpenSCAD program.
<JordanBrown>
But I need to run an errand, and while I'm sure you'll be disappointed to drop this for now, I have to... :-)
<J1A84>
it is what InPhase said to introduce a automatic render at toplevel for 2D objects .. you may missed that part of the discussion
<JordanBrown>
Probably did.
<J1A84>
belive me i am more than happy to drop this aeons ago
califax has quit [Remote host closed the connection]
califax has joined #openscad
<JordanBrown>
I learned some important stuff, and it might prompt me to work on it, because the non-zero thickness of 2D objects bugs me.
<JordanBrown>
Anyhow, thanks, later.
califax has quit [Remote host closed the connection]