<teepee>
changes breaking existing desings for this specific case are very unlikely to be acceptable
<bitbasher>
i bet you meant .. unacceptable?
<bitbasher>
oh .. neven mind ..
<bitbasher>
finally saw the "un"
<bitbasher>
my testing of the primitives in the last few weeks has revealed abuses of the center parameter .. sometime default is false, sometimes, true .. sometimes it is horizontal centering, others centering vertically on z=0 .. i would like to see consistency is all .. and to me worth suffering through a big change
<teepee>
that's what python3 said too
<teepee>
the "inconsistency" is due to different primitives just being different
<bitbasher>
LOL too true .. but .. my proposal does leave the "center" param as is .. i want to add centerxy and centerz so existing scripts should keep working
<teepee>
I have *never* needed a sphere aligned like the default cube
<teepee>
well, the page said "change to" centerxy
<bitbasher>
ah ... oopsie
<teepee>
anyway, I'm not sure all that looking at the center parameter is even useful
<bitbasher>
well i had better fix that before other sleepless people read it
<teepee>
there's at least more options, like having a separate center() module
<teepee>
or using the idea of using named handles
<bitbasher>
there has been a lot of attention paid to the more complicated ideas in the different issues
<teepee>
which the original idea is to use those to attach stuff, they could also be used for aligning things maybe
<bitbasher>
adding a couple of params would be little work compared to doing new modules etc
<teepee>
that is NOT a reasonable goal
<teepee>
we are not code golfing
<teepee>
I'd like to use openscad in a couple of years still
<bitbasher>
well i would like to see align( x="center", y= etc ) as an operator module that would operated on all of its children
<teepee>
so just tossing any idea over eachother is just going to mess things up
<teepee>
yes, something like that
<bitbasher>
code golfing .. a new term to me
<teepee>
not sure it actually is all that much more complicated to implement
<teepee>
oh, it even has a website - https://code.golf/ - which does hurt my eyes upon opening it :/
califax has quit [Remote host closed the connection]
<bitbasher>
what ! The F? is that - yeah, code golf site causes pain .. but i am going to have to look
califax has joined #openscad
<bitbasher>
okay .. i fixed my suggestion .. now off to bed
sculptor has quit [Read error: Connection reset by peer]
sculptor has joined #openscad
sculptor has joined #openscad
sculptor has quit [Changing host]
bitbasher has joined #openscad
<JordanBrown>
teepee WRT tags I think there's a significant difference between "we need to fix our deficiency" and "we should work around another tool's deficiency".
<JordanBrown>
teepee bitbasher historically one of the key problems with a generalized center/align operator is that there is no way to know the geometry of a child without rendering it, and rendering was slow and lost color information. Manifold changes both of those, but my impression is that preview is still noticeably faster.
<teepee>
meaning of the tag yes
<teepee>
practical implication which one it attached: probably nothing
<JordanBrown>
Indeed.
<teepee>
I'll add a tesselate call, this should already fix the issue
<JordanBrown>
It matters if there's a finger-pointing exchange :-)
<teepee>
true, but those are only actually critical in companies
<teepee>
here even that is just opinions
<JordanBrown>
My personal "justified" modules use an xyz vec3 with -1 for positioning left of the axis, 0 for centering, and +1 for positioning right of the axis.
<JordanBrown>
I have been very happy with that for cubes.
<teepee>
I'm still not clear how handles would work in the language
<teepee>
like imagine a cube with 9 handles for a start
<JordanBrown>
What do you mean by handles? Do you mean like BOSL2 anchors?
<teepee>
sort-of yes
<JordanBrown>
But... I started to extend it to circular objects, and I ran into a fundamental question about justifying circular objects: they aren't circular, and sometimes that matters.
<teepee>
like a cube would have some magic handles, lets say as string CENTER, TOP_LEFT_FRONT,...
<JordanBrown>
Like BOSL2 anchors.
<teepee>
now it would be possible to both "center" on that or attach things in that position
<teepee>
like guso has implemented for the python stuff
<JordanBrown>
Sounds exactly like what they did in BOSL2.
<teepee>
the center() module would default to origin, I guess, but could take a position
<teepee>
center([10, 3, 5]) cube(5);
<teepee>
so now how to bring the handle in there
<JordanBrown>
What would that center() invocation mean?
<teepee>
center([0, 0, 0], "CENTER") cube(10);
<teepee>
that would use the CENTER handle of the cube and move the cube so that is at 0, 0, 0
<JordanBrown>
what does the [0,0,0] mean there?
<teepee>
that would be like center=true
<teepee>
hmm, probably swapping the arguments...
<JordanBrown>
That doesn't seem necessary. Everything is relative to the origin; if you want it relative to something else you wrap a translate around it.
<teepee>
that would position the cube with it's top-left-front corner placed at [10, 3, 5]
<JordanBrown>
So that would put the top left front at [10,3,5]?
<JordanBrown>
Yeah, I would oppose including that parameter.
<teepee>
center("TOP_LEFT_FRONT") cube(5);
<teepee>
woudl put the top-left-front corner at the origin
<JordanBrown>
I don't see a need for more than that.
<JordanBrown>
Just as we don't have cube(size, position).
<teepee>
well, the point would be that you can define those handles also for self made objects
<teepee>
so you can have handles where the screw holes are for example
<JordanBrown>
The handle part, sure, give or take the representation. It's the "and then position it <here>" that I object to.
<teepee>
ah, right
<teepee>
yeah, true, an additional translate is fine and easy to combine in user space
<JordanBrown>
When you have a circle, and you want to put it into the first quadrant (+XY) against the axes, do you position the mathematical circle (and perhaps leave gaps between it and the axes) or do you align the edges to the axes (and have the mathematical circle extend on the wrong side)?
<teepee>
the handle does not necessarily have a vertex in the geometry
<JordanBrown>
Handles could help there, in that there could be distinct handles for the mathematical circle and the actual line segments.
<teepee>
first go, I'd say mathematical only, others maybe later if needed
<JordanBrown>
Or we could introduce a regular-polygon module, which would be pretty much the same as circle() except for alignment behavior.
<JordanBrown>
I don't remember if I've ever wanted to align a circle other than centered. I have certainly wanted to align regular polygons on their edges.
<JordanBrown>
It would be tempting to add a polymorphic variation on polygon: polygon(sides, size)
<JordanBrown>
(though then you still need to know whether "size" radius-like or diameter-like, and whether it's to the vertexes or to the edges.
<JordanBrown>
But to be clear, the parenthesis in a smiley is not a parenthesis for these purposes. (Unless it is :-)
<JordanBrown>
Going back to handles...
<JordanBrown>
Strings are an obvious representation, but aren't so good for constructing values.
<teepee>
the value is probably a transformation matrix
<teepee>
that's what guso used
<JordanBrown>
Sure, but how does the caller refer to it?
<teepee>
I guess the minimum is a vertex + a direction
<JordanBrown>
I've not infrequently constructed my justification triplet when building objects with symmetry.
<teepee>
I guess it could be a name for the legacy case built-ins
<teepee>
for self-made it would be just a variable reference of an object
<JordanBrown>
Hmm. Not without geometry values.
<teepee>
well, actually any variable with a matrix (or whatever we declare to be a handle) would be ok
<teepee>
object + geometry values would be hugely convenient though
<JordanBrown>
Yes.
<JordanBrown>
I have a demo that I wrote a few years ago that I considered rewriting to avoid those features (because it's kind of fun regardless), and I realized that there really was no good way to do what it did without either geometry values or module references.
<JordanBrown>
and you define a train like so: [ steamLoco("darkgray"), boxcar("lightgreen"), tanker("silver"), boxcar("blue"), caboose("red")]
<JordanBrown>
There's no good way to dynamically assemble a list of geometric objects like that.
<JordanBrown>
Those functions each return an object containing a shape and metadata (notably length) about the shape.
<JordanBrown>
actually, the only metadata is the length.
<teepee>
hmm, with the OBJ example, I have no issue slicing that in PrusaSlicer
<teepee>
ahem, oops, yes OBJ would be the key :-)
<teepee>
(smiley not a closing brace!)
<JordanBrown>
and you define a track like so: [ straight(30), curve(30,90), switch(s1, function() track2), curve(30,90), straight(120), link(function() track3) ]
<JordanBrown>
where each track segment is an object containing a shape, translation and rotation for the other end of the segment, the length along the segment, and a function that for a given distance along the segment returns the rotation and angle.
<JordanBrown>
But going back to handles.
<JordanBrown>
One might think that a general shape creation could return an object with a shape and a list of handles.
<JordanBrown>
But since it doesn't know which of the handles the caller wants, it would have to list all of them.
<JordanBrown>
for a cube, that's 27.
<JordanBrown>
Given $this, it could return a function that accepts a handle designator and returns a transformation matrix.
<JordanBrown>
so that it would dynamically create the one-and-only transformation matrix that the caller wants.
<JordanBrown>
BOSL2 does it using the child relationship.
<JordanBrown>
No, that's not right. It's more complex than that.
<JordanBrown>
You can tell an object to position itself relative to one of its anchors.
<JordanBrown>
but when you want to position a child relative to a parent's anchor, I'm pretty sure the parent has to pass down a full list of its anchors. (But maybe it just passes down a function reference. I should ask/check.)
<teepee>
hmm, it could transform that if it's matrices
<teepee>
but that might be something for v2
<JordanBrown>
If it's just one parent and one child, you could tell the parent "position the child at <this> anchor".
<JordanBrown>
But a parent can have multiple children.
<JordanBrown>
You could have a parallel array of anchors, one for each child, but ... yuck.
<gbruno>
[github] t-paul pushed 1 modifications (Tesselate PolySet before exporting as OBJ (closes #5993). OBJ does support faces with more than 3 vertices but some applications, e.g. PrusaSlicer currently do not support that. So for now we just force a tesselation to triangles before exporting to OBJ.) https://github.com/openscad/openscad/commit/995f07973a0dbfb4cf85d67ce2d3e759bec2d2d6
<gbruno>
[github] t-paul pushed 3 modifications (Tesselate PolySet before exporting as OBJ (closes #5993). OBJ does support faces with more than 3 vertices but some applications, e.g. PrusaSlicer currently do not support that. So for now we just force a tesselation to triangles before exporting to OBJ.) https://github.com/openscad/openscad/commit/6c7c4b1114bf2e5e1f69b3463579fdac16ce89d1
califax has quit [Remote host closed the connection]
califax has joined #openscad
guso78k has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
<JordanBrown>
teepee if you likes pkriens' template-based solution to the ContextMemoryManager polymorphism question better than my subclass-based scheme, it's probably appropriate to close my PR.
<JordanBrown>
s/likes/liked/
califax has joined #openscad
guso78k72 has joined #openscad
<guso78k>
wondering, if there is a function similar to tessellatePolygonWithHoles which also transfers colod information from input to output ?
<guso78k>
is there a chance to reuse the existing function an dstill getting colored output triangles ?
<teepee>
JordanBrown: I have not looked at that yet, I might after getting something to eat (have to check when to get up tomorrow morning)
sculptor_ has joined #openscad
<teepee>
guso78k: no idea, that may need Marius to answer
sculptor has quit [Ping timeout: 240 seconds]
sculptor__ has joined #openscad
sculptor has joined #openscad
sculptor_ has quit [Ping timeout: 276 seconds]
sculptor__ has quit [Ping timeout: 260 seconds]
sculptor_ has joined #openscad
sculptor has quit [Ping timeout: 260 seconds]
<teepee>
JordanBrown: oh, so #6029 and #6023 were targeting the same topic, I missed that. I did not look at #6023 as the CI was red
<bitbasher>
thanks t-paul .. having proper triangles in an OBJ files will solve some problems
<bitbasher>
even back in the day Wavefront's software was way ahead on modeling with polys with any number of edges .. but not many other apps could handle the threat of non-planar shapes .. most of the downstream apps .. at the time that was really only CNC machines .. but exporting to Z-Paint and 3-rd party rendering platforms required a lot of massaging of an obj file to work well
<bitbasher>
when is the nightly build .. is t-pauls PR #6035 already built? i could wait till tomorrow .. sigh
<teepee>
no, I have 2 PRs colliding in master branch
<InPhase>
bitbasher: FYI, one of your github comments implied you found 4 vertex elements in an STL. STLs are all triangles though. Maybe you mistyped that, but pointing that out in case you actually led yourself astray on something. :)
<InPhase>
The file format is hard-locked to triangles.
<teepee>
yeah, not uncommon even for the newer formats, like AMF, 3MF
<teepee>
well, "newer" with AMF already dead again :)
<teepee>
bitbasher: just in case that was not clear from earlier talk... t-paul is me on github
* teepee
crosses fingers the PR goes through now
<bitbasher>
InPhase .. indeed .. that is a "my bad" .. i dont rem my text but the use of export STL is the workaround to the prob
<bitbasher>
ah .. t-paul == teepee is clear .. but only in hindsight with the hint given . thx
<bitbasher>
would it be better to start a discussion page on the wiki for these bigger issues of what do to about features? details get lost in chats like IRC no?
califax has quit [Remote host closed the connection]
<teepee>
for actually discussion, I have no idea how that will work
<InPhase>
bitbasher: We have no cultural convention of discussing on the wiki, so I suspect that would be where conversations go to die. :)
<InPhase>
bitbasher: But there have been important wiki pages made summarizing the current state of thought on complex topics. But usually they just live as snapshots of a point in time.
howiemnt has quit [Remote host closed the connection]
howiemnt has joined #openscad
stealth_ has joined #openscad
<stealth_>
how to go about placing 3 object in equilateral triangle
<stealth_>
o nm
<teepee>
for (a = [0:2]) rotate(a*120) translate()
<bitbasher>
translate the object a distance off origin and prefix with a rotate
<stealth_>
ya, cube(1).translate([0, 1, 0]).rotate([0, 0, i*120]), not sure why i was overthinking it, lol
<stealth_>
it took longer to do the same in inkscape figure it was complicated in openscad as well.
<bitbasher>
okay .. scad WoW is chat about stuff till someone is motivated to write a summary page or an enhancement issue in Git HUb .. that can work too
<bitbasher>
WoW == Way of Work BTW
<bitbasher>
BTW == the TLA for By The Way
<teepee>
if the motivation is not enough for writing things down, it's even more unlikely to be implemented anyway I guess
<bitbasher>
you know what comes next right .. yep .. a sound beating if i fail to run away fast enuf
<teepee>
it's not like there are hundreds of ideas
<teepee>
looks like the builds are back to green
califax_ has joined #openscad
<bitbasher>
there are 883 open issues .. i can't get github to tell me how many are enhancements
<teepee>
so good chance a new build will appear on the download page
<bitbasher>
yeah .. i can export OBJ to Prusa then
califax has quit [Ping timeout: 244 seconds]
<bitbasher>
release page on GitHub or downloads on website?
<teepee>
rough estimation: click on the "type: enhancement" label
califax_ is now known as califax
<teepee>
there is no github nightly build download
<bitbasher>
yeah .. that works .. unexpected but okay .. why can't i enter type:enhancement in the filter field? only type:bug etc
<teepee>
because it's a label, so I guess it's label:"Type: Enhancement" or so
<bitbasher>
ick ick .. thx
<bitbasher>
last dev snap on download page is 2025.07.11 still .. i will be patient
<teepee>
because the download only runs once a day
<teepee>
I think that's 6:00 UTC
<bitbasher>
ah .. for me that is 6.5 hours from now
<bitbasher>
no worries
<teepee>
indeed, that's in 6.5 hours for everyone on earth ;-)
<teepee>
just not the same local clock time showing :P
<teepee>
for me that's 8:00 which means I'll be still sleeping
<teepee>
but the automation is running pretty much without issues for years now
<bitbasher>
I am in CET .. Belgium .. so as of now it drops in 6 hr 15 min .. but i need to sleep so .
<bitbasher>
or .. do people prefer to have the full, long, indented TOC list the existing page .. i can go either way .. but the long TOC will be more work to rationalize and tidy so i lean to Plan A