<InPhase>
JordanBrown: To summarize my thoughts, I think auto-render on 2D pieces reaching top level is a reasonable solution for preview because I also see fast-csg pushing us closer to the point where we eventually don't even need preview.
teepee_ has joined #openscad
<InPhase>
There is just one lurking big problem, and that's color support.
<InPhase>
BUT, we need to solve color support anyway, because we're soon going to need some smart solution for models for multimaterial and multicolor 3D printers.
<JordanBrown>
Hmm. Yeah, I bet something bad happens to the color of 2D objects when you process them.
<JordanBrown>
I did some experimenting (though right now I don't entirely remember how) with a scheme where an "object" would really be a set of multiple objects, one for each material, and where operations on that object would do something right-ish with respect to materials.
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
<InPhase>
JordanBrown: We already have broken color support for 2D like such: offset(3){color("blue")square(8);color("red")circle(5);}
<JordanBrown>
Yeah, and linear_extrude() of a multi-colored object.
<JordanBrown>
But breaking color support on offset() doesn't really bug me. Sometimes you do an operation that's radical enough that it's not clear what the separation between colors means.
<InPhase>
Even linear_extrude of a single color object fails.
<JordanBrown>
Just like I wouldn't ask to preserve colors across hull(), if the children are different colors.
<JordanBrown>
Fails in the sense of losing the color?
<InPhase>
Yes.
<JordanBrown>
For offset and hull, I'd say that it's OK to break colors in multi-color cases, desirable (but not required) to preserve it in single-color cases.
<JordanBrown>
But I *think* that linear extrude could do it right even for multi-color cases, and it would be nice to get that right.
<InPhase>
So we basically have no way to make colored 3D objects inheriting their color from 2D at present. Hence I pretty much never color a 2D object outside of demos.
<JordanBrown>
Yeah, makes sense.
<InPhase>
However, if we reason out how to color 3D objects for render, we could probably backport this support to 2D tracking of it.
<JordanBrown>
My multi-color theory first started with defining the operations:
<JordanBrown>
Union - first (or last) object wins. Being like paint is last-wins.
<JordanBrown>
Intersection - only the first object matters
<JordanBrown>
Difference - only the first object matters
<InPhase>
We currently for preview color the carved out piece by the differenced color.
<InPhase>
But I think what you wrote makes more sense when thinking about volumes of material.
<JordanBrown>
yes, exactly.
<InPhase>
You don't paint with your chisel. :)
<InPhase>
Well, usually anyway.
<JordanBrown>
having difference paint the cut section is nice in some ways, but doesn't make any sense at all for volumes, and we want to support volumes here.
<InPhase>
Yeah. I've used it conveniently for some pretty artwork that would be broken. But that's okay.
<JordanBrown>
As have I.
<JordanBrown>
So if we have an object defined as a set of individually-colored non-overlapping objects...
<JordanBrown>
difference involves taking the original sub-objects, and differencing the later arguments from each of them.
<JordanBrown>
intersect is similar.
<JordanBrown>
union is the tricky one.
<InPhase>
Union is especially tricky because of the surface representation of volumes that we do.
<JordanBrown>
union would, for each color in A, keep A, and for each color in B, keep (B-A).
<InPhase>
Let's say we have a cube which is half red and half blue. How do we even represent that? How do we save it out?
<JordanBrown>
Dispensing with the second question first: however the export format wants it. For STL, we'd need to generate two STLs.
<InPhase>
The overlap issue is confusing.
<JordanBrown>
Hence my initial definition of the desired result.
<InPhase>
No, I mean in the final result, after those decisions.
<InPhase>
How do we make clear that these are "one object with two colors".
<JordanBrown>
Internally?
<InPhase>
Rather than "two objects with two colors"
<JordanBrown>
Internally, it would be one "object" with two "sub-objects".
<JordanBrown>
The two sub-objects would each be a single color, and would be non-overlapping.
<JordanBrown>
Every operation is required to take as input objects like that - sets of single-color sub-objects - and produce such a thing as its output.
<JordanBrown>
It lets you create cubes of different colors, and then union, intersect, difference, et cetera them.
<JordanBrown>
Here's the key part of a union:
<JordanBrown>
// Last paint wins, so n1's colors show through
<JordanBrown>
union() {
<JordanBrown>
// only where it is not in common with n2.
<JordanBrown>
eval1(n1);
<JordanBrown>
difference() {
<JordanBrown>
eval1(n2, $color=undef);
<JordanBrown>
}
<JordanBrown>
eval1(n2);
<JordanBrown>
}
<JordanBrown>
and that gets processed for each color in the model.
<JordanBrown>
Does that all sort of make sense?
<JordanBrown>
Unfortunately, I suspect that it would mean that render times would increase by at least the number of colors, and maybe by the square of the number of colors.
<JordanBrown>
Maybe not, if processing an infrequently-used color leads to lots of null intermediate objects.
<JordanBrown>
I use "color" here, but really the same logic applies to any kind of "material" distinction.
<JordanBrown>
It might even be possible to do entirely downstream of the CSG tree.
<JordanBrown>
That is, build a CSG tree as it's built today, and have the volumetric-color work all be in the geometry evaluation.
<JordanBrown>
Don't know, haven't looked at it.
<InPhase>
I mean, kind of makes sense in a half-baked manner. I'm sure there are a few dozen complexities that are missed.
<JordanBrown>
Absolutely.
<JordanBrown>
But the math (in a boolean geometry algebra sense) makes sense, and that's a big first step.
<JordanBrown>
The previewer isn't happy because it doesn't like invisible colored cubes that coincide with real cubes.
<JordanBrown>
So although red(A) + blue(B) should be red(A-B) + blue(B), but the shapes that go into making A, that get differenced away, are still there for the previewer's processing and give it indigestion.
<JordanBrown>
(give or take bad wording from changing how I was going to say it in the middle, and not fixing the beginning...)
<JordanBrown>
Dinner time. Later.
califax has quit [Remote host closed the connection]
califax has joined #openscad
LordOfBikes has quit [Ping timeout: 276 seconds]
LordOfBikes has joined #openscad
J1A8479 has joined #openscad
J1A84 has quit [Ping timeout: 252 seconds]
<JordanBrown>
Hah, the 2D previewer avoids Z-fighting on the horizontal surfaces by making the negative objects 1.1 tall instead of 1.0 tall.
<J1A84>
JordanBrown I had the idea it could do that - maybe a reason why scale can scale Z of an 2D object
aiyion1 has quit [Read error: Connection reset by peer]
califax has quit [Read error: Connection reset by peer]
teepee has quit [Read error: Connection reset by peer]
aiyion1 has joined #openscad
califax has joined #openscad
teepee has joined #openscad
TheAssassin has quit [Remote host closed the connection]
ccox_ has quit [*.net *.split]
lostapathy has quit [*.net *.split]
rue_mohr has quit [*.net *.split]
tcurdt has quit [*.net *.split]
redlizard has quit [*.net *.split]
redlizard has joined #openscad
rue_mohr has joined #openscad
TheAssassin has joined #openscad
lostapathy has joined #openscad
ccox has joined #openscad
tcurdt has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
Wolf480pl has quit [*.net *.split]
phryk has quit [*.net *.split]
TheCoffeMaker has quit [*.net *.split]
muesli has quit [*.net *.split]
muesli has joined #openscad
Wolf480pl has joined #openscad
phryk has joined #openscad
TheCoffeMaker has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
ran has quit [Remote host closed the connection]
teepee has quit [Remote host closed the connection]
lastrodamo has joined #openscad
teepee has joined #openscad
ur5us has joined #openscad
Colere has quit [Ping timeout: 252 seconds]
Colere has joined #openscad
Furor has joined #openscad
Colere has quit [Ping timeout: 268 seconds]
Furor is now known as Colere
KimK has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
Alexer has quit [Ping timeout: 264 seconds]
teepee has quit [Write error: Connection reset by peer]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
Guest75 has joined #openscad
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
Guest75 has quit [Quit: Client closed]
GNUmoon2 has quit [Ping timeout: 268 seconds]
TheAssassin has quit [Quit: No Ping reply in 180 seconds.]
TheAssassin has joined #openscad
GNUmoon2 has joined #openscad
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
p3ck has joined #openscad
p3ck has quit [Ping timeout: 240 seconds]
snaked has quit [Ping timeout: 245 seconds]
p3ck has joined #openscad
Alexer has joined #openscad
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
<Friithian>
hm, openscad segfaults when I quit it
<teepee>
sounds likke quitting is not supported ;-)
<Friithian>
well it closes perfectly fine so :P
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
<InPhase>
Friithian: Windows?
<InPhase>
Friithian: There was a Windows-only issue for that up there on the list.
<Friithian>
linux
<Friithian>
kde neon, ubuntu 20.04 based
<InPhase>
A nightly or master branch build? Or back at release?
<Friithian>
whatever ubuntu 20.04 packages
<Friithian>
2019.05
<InPhase>
Oh, that's not even latest release.
<Friithian>
it's ubuntu lts whattya expect :P
<InPhase>
I think there might have been a crash back then under some circumstances.
<InPhase>
But fixed so long ago it has been long since forgotten. :)
<InPhase>
22.04 is solid enough to upgrade to.
<Friithian>
kde neon won't rebase to 22.04 until after the point release
<InPhase>
But also for OpenSCAD it's worth grabbing a new release or even a nightly build. The AppImage versions work really well.
<Friithian>
imma just build from source
<InPhase>
I keep my /usr/local/bin/openscad symlinked to the release AppImages as soon as we bump them out. Then I use a separate command to open the master branch version I regularly build.
<InPhase>
I don't even install the repository versions anymore for openscad.
<Friithian>
on my desktop I have an r9 5900x so I just build stuff
<InPhase>
Although I can confirm that 22.04 carries 2021.01
<InPhase>
I need to keep both around to track regressions in behavior, but the current master branch has some really important improvements that make it worthwhile. fast-csg is an extremely important speed boost, for example. We also had a number of other major boosts.
ur5us has quit [Ping timeout: 240 seconds]
trashbird has quit [Ping timeout: 252 seconds]
trashbird has joined #openscad
snaked has joined #openscad
trashbird has quit [Ping timeout: 240 seconds]
trashbird has joined #openscad
fling has quit [Ping timeout: 268 seconds]
<JordanBrown>
J1A84: The previewer turns 2D objects into 3D objects, and then the transform happens in the underlying OpenGL.
<J1A84>
so a square is 2D that gets 3D and for extrusion (and maybe offset) 2D again to end in 3D ? .. sounds like a lot extra steps
<JordanBrown>
I'm sorry, I don't follow that.
fling has joined #openscad
<J1A84>
i just wonder if multiple offset cause multiple translations from 3D to 2D and back to 3D
<JordanBrown>
A square is a 2D object, until it gets to the previewer. Inside the previewer, it gets inflated into a 3D object,and some of the previewer operations need that because they only work on 3D objects.
<JordanBrown>
No, for linear extrude, offset, et cetera the square is still a 2D object. It only gets inflated if it makes it to the previewer.
<J1A84>
ah ok
<JordanBrown>
... which is why I was surprised that the inflated square scaled in Z; I would have expected that all of the transforms happened before the inflation.
<J1A84>
explains why z translations are removed when you put an offset
<J1A84>
so scale works after the priviewer?
<JordanBrown>
right - through mechanisms that I haven't yet looked at, some or all of the operations that consume 2D objects flatten them back out again before processing.
<JordanBrown>
After, or in, depending on your point of view.
<JordanBrown>
The previewer does its work by calling OpenGL, and the transforms (including scale) appear to be done there.
<JordanBrown>
(Or at least that's how I understand it now. I am far far far from an expert on this area of OpenSCAD's internals.)
<J1A84>
so aslong we hale nothing that can do boolean operation on 2D there is not much that can be done
<J1A84>
have nothing
<JordanBrown>
We *do* have that processing available. linear extrude and presumably other 2D consumers do it. It just doesn't get done if the 2D object makes it all the way to the previewer.
<J1A84>
so why is difference using 3D objects then
<J1A84>
(for the preview)
<JordanBrown>
difference is *not* one of the things that fully evaluates its 2D children. Rather, it just passes them through (like it passes through 3D children), and the previewer does the actual differencing.
<JordanBrown>
And the previewer's differencing only works on 3D objects.
<JordanBrown>
Similarly for intersection.
<J1A84>
hmm also in 2D objects there shouldn't be any z-fighting
<JordanBrown>
One would hope, but because the 2D objects get inflated into 3D for preview, all of the same Z-fighting issues apply.
<JordanBrown>
The only thing that hides a lot of them is the fact that the previewer makes the negative object be 1.1 tall, where the positive object is 1.0 tall.
<JordanBrown>
But if you scale a 2D object, that scales the inflated-to-3D representation of it and louses up that relationship.
<J1A84>
should use 100× Ü
<JordanBrown>
We really need some more terminology, because we have OpenSCAD 2D objects (squares) that get inflated in the previewer to 1-unit-thick 3D object, and we have OpenSCAD 3D objects (coplanar incomplete polyhedra) that are geometrically 2D.
<J1A84>
you even could have 1D objects
<JordanBrown>
OpenSCAD doesn't have 1D objects, though it would be useful if it did.
<JordanBrown>
Not for 3D printing, but for laser cutting.
<J1A84>
you can make them with polyhedra
<JordanBrown>
Well, yeah, kind of, with degenerate faces.
<JordanBrown>
It would be good to have line segments and polylines as first-class citizens.
<J1A84>
works if using 1D with hull to construct 3D objects
<JordanBrown>
yes, kind of, sort of.
<JordanBrown>
(Note: if you're doing that, you're probably working with a point cloud, and points are zero-D.)
<J1A84>
but even more a point would be nice to have .. but that is not possible with a polyhedra
<JordanBrown>
You could build a polyhedra with a single degenerate face, all three vertexes in the same place. But that would be a hack.
<JordanBrown>
And yes, first-class support for points would be good.
<JordanBrown>
But, sorry, right now I need to pretend to do real work, and get some lunch.