<teepee>
hmm, sounds like disabling the check for now and getting things automated might be a good step forward
<teepee>
giving protection against the stuff already down so it does not regress
<teepee>
s/down/done/
teepee_ has joined #openscad
epony has quit [Ping timeout: 268 seconds]
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
qeed has quit [Quit: qeed]
aiyion2 is now known as aiyion
epony has joined #openscad
<kintel>
peepsalot: In those cases, perhaps an improvement would be to rewrite the code to dynamic_cast first, instead of checking the typeid?
<peepsalot>
teepee: what would you recommend in terms of CI? I could add another entry to the github actions linux/Ubuntu matrix?
<peepsalot>
the CircleCI builds are also pretty fast, not sure if that's just a consequence of MXE for some reason
<peepsalot>
the checks can take quite a bit resources. i hit swap on 32GB ram if I run max 24 threads of this computer. so, say... maybe 1.5GB needed per thread
<kintel>
I believe GitHub allows for integrating this so it can actually generate a review with suggested changes which can be applied directly in the UI.
<peepsalot>
kintel: regarding dynamic_cast, i guess I'm working under the assumption that comparing typeid is faster than trial and error of many dynamic_casts. though I don't know for sure if that's actually true
<kintel>
well, we do trial and error on many typeid checks, so I expect it to be equivalent :)
<peepsalot>
which i suppose only matters in performance critical sections, where I think Expression.cc would be the only one that qualifies
<peepsalot>
because that is tail recursion code iirc
<kintel>
actually, today's implementation is likely faster as there is only a single dynamic typeid()
<kintel>
As long as nobody tries to subtype e.g. Echo and expect it to work that's fine
<peepsalot>
well, i'm headed to a local robot group meetup for a bit, be back later tonight
<JordanBrown[m]>
It seems mildly wrong that { for (i=[1,2]) !cube(i); } is legal, but { !cube(1); !cube(2); } isn't. I get that you can only appoint one pseudo-root node, but there are two nodes appointed in both cases.
<sinned6915>
i need help with order of operations-
<sinned6915>
yes, i am not understanding which comes first
<JordanBrown[m]>
Work your way from the inside out.
<JordanBrown[m]>
you want to swap the translate and the rotate.
<teepee>
sinned6915: you can also have a look at File->Examples->Advanced->children
<teepee>
this has a make_ring_of()
<JordanBrown[m]>
In a more conventional language, what you have said is sort of akin to translate(rotate(cube)), where what you want is rotate(translate(cube))
<JordanBrown[m]>
teepee yeah, but let's get past the fundamentals...
<teepee>
yep, nothing wrong with that
<JordanBrown[m]>
sinned6915: does that make sense?
<sinned6915>
i am trying to 'read' it like openscad would be reading it
<teepee>
then imagine the operations you give are a tree
<JordanBrown[m]>
translate(...) rotate(...) cube(...) reads like "translate a rotated cube".
<sinned6915>
rotate(translate(cube)) makes sense
<teepee>
cube() is the leaf and operations are working upwards
<JordanBrown[m]>
and that's rotate(...) translate(...) cube(...), which reads as "rotate a translated cube".
<sinned6915>
ok
<JordanBrown[m]>
and remember that all rotations are around the origin, so rotating a translated cube moves it around a circle.
<sinned6915>
right
<JordanBrown[m]>
it looks like you're now getting what you wanted, more or less.
<sinned6915>
i am still fumbling, but yes
<sinned6915>
so how do the individual axis array variables ger read?
<JordanBrown[m]>
It seems like you have a +1/-1 problem with the number of cubes; I would have expected n=5 to produce 5 cubes, but since you're counting 0,1,2,3,4,5 you get six.
<sinned6915>
([x,y,z])
<JordanBrown[m]>
I don't quite understand what you mean by "how do they get read".
<sinned6915>
5 vs 6 has to do with the angles and 360
<sinned6915>
right now i am only dealing with 1 varible change, the radius
<JordanBrown[m]>
a translate moves the origin of the child object to the specified point.
<sinned6915>
if i wanted the cube to be 45 degree inclined in X and Y
<JordanBrown[m]>
a rotate rotates the child object by the specified amount, first around the X axis, then the Y axis, then the Z axis.
<sinned6915>
i should probalby do at center, not face
<JordanBrown[m]>
indeed, rotating a centered cube is more obvious than rotating a not-centered cube.
<JordanBrown[m]>
multi-axis rotates can be difficult to visualize.
<sinned6915>
teepee: i think i am going to stick with this for now
<sinned6915>
the child thing confuses me right now
<sinned6915>
i blame inPhase :p
<JordanBrown[m]>
this is a cube rotated 45 degrees in X
<JordanBrown[m]>
You can achieve any rotation with a single [x,y,z] triple, but it is not always obvious what that triple is.
<sinned6915>
yes, exactly that!
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JordanBrown[m]>
That is, if the easiest way to think of what you want to do is a rotation in Z, then a rotation in Y, it may be better to say rotate([0,ry,0]) rotate([0,0,rz]) myobject(); than to try to figure out the single rotate equivalent.
<sinned6915>
where i am going with this is the screwhole function of inPhase's thread libary
<InPhase>
sinned6915: The idea of that module is you're supposed to pass the rotation and position of the hole in as parameters.
<InPhase>
sinned6915: Oh, I see the thing. You wanted to loop it, but we don't have objects.
<InPhase>
sinned6915: I think that was actually supported when I wrote the library, but peepsalot broke it when he fixed the processing of difference with empty children. (Although in peepsalot's defense I endorsed the change, because the old way of handling empty children was conceptually broken.)
<InPhase>
The right way is for us to have objects to solve this issue, rather than this overreliance on syntactic children.
J23165 has joined #openscad
J231 has quit [Ping timeout: 260 seconds]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
othx has quit [Ping timeout: 272 seconds]
othx has joined #openscad
kintel has joined #openscad
kintel has quit [Client Quit]
<sinned6915>
InPhase: ok, so I did remember it right! I see the change now
<sinned6915>
btw: what is the 'safest' dev release? I am on 2022.5.15. I am thinking i might want to see if there is something more stable
<JordanBrown[m]>
I don't think anybody keeps track of stability of the dev snapshots.
<JordanBrown[m]>
They are not, after all, intended to be supported in the long term.
<sinned6915>
yes, agreed.
<sinned6915>
but some are 'better' than others
<JordanBrown[m]>
I think they are all decently stable.
<JordanBrown[m]>
I'm sure some are better than others. But I don't think anybody tries to figure out which those are.
<JordanBrown[m]>
But are you using any of the unreleased features? If not, you might want to stay with 2021.01.
<InPhase>
sinned6915: I just stick with latest. Any bugs recently added that we're aware of are among the easiest things to fix.
<sinned6915>
so everything between the braces will refer back to the for-i loop
<JordanBrown[m]>
yep
<JordanBrown[m]>
I wouldn't say "refer back to". The stuff in the braces are the children of the for loop.
<JordanBrown[m]>
Same for if(), union(), translate(), ... anything.
<JordanBrown[m]>
The two forms for a for loop are
<JordanBrown[m]>
for (...) one_statement;
<JordanBrown[m]>
for (...) {
<JordanBrown[m]>
... zero or more statements ...
<JordanBrown[m]>
}
<sinned6915>
ok
<sinned6915>
renders are taking forever
lostapathy has quit [Ping timeout: 264 seconds]
<JordanBrown[m]>
$fn=196 is a very large number.
<sinned6915>
i backed it of to 128
<sinned6915>
then 96
<sinned6915>
still forever
<JordanBrown[m]>
I would not normally use $fn at all; instead, I would set $fa=1 and $fs=0.5.
<JordanBrown[m]>
Without looking in detail, I suspect that you are asking it to make screw-hole-sized objects with 96 sides.
<JordanBrown[m]>
So you have an object with a circumference of, what, maybe 10mm divided into 96 sections 0.1mm each.
<JordanBrown[m]>
That's probably at the mechanical resolution of your printer, and significantly smaller than the accuracy that you can actually get out of the plastic.
lostapathy has joined #openscad
L29Ah has joined #openscad
TheAssassin has quit [Ping timeout: 255 seconds]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
ActionDave has quit [Remote host closed the connection]
<J23165>
if someone told me 5yr ago you can do this with openSCAD at least i wouldn't know how
califax has quit [Remote host closed the connection]
califax has joined #openscad
<buZz>
nice, how many hull() ?
tachoknight has joined #openscad
<J23165>
no hulls were harmed for this
<J23165>
the fillets around are probably still hull chains
<buZz>
did you post the code?
<buZz>
s/did/could/
<buZz>
:)
<InPhase>
That model is a challenging topology category to do smoothly. I see residuals of the iterative geometric pieces that made it work, but it is relatively quite seamless for that sort of solution.
<InPhase>
However, beautiful as it might be, that has got to be one of the world's worst teapot designs ever.
<J23165>
maybe these are also the reason why roof with offsets get problems .. because the offset is creating bad geometry
J23165 is now known as J23
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
KimK has quit [Ping timeout: 252 seconds]
KimK has joined #openscad
tachoknight has joined #openscad
<InPhase>
J23: I've never seen offset do something like in that 3MX url. Do you have a small testcase that does this?
<J23>
to round something you have 4 offset operations .. and i use 2 sets with different radii .. if i remove one set the error is gone, also when selecting different values for the radii..
<J23>
it seems the order of the ir and or offsets changes the issue .. so ir first or second doesn't produce the error (at least in this example)
Sauvin has quit [Quit: Leaving]
Sauvin has joined #openscad
<J23>
error can be seen at [ 5.26, 17.15, 0.00 ]
<J23>
https://imgur.com/a/JsGoAXd it assume some floatingpoint rounding causes this so the points are not aligned and then following operation causing the gap
<Kalov>
i was wondering the other day, what's a good practice about integers and floats
<teepee>
I wonder if clipper2 helps here as it has a floating point interface. maybe the internal conversion is working better
* J23
crosses fingers thrice
<InPhase>
Kalov: Here's a scad file I wrote for working with imperial units. Feel free to take what you need from it: https://bpa.st/M3WJC
<Kalov>
thanks InPhase!
<InPhase>
Kalov: It keeps mm as the "number" unit, but then you specify inches with in(5) or feet with ft(6). Or you can use mils, or fractions of an inch.
<Kalov>
did you set an expiration date in the paste?
<InPhase>
1 month
<Kalov>
k, i better download it then
<InPhase>
I could post this on github, just I hadn't seen a lot of interest in it, so it lives only in my files for now. :)
<J23>
InPhase .. where is the fathom?
<InPhase>
I see you mocking our national units.
<InPhase>
Which... is totally understandable. ;)
<InPhase>
mm are so much better to work with, but it's nice to take the cognitive load out for matching things up with external parts.
<InPhase>
That ImpStr function for canonically printing out an imperial equivalent to a mm size is a handy convenience function as well.
<InPhase>
I wrote that mostly as an exercise though. I've never used it in practice, but, I can see it being handy.
fling has quit [Remote host closed the connection]
Guest20 has joined #openscad
Guest20 has quit [Quit: Client closed]
<JordanBrown[m]>
I have to wonder how many of the "floating point" errors are really introduced by snapping to the grid.
<JordanBrown[m]>
One of these days I need to build an experimental where I can control the grid behavior, so that I can see for myself how it behaves.
<teepee>
just use fast-csg
<JordanBrown[m]>
fast-csg doesn't use the grid?
<teepee>
as far as I remember the discussion with ochafik, it's not used
<teepee>
also I don't think it's relevant for any 2d stuff
<teepee>
there's no point in just disabling it without any replacement
<JordanBrown[m]>
I'd be interested to see for myself what misbehaves if you disable it.
<JordanBrown[m]>
I would say that floating point errors are microscopic, but that "micro" prefix is many orders of magnitude too large.
<InPhase>
teepee: I think it gets used still with those polyset conversions, but I'm not clear on where those are happening.
<JordanBrown[m]>
I could believe them introducing problems, but I would expect the problems to be down in the 10^-14 range.
<InPhase>
teepee: So it comes down to the fact that not everything in fast-csg is done the fast-csg way.
<teepee>
yes, if it goes through NEF it would apply again
<InPhase>
JordanBrown[m]: I have in fact removed some model problems by dropping the grid resolution to 1024 times smaller.
<InPhase>
JordanBrown[m]: I raised this as a possible codebase change many years ago, but kintel was opposed to it believing it would slow too much down. I did not notice a performance decline in the things I was attempting, however.
<JordanBrown[m]>
I've wondered about that too. If the problems are down in the 10^-14 range, putting the grid at 10^-12 might be enough.
<InPhase>
I think we should probably remeasure in the current codebase, the current CGAL, and current processors, because the conclusions from almost a decade ago might no longer be true.
<JordanBrown[m]>
Or maybe not, since there's always the possibility that something will snap the wrong way, and the smaller the grid is the more likely that is.
<InPhase>
JordanBrown[m]: Well I don't think it was done for correctness, but for speed.
<teepee>
it still destroys geometry
<teepee>
in my view a much better use of time would be trying out the Manifold library
<InPhase>
JordanBrown[m]: So it might also be possible to eliminate the grid snapping altogether. The only reason I did a factor of 1024 was because this allowed me to test it with a minimal code change. (Altering the constant.)
<teepee>
I wish I had time looking into that
<JordanBrown[m]>
I don't know the internal discussions; I thought I'd heard that the grid was there so that two points that were intended to be the same, but that were epsilon apart because of floating point error, would be snapped to the same value.
<InPhase>
JordanBrown[m]: But we'd need to define a set of appropriate models to benchmark, ideally of various different types of construction, and then compare performance with current, with a much smaller grid, and with no grid snapping. And probably we need to test this with and without fast-csg. But I suspect we actually have the opportunity to remove it altogether now.
<teepee>
yes, I think that's one of the main issues, also preventing complexity explosion in CGAL
<JordanBrown[m]>
Yes.
<teepee>
fast-csg intends to replace via remeshing solving the complexity problem differently and geometry aware
<InPhase>
I don't think any "epsilon apart" problems are actually solved.
<kintel>
I was talking to Emmett about Manifold a month or so back. He've very excited about it and strongly believes it's robust enough.
<JordanBrown[m]>
:e#
<JordanBrown[m]>
oops
<kintel>
He may not have time to contribute to OpenSCAD, but I think he'd take bug reports :)
<InPhase>
It's super easy to make designs where "epsilon apart" ambiguities cause render issues. I made one for the wiki docs, and I didn't even think very hard to do it.
<teepee>
ochafik did also do a quick comparison and fast-csg is not *that* bad performance wise
<InPhase>
So if grid snapping is to be fixing that, it's failing I think. :) But, I do believe it at one point made some performance differences.
<teepee>
but it still has some issue where it gets stuck due to complexity explosions
<teepee>
also maybe at some point manifold gets some usable GPU support. I don't think the nvidia stuff is usable in general builds
<InPhase>
If we could remove 90% of design failures that e.g. JordanBrown[m] faces, but make some rare designs take a little longer, while making no performance difference on most designs, that would be an improvement to my perspective.
<teepee>
but as it has that support, it's basically ready to work this way
<InPhase>
But we'd need to see some data to really reassess this.
<teepee>
well, everyone make a new-year wish that ochafik comes back :)
<InPhase>
:)
<JordanBrown[m]>
I run into problems like this only very rarely, if ever, because I do almost everything with primitives, not with polyhedra.
<InPhase>
Making the grid finer, that's a trivial change that takes like 2 minutes. If anyone wants tips on that I can provide.
<JordanBrown[m]>
And only very rarely with imported STLs.
<JordanBrown[m]>
Like I said, I want to look at it sometime. But not today. Today is objects :-0
<JordanBrown[m]>
:-)
<InPhase>
Removing the grid would be a little more effort, but I think really not that much. The grid is used very few places in the code.
<InPhase>
The bulk of such a project is testing to figure out what is actually the right decision.
<InPhase>
Actually, we should probably have a broader policy for cloaks. Perhaps anyone who is set as a member on github?
<InPhase>
I guess we hadn't really thought about cloaks in a while, but they're nice.
<JordanBrown[m]>
I can't see any difference, but maybe that is because I am looking through a Matrix-colored lens.
<teepee>
I would not restrict to github, but I suppose pretty much all people I'm aware of who are not doing coding at least have a github account
<InPhase>
So any github member of the project, plus anyone else teepee says, "Hey that person should have a cloak"? ;)
<teepee>
as there's no separation like other groups have with /developer /supporter and such, I suppose anyone contributing in any way might be eligible?
<InPhase>
There's a representation aspect as well, so we want well-behaved people.
<InPhase>
But I'm not aware of any social misbehaviors of anybody on the list.
<JordanBrown[m]>
We don't talk about Fight Club.
<InPhase>
Naturally.
<kintel>
<rant>Meson - because the world desperately needed another build system</rant>
<JordanBrown[m]>
I haven't looked at Meson, but so far I'm not happy with any build system that I've seen.
<InPhase>
I would appreciate a cleaner build system. I haven't looked at Meson, so I don't know if that is it...
<kintel>
glib uses it, and I need to convince it to build macOS binaries - fun stuff
<teepee>
yes, it also caused some headaches for WASM
<InPhase>
I would certainly appreciate a build system with a lot less platform customization, but that can be asking a lot.
<InPhase>
That is, after all, the one job.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<JordanBrown[m]>
I should have a very-much-draft PR for the objects work today.
<JordanBrown[m]>
Objects, geometry as data, module references.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
nice!
<teepee>
would that also replace the revar object() PR? or would that still make sense in addition?
<JordanBrown[m]>
I was thinking that some people (notably you and InPhase) would look at it in PR form.
<JordanBrown[m]>
s/thinking/hoping/
<JordanBrown[m]>
What I have now is definitely not final. In particular, it has two different variations on the syntax for an object literal - one more JavaScript-y, and the other more OpenSCAD-y, one where geometry literals are a separate construct, and the other where a single syntax does both.
<teepee>
that we can do, but even slightly wider audience is hard to get other than pushing it out as dev snapshot
<JordanBrown[m]>
Yes.
<JordanBrown[m]>
But it would be good to get opinions from at least the three of us before merging.
L29Ah has quit [Ping timeout: 265 seconds]
<JordanBrown[m]>
There's also questions around the exact syntax allowed for module references, and the exact syntax allowed for bringing a geometry value into the model. For that matter, there's the question of whether we support module references *at all*, given that with geometry values a function is almost equivalent.
<JordanBrown[m]>
There's some internal cleanup that ought to be done, but I figure that it is best done after we've figured out the answers to some of these questions - there's not much point to polishing the internals of something that we decide to throw away.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
JordanBrown[m]: It's good timing. I should have time to look into it from the 29th through 31st.
<InPhase>
It is one thing to theorize about usage, and another to try using it.
<JordanBrown[m]>
Yes, exactly.
<InPhase>
JordanBrown[m]: Also, I think you're on that eligible-for-a-cloak list, if you want a nice cloak that you can't see. ;)
<JordanBrown[m]>
I don't know what a cloak is...
<JordanBrown[m]>
(In this context, that is.)
<InPhase>
-!- kintel [~kintel@bras-base-toroon0964w-grc-25-184-148-114-68.dsl.bell.ca] has quit [Changing host]
<InPhase>
Not cloaked.
<InPhase>
-!- kintel [~kintel@openscad/kintel] has joined #openscad
<InPhase>
cloaked
<JordanBrown[m]>
What do I look like, coming in from Matrix?
<JordanBrown[m]>
I should be sort of a green sepia tone :-)
<InPhase>
-!- JordanBrown[m] [~jordanbro@2001:470:69fc:105::2:8434] has joined #openscad
<JordanBrown[m]>
Ooh, all fancy and IPv6-y.
<InPhase>
Oh, but you have not authenticated your account via Matrix, so you cannot get a cloak on that unless you setup sasl or whatever via matrix.
e2k has quit [Ping timeout: 260 seconds]
castaway has joined #openscad
<JordanBrown[m]>
I have no idea how that interaction works. I'm authenticated to Matrix, but here we're talking about how Matrix proxies me over to IRC.
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
milza has joined #openscad
Guest8040 has joined #openscad
Guest8040 has quit [Client Quit]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
othx has quit [Ping timeout: 252 seconds]
aiyion1 has joined #openscad
aiyion has quit [Remote host closed the connection]