<kintel>
Does anyone have a good sense of how much the lazy union feature is being used?
<kintel>
I'm working through some rendering refactoring, and the lazy union stuff isn't particularly well designed, and it's pretty hard to keep it alive and clean up code at the same time..
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
peepsalot ping for thoughts ^
<InPhase>
Does it maybe lose some of its utility with Manifold being the future?
<InPhase>
Or is there still a useful role for it?
J24k has quit [Quit: Client closed]
J24k has joined #openscad
kintel has joined #openscad
<kintel>
It might be useful eventually, just requires better design IMO
<kintel>
Challenge being that, instead of a single top-level geometry, it has the potential for creating geometry trees, potentially containing different types of geometries depending on caching situation
<kintel>
The renderer infrastructure doesn't like this : /
<JordanBrown1>
There have been people who thought that lazy union was the path to multi-color / multi-material, but I don't buy it.
<JordanBrown1>
If you're willing to keep the individual volumes for MC/MM disjoint then you don't really need LU; just run the program N times and generate N subsets.
<kintel>
Heh, the reason for my refactoring is to explore multi-color through per-face materials in PolySets, inspired by guso78
<JordanBrown1>
And LU doesn't solve the problem even so, because it has no way to label the various volumes.
<JordanBrown1>
And if you're not willing to keep the individual volumes disjoint, it's no darned good to emit overlapping volumes like LU would.
<kintel>
but my exploration doesn't yet address volumetric materials, as we'd need CSG engine support for that, or some sort of fancy postprocessing
<JordanBrown1>
Mathematically I think I understand how MC/MM would work, but as it involves subtracting volumes with coincident faces I'm not confident that it'll really work.
<JordanBrown1>
And it doesn't work for preview because of those coincident faces.
<kintel>
You mean, by allowing users to decide which material "wins" for unions and intersections?
<JordanBrown1>
yes
<JordanBrown1>
or, rather, by defining rules for which material wins.
<JordanBrown1>
for intersections I decided that it was fair to say that the first object won, because the rest are just saying what to cut away.
<kintel>
Right, I also think there may be two dominant use-cases: MC vs. MM, where MC is more of a "surface color" use-case and MM really cares about the material all the way
<JordanBrown1>
For unions I can never quite decide between first-wins and last-wins. I kind of like first-wins, but last-wins is what a paint program does.
<JordanBrown1>
In the 3DP world I think it's always volumetric, unless you're just painting color on for display.
<kintel>
right, depends on your use-case: Is the material functional or visual?
<JordanBrown1>
But yes, face coloring (or texturing!) is a different case from volumetric.
<JordanBrown1>
I don't see how face coloring would really work in 3DP.
<JordanBrown1>
You could (and I do) apply a thin "paint" object to make it display the right color, when I'm going to apply actual paint to the final object.
<kintel>
Someone talked about the surface painting feature in Slicer
<JordanBrown1>
But if I was going to be printing it as multiple parts or using a MC printer, I don't see how to avoid it being volumetric.
<JordanBrown1>
I don't know what surface painting would really be, since any one (or even two or three or four) layer will probably show a bit of the underlying color through.
<kintel>
I think that's exactly what Slicer does: extrudes a number of layers with the surface color, and the rest is infill
<JordanBrown1>
Yeah, maybe.
<kintel>
Anyway, that may be a bit of an esoteric feature :)
<JordanBrown1>
MC printers are affordable by mere mortals, so not really.
<JordanBrown1>
I keep thinking about getting a Prusa with their MC kit.
<kintel>
heh, as opposed to that powder-inkjet printer :)
<JordanBrown1>
Yeah.
<kintel>
Anyway, the stuff I'm exploring is currently about surface colors: Extend preview colors to render
<kintel>
..and possibly allow exporting to file formats which allow surface colors.
<JordanBrown1>
I was just watching a friend print stuff on a two-headed printer. He was printing two separate objects at the same time, but I assume it's also capable of printing a single object from multiple colors.
<kintel>
..potentially some of that becomes baby steps towards something else
califax has quit [Remote host closed the connection]
califax has joined #openscad
<JordanBrown1>
I think his was a Snapmaker J1S, which is "only" a thousand dollars.
califax has quit [Remote host closed the connection]
<JordanBrown1>
face painting is very interesting for building stuff for integration into video games and virtual worlds.
califax has joined #openscad
<JordanBrown1>
I played around with AltspaceVR, and found building things using Unity's editors to be incredibly painful.
<JordanBrown1>
I did manage to import an STL, but it came out gray.
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
<peeps[zen]>
manifold also makes the performance benefits of lazy union much less compelling. one case for lazy union which i feel is still useful, is that of 2d output for laser engraving.
<peeps[zen]>
where it might be desirable to have overlapping outlines, or e.g. >2 nested concentric circles
<peeps[zen]>
but that's still kind of an odd hack to make a solid modeller behave otherwise. maybe a nice replacement for LU would be to only affect the top level union. "No Implicit Top Level Union"
<peeps[zen]>
i don't know how much others rely on it, if at all. but I haven't really been using OpenSCAD in general very much lately, and haven't used a laser engraver in a long while either. so i wouldn't miss it much.
<InPhase>
Oh right, I remember the $children computability fiasco.
<peeps[zen]>
yeah if it wasn't gonna work on loops, then didn'
<peeps[zen]>
t seem all that useful
<InPhase>
And the future could look like modules and objects with geometry anyway, if we get around to that. And we can just try to get things sensibly consistent that way.
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
analoq has quit [Ping timeout: 264 seconds]
analoq has joined #openscad
fling_ has joined #openscad
fling has quit [Read error: Connection reset by peer]
fling_ is now known as fling
analoq has quit [Ping timeout: 255 seconds]
analoq has joined #openscad
bozo16 has quit [Ping timeout: 240 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
guso78k has quit [Quit: Client closed]
Guest78 has joined #openscad
Guest78 has quit [Client Quit]
splud has quit [Ping timeout: 255 seconds]
fling has quit [Remote host closed the connection]
fling has joined #openscad
splud has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
r2ro has joined #openscad
R2robot has quit [Ping timeout: 260 seconds]
r2ro is now known as R2robot
mmu_man has joined #openscad
snaked has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 260 seconds]
foul_owl has quit [Read error: Connection reset by peer]
mmu_man has joined #openscad
foul_owl has joined #openscad
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 246 seconds]
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #openscad
Dennis78 has joined #openscad
<Dennis78>
Hey guys. I am new to OpenSCAD and have a rendering related question - is that the right place? ;)
<ecraven>
no one knows until you ask ;)
<Dennis78>
Hehe lets give it a try :)
<Dennis78>
I have tried to develop a kind of spacer for a battery
<Dennis78>
but in "real" render mode (F6) the inner "bars" are missing
<Dennis78>
I don't understand why
<Dennis78>
also in the STL export they're missing
<ecraven>
do you have exactly-matching surfaces? for difference, you should make the thing you are subtracting just a bit larger
<Dennis78>
yes that's why I use the translate ([0,0,-5])
<ecraven>
ok, that should be enough, I mostly use 0.1 or so ;)
<Dennis78>
I gave it some more buffer :D But yeah, a minimum delta should be fine
<ecraven>
hm.. the union thing is 2d, but the second operand of the difference is 3d?
<ecraven>
I tend to not use extrusion, but directly use cylinder and cube for this kind of stuff
<Dennis78>
hm why is it 2d? It should be like 2 "walls" with a 90°, so it looks like an extruded "+"
<ecraven>
also, I get two warnings about this in openscad, do you also get them?
<ecraven>
well, you rotate/scale/translate squares.. squares are 2d, no height
<Dennis78>
hm maybe that's the problem. But in the preview it shows fine :D
teepee has quit [Quit: bye...]
<Dennis78>
I will try cube instead, thanks
TheAssassin has quit [Quit: No Ping reply in 180 seconds.]
<ecraven>
yes, but I think that's the problem. I'd to cylinders and cubes
teepee has joined #openscad
<ecraven>
however, I'm really a beginner at OpenSCAD, so ... ;)
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
<Dennis78>
It works with cube indeed :) But I thought if you extrude a square you also have a cube
J24k95 has quit [Quit: Client closed]
J24k95 has joined #openscad
<ecraven>
but you never extrude it
<ecraven>
if you do that, it should work fine ;)
<J24k95>
The advantage of extruding is that you can apply offsets to the 2D .. also you can center a square and extrude without center so it starts at z=0
<J24k95>
further you don't need to care about z epsilon in 2d for union or differences
<ecraven>
thanks, I've not yet come across these, that sounds like good reasons (but you still need to actually extrude afterwards)
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #openscad
Dennis78 has quit [Quit: Client closed]
<J24k95>
yes and you can rotate_extrude them for curved objects
<JordanBrown1>
Yeah, the 2D subsystem is kind of unfortunate in that it previews 2D objects as having a Z-height of 1.
<JordanBrown1>
square(1) *looks* the same as cube(1), but isn't the same.
<JordanBrown1>
The previewer can actually display zero-thickness objects - you can build them with polyhedron() - but it doesn't know how to do boolean operations on them.
<JordanBrown1>
We should arguably have the previewer fully evaluate 2D objects, in 2D, before displaying them. That would address the problem with boolean operations. It's what linear_extrude already has to do.
<JordanBrown1>
But it would lose color information, and that would be a problem for some applications.
JordanBrown1 has quit [Read error: Connection reset by peer]
JordanBrown has joined #openscad
a6-webm has joined #openscad
<a6-webm>
anyone want to look at my GSoC application before I send it off? (I'm honestly worried it's not worth submitting at this point lol)
<a6-webm>
well for better or worse, it's in
a6-webm has quit [Quit: Client closed]
<teepee>
hum, that's a bit short notice
<teepee>
deadline was 9 minutes after the message
<J24k95>
Ü
<J24k95>
some people just living on the edge
teepee_ has joined #openscad
mmu_man has quit [Ping timeout: 256 seconds]
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
mmu_man has joined #openscad
Guest77 has joined #openscad
<Guest77>
Hello I have a problem with OpenSCAD version 2023.12.15 (git 3d094bf87), it seems to be a bug. The following code works for me with $fn = 2000 in the rotate_extrude parts. It shows a ring with an inner slope. But if I change the second one to $fn=2800, then it renders a filled circle at the top
<JordanBrown>
Can't really look at it now, but $fn=2000 is a crazy large number.
<JordanBrown>
Even $fn=100 is usually well more than enough.
<Guest77>
100 is very low for such a big ring
<Guest77>
I forgot to say, it is on a mac
<teepee>
seems fine with the latest version, I'd suggest trying with that
<JordanBrown>
Again, not looking in detail, but your whole model looks like it's only a couple of hundred units across.
<JordanBrown>
But as I think about it a bit more, yeah, 100 might be small enough to be visible on a ring that's ~280 across.
<Guest77>
ok thanks, I will try the newest 2024.04.01 development snapshot
<Guest77>
yes exactly, I rendered it now with $fn=100 and it is very very low resolution, I need it much much smoother :-)
<JordanBrown>
But 2000 is less than half a millimeter per side.
<Guest77>
yes, that is a resolution that is ok for me, I do not want to see any artefacts on the model
<Guest77>
for me a half millimeter is low-resolution :-)
<JordanBrown>
On an arc? In plastic?
<J24k95>
Guest77 use $fs and $fa which will calculate the facets - also keep in mind the number of $fn is irrelevant the angle between two facets matter
<JordanBrown>
yeah, that's a different topic, that generally you should use $fn only to generate regular polygons.
<JordanBrown>
For circles, use $fa and $fs.
<JordanBrown>
I bet that with $fa=1 and $fs=0.5 you won't be able to see or feel the sides.
<Guest77>
I generate the OpenSCAD code from Smalltalk programming language, it is autogenerated code and I simply use the $fn which is easier for me
<JordanBrown>
OK, just be aware that it can cause stupid things to happen with small circles.
<JordanBrown>
The way you're doing it here, specifying on each individual call, isn't awful.
<JordanBrown>
Awful is when you set it globally and then are also messing with 3mm circles and end up with sides far below the resolution of 3d printers.
<JordanBrown>
Spheres are especially bad because the numbers get squared.
<Guest77>
Yeah I have just implemented a Context-object in smalltalk, which knows a "resolution" and this is a factor which is simply multiplied to all circular things and sets the $fn for each individual
<Guest77>
my code simply does internally "radius * resolution" for each circle or rotate_extrude, and this works fine for me so far, coz I can easily setup my context object with another resolution
<JordanBrown>
OK. It's not nearly as bad these days if you have Manifold turned on, but with CGAL it's easy to get into trouble even with a couple of hundred sides.
<Guest77>
The $fn globally is not really useful, it should depend on the radius of a shape
<JordanBrown>
Right, which is what $fa and $fs do.
<Guest77>
but I guess it does not work for rotate_extrude?
<JordanBrown>
Hmm? Sure, it works.
<J24k95>
it evaluate the outer edge
<Guest77>
I implemented in my context class simply a "rotateExtrudeAngle:radius" in Smalltalk syntax, where I has the extra "radius" parameter, so that I can also do "radius * resolution". That works fine for me and I simply tell with that way how big the outer part of the rotate_extrude is
J24k95 has quit [Quit: Client closed]
J24k95 has joined #openscad
<JordanBrown>
So I duplicate your problem. Preview is OK, render is bad.
<JordanBrown>
Manifold render, that is. CGAL render is taking its own sweet time.
<JordanBrown>
... and fails too.
<Guest77>
I use always the CGAL rendering, coz I need to do it anyway to save a .stl file and with the development snapshots the CGAL rendering is not so slow anymore
<JordanBrown>
F6 is either CGAL or Manifold depending on your preferences setting.
<JordanBrown>
Manifold is far faster.
<Guest77>
currently I try it with 2024.04.01 version, but it takes time
<JordanBrown>
Both of them can be used to create STL files.
<Guest77>
ahh ok, I did not know that :-)
<JordanBrown>
F5 preview cannot.
<JordanBrown>
and is far far faster than CGAL, and somewhat faster than Manifold.
<Guest77>
ok I can agree the 2024.04.01 has the same problem, I try to look now for the Manifold setting
<JordanBrown>
Edit/Preferences/Features
<JordanBrown>
But it's it's getting your failure for both CGAL and Manifold.
<JordanBrown>
It just takes a lot longer with CGAL.
<J24k95>
notice to myself .. don't slice space filling curves ..
<Guest77>
wow... it seems to work with manifold setting and it is very very fast, I just click to render and it is immediately ready :-) . why you did not tell me that a half year before... I do not accept any excuses that I was not here in chat :-) :-)
<J24k95>
"experimental"
<Guest77>
yeah it seems I get render artefacts with a big model with some differences, but I will look at that