<InPhase>
peepsalot: Same, M3 is the smallest I design for.
<InPhase>
At some point you're getting into aluminum foil territory. :)
<InPhase>
Only certain metals even have a chance at 2mm. No metals hold up to any sort of load at that size scale.
<InPhase>
Soft metals for nails are a little bit better, but bend easy. Hardened metals for screws will just snap.
<InPhase>
Made worse because the actual solid rod in the middle of a 2mm screw is a good bit smaller than 2mm, and the cross-sectional area is thus WAY smaller than for a 2mm nail.
<InPhase>
peepsalot: So on the AffineTransform issue, the way you described the problem in that bpa.st is pre-registered in my head as the "do double dispatch instead" scenario.
<InPhase>
peepsalot: I haven't evaluated whether that works here, but you're hitting all my mental triggers for it.
<InPhase>
peepsalot: i.e., you have two parallel inheritances interacting, and you're contemplating dynamic_cast.
J1A8454 has joined #openscad
<InPhase>
peepsalot: For which a valid response scenario is "double dispatch is kind of annoying too, is there a way to refactor instead?" But perhaps there is no sensible other way to refactor this.
<InPhase>
(Be back in ~30-45 minutes.)
J1A84 has quit [Ping timeout: 244 seconds]
LordOfBikes has quit [Ping timeout: 276 seconds]
LordOfBikes has joined #openscad
ur5us has joined #openscad
snaked has joined #openscad
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee has joined #openscad
<peepsalot>
InPhase: ok, i don't know what do double dispatch means. wikipedia suggests that I would flip transform to be a member function of AffineTransform and not Geometry?
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<InPhase>
peepsalot: So a Geometry virtual transform(const AffineTransform&) for which Polygon2d and polyset have an implementation which does affine_transform.applyTransform(*this), and where Transform2d and Transform3d each have virtual implementations of applyTransform(Polygon2d) and (polyset)? Something like that.
<InPhase>
peepsalot: It's not great. But C++ is not great at this specific problem. But the argument for that version is that the boilerplate buys you a little bit more static checking when someone goes to add a new variant and attempts to transform it.
<InPhase>
peepsalot: The classic dynamic_cast maintenance issue is that they are typically buried away from where they are needed, and a failure to cast in location A of the code does not always mean the same thing as the original author intended after changes to location B of the code.
<InPhase>
peepsalot: This is not one of those things I'd advocate strongly as essential. It's just in there as a "best practice" default recommendation. There are plenty of times when you'd go to write such a thing and just shake your head at some messy detail and do it the other way, and let the future deal with it. :)
<peepsalot>
InPhase: there's one other odd bit, that class State has a setMatrix function and matrix can only be Transform3d
<peepsalot>
or *at least* that other complication, maybe more.
<InPhase>
That doesn't seem to contradict anything here I suppose.
<InPhase>
It doesn't need to use the same dispatch pathway, as it desn't appear to play a part in this inheritance issue.
<peepsalot>
ah, yeah
<InPhase>
State seems to be a spectator in a different visitor pattern on the Nodes, but not as something being dispatched. More of a ride-along variable.
ur5us has quit [Ping timeout: 272 seconds]
ur5us has joined #openscad
<peepsalot>
InPhase: so, what should I do for the mismatched Transform2d::applyTransform(PolySet& ) and Transform3d::applyTransform(Polygon2d&) ?
ur5us has quit [Ping timeout: 250 seconds]
<peepsalot>
just put asserts there like Geometry base class did on transform?
<peepsalot>
idk, this seems like a big pain to write all the conversions between Transform3d and Eigen::Affine3d
<peepsalot>
like assignment, i tried: Transform3d& operator=(const Eigen::Affine3d& a) { this->m_matrix = a.m_matrix; return *this; };
<peepsalot>
and a.m_matrix is protected even though Transform3d inherits Eigen::Affine3d
<peepsalot>
i don't know why, i was imagining it would just be able to inherit all these constructors and assignment ops, but i have to redefine them
neur0 has quit [Remote host closed the connection]
teepee has quit [Remote host closed the connection]
neur0 has joined #openscad
teepee has joined #openscad
<peepsalot>
from Eigen::Affine3d import *;
<peepsalot>
:P
<peepsalot>
sometimes these inheritance problems in C++ make me feel like a noob even though I've been programming for decades
<peepsalot>
i'm ready to go back to geometry problems
ur5us has joined #openscad
ur5us has quit [Quit: Leaving]
castaway has joined #openscad
<peepsalot>
i wonder if CGAL's Gmpq rational number class could be wrapped in boost::flyweight, and if that would possibly help performance
<Scopeuk>
I guess unless you can convince cgal to make proper use of the type probably not
<Scopeuk>
as far as I can tell cgal hates the idea that it might be expected to do anything and its even ruder about being asked to do things quickly
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
pah is now known as pa
<InPhase>
peepsalot: It'd have to be a runtime error, yeah, since it's only dynamically determinable by this approach.
Trieste has quit [Ping timeout: 264 seconds]
neur0 has quit [Ping timeout: 258 seconds]
neur0 has joined #openscad
snaked has quit [Quit: Leaving]
<J1A8454>
is this normal? x=1000002;translate([1,1,1]*x/2)cube(x,true); // just count x up and see how the cube moves .. seem to happen only over 10⁶
aiyion has quit [Remote host closed the connection]
fling has quit [Remote host closed the connection]
<InPhase>
J1A8454: This is my least-favorite part of the program. An ugly hack put in to keep the rationals small in CGAL.
aiyion has joined #openscad
aiyion has quit [Remote host closed the connection]
<InPhase>
J1A8454: It is probably that kicking in, given that it's on the same scale.
fling has joined #openscad
aiyion has joined #openscad
<InPhase>
J1A8454: Note that it oscillates like you would expect a rounding error to do right at the threshold where the product of the numbers and that grid factor are around the size scale of 1.
<J1A8454>
inPhase .. i thought this too but why is this not happening with 999999 or lower
<InPhase>
J1A8454: Do 999998.4 and zoom in really close.
<J1A8454>
with decimals / fractions it sure does
<InPhase>
Oh, also 999998
<J1A8454>
but i could not replicate with integer numbers while above 10⁶ it always
<J1A8454>
InPhase 999998 doesn't for me ..
<InPhase>
I think it's just because it's right at the threshold where integers don't have any inconsistent snapping applied.
<J1A8454>
also interesting in 2D this happens for different numbers
<InPhase>
Oof. 999998 disappeared after I did a flush cache.
<InPhase>
Now it stopped doing it.
<InPhase>
Oh! That might be the bug with caching by floats.
<InPhase>
Yeah, nevermind.
<InPhase>
This is not the grid. This is pure caching bug.
<InPhase>
Do a flush cache each time.
<InPhase>
Didn't we fix that after a recent issue?
<InPhase>
I mean, I guess not, but I thought this was addressed already.
<InPhase>
dalias: Change the "8" to match the physical cpu count of your system.
<InPhase>
dalias: I have these in ~/bin/ as oscadcleanbuild and oscadrebuild, so that I can quickly build different PR clones and such without worrying about any setup efforts or variability.
juri_ has quit [Ping timeout: 260 seconds]
<Virindi>
the latest nightly package seems to get even higher fps than before, with all the vbo prealloc and stuff, I am happy :)
<dalias>
inphase, thanks. that's equivalent to what i'm running now
<dalias>
impressive that it was usable at all at -O0
<InPhase>
teepee: Do you think it would be meritorious to put those build scripts somewhere? It's mildly platform specific in that it assumes bash is installed, although you can have that on any platform. Would there be a place for build tips and tricks?
<dalias>
i don't like the idea of shipping a script with rm -rf in it...
<InPhase>
Well, it does a safety check first, because of it.
<dalias>
anyway the bashisms are entirely gratuitous and could be fixed in a few seconds
<InPhase>
Sure, although those should work even on the old bash version that ships with macos.
<InPhase>
It's only Windows it doesn't hit, which either has a shell installed or doesn't. And I don't know anyone out there installing Bourne shell on Windows instead of bash. :)
<teepee>
the scripts folder has some extra stuff, so if it's releasable it could live there
<InPhase>
In the repository?
<InPhase>
I'll think about how to fix up the hard-coded cpu count. It would be nice if there were a good cross-platform way to do that.
<InPhase>
I will test timing on make -j without the 8. I think that's slower, but I will see.
<dalias>
i don't use bash, tho i do have it installed for the occasional #!/bin/bash >_<
<dalias>
anyway the bashism here is entirely gratuitous. i think the [[ ]] are just acting as ugly versions of [ ]
<dalias>
and weird bash syntax is used for the function
<InPhase>
I could uglify it for /bin/sh if that were important.
<InPhase>
Just not sure if that actually matters for any platform in 2022. :)
<InPhase>
I figured bash became the standard thing to always have around everywhere but Windows 15+ years ago.
teepee has quit [Ping timeout: 258 seconds]
<InPhase>
One exception system I have is my openwrt router with its tinybox stuff, but obviously that's not an OpenSCAD build system.
<InPhase>
But please, if anyone is aware of a platform where OpenSCAD is used that doesn't have a /bin/bash, let me know.
<InPhase>
(Other than Windows.)
<InPhase>
Oh. My test gets the same time with -j as with -j8 for the current master branch. So I will standardize on that.
<InPhase>
Wait... I might have an environment variable setting that to 8. More testing needed.
teepee has joined #openscad
<dalias>
no -j here :-p
juri_ has joined #openscad
<dalias>
one 2GB cc1plus process is enough :-p
<Virindi>
2GB? pffft!
<Virindi>
these days 2GB is half a browser tab worth of tracking js
<JordanBrown>
Feh. Matrix is back to time warping again.
<JordanBrown[m]>
I think our only current Windows build environment is MSYS2, and that has bash.
<JordanBrown>
^^ that's from three minutes ago.
<JordanBrown>
Two more should be coming through momentarily.
<JordanBrown[m]>
InPhase: we were talking about computer performance. I did some tests and decided that -j3 was the optimum for my desktop and -j2 for my laptop.
<JordanBrown[m]>
(Though I think that might have been "what makes the reported CPU usage just barely hit 100%" rather than a total-elapsed-time measurement.)
TIBL has joined #openscad
<TIBL>
hey guys, this openscad bug has been bothering me for years, I am wondering if it is actually a known problem? (open file doesn't complete if it isn't the first file you open after starting the program) http://www.youtube.com/watch?v=b8Yqo7jLk1M
<othx>
TIBL linked to YouTube video "OpenSCAD file open/cache bug?" => 1 IRC mentions
<TIBL>
it seems that it may have something to do with my large file being just an include, or it being large, because it doesn't seem to happen so often for trivial files
<TIBL>
it is 100% repeatable with my large printer file
<TIBL>
so I have just gotten in the habit of always restarting the openscad process whenever opening any file
<dalias>
wow it's wild faster than old 202101 now
<J1A8454>
TIBL this would open in a new tab for me
<dalias>
(without the -O0 footgun :-p)
<TIBL>
as you can see, I just do everything in an external editor
<dalias>
csg with an imported STL with >45 parts where the csg only interacted with one of them took about 2s to render rather than bogging down at 3GB+ of memory usage and swapping forever never to finish
<J1A8454>
try with the internal to find out where the problem is
<teepee>
you open a file that is already loaded, so nothing happens I suppose
<dalias>
<3
<dalias>
and roof() is amazing
<dalias>
i already wrote a trivial module to loft it
<TIBL>
wow what, I didn't even realize tabs exist! I only use external
<dalias>
allowing fillets, curved vessels defined by 2D outline of widest part, etc
<TIBL>
so in order to open a file I need to enable editor, close everything else, and then hide editor again? seems that it is poorly designed for external editor workflow then :(
<TIBL>
maybe if when you open a file, if it is already loaded, it should switch to it.
<TIBL>
I guess I am "using it wrong" :(
<J1A8454>
hmm wondering what "next and previous window does" but as tabs are shown in the editor window it may be a problem to switch without that and only external editor
<teepee>
well, I would not rate it as a bug, but it might make sense to switch tab on loading an existing file
<TIBL>
user experience problem? :)
<Scopeuk>
it's always worth discussing how people expect things to behave. there are whole load of edge cases and unless people talk about them some won't get considered
<teepee>
hmm, actually it does that for me, at least in the nightly
<JordanBrown>
I continue to wish that I could have the pre-tab UI back :-(
<TIBL>
this is nightly 2022.10.22.nightly
<J1A8454>
dalias roof doesn't like $fn over 60 and when you use +–offset
<TIBL>
the latest package for debian
<TIBL>
or, as of yesterday ;)
<TIBL>
when did tabs get introduced? I bet I have been using external editor since before tabs even existed. I think I've been using it since like 2014
<dalias>
j1a8454, ?
<J1A8454>
teepee what is »window↦next window ? can't see any effect
<TIBL>
(I've been using openscad itself longer than that but in the ancient times I used the internal editor)
<J1A8454>
dalias you will get geometry errors that are hard to control if you use many roof as you need to find the magic $fn number that works .. kind of annoying
<teepee>
J1A8454: keyboard focus
<J1A8454>
wouldn't it make sense to have a keyboard shortcut for this then?
<teepee>
ALT+W + N
<teepee>
but maybe we can get the keyboard shortcut editor in eventually
<J1A8454>
the next window didn't change my keyboard focus
<TIBL>
I think that if the editor is hidden, opening a file should not open a new tab, because obviously the user is not using tabs (they aren't even visible). It should instead close the previous file and open only the new file.
<J1A8454>
alt w opens the pull down .. n selects .. then i am back in the old window
<teepee>
if you enable both console and error-log and put them as tabs over each other it should be visible whats going on
<teepee>
also there might be bugs with all the new windows added lately
<J1A8454>
TIBL sounds reasonable to me .. or some window manager.. the "window" tab should list the tabs
<J1A8454>
teepee i use them detached maybe that is why
<teepee>
right, it's probably not tested for that
<teepee>
not sure it's even possible in general
<J1A8454>
( maybe hide it then for this usage Ü )
<JordanBrown>
teepee "probably not tested for that"... for what, exactly? I run with the various panes detached too. I don't need an editor or console that is as big as I keep the 3D view.
<teepee>
ALT+W + N for detached windows
<JordanBrown>
ah
Notkea has quit [Quit: Bridge terminating on SIGTERM]
KREYREN has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has quit [Quit: Bridge terminating on SIGTERM]
one-star-chef has quit [Quit: Bridge terminating on SIGTERM]
phas858[m] has quit [Quit: Bridge terminating on SIGTERM]
Bram[m]12 has quit [Quit: Bridge terminating on SIGTERM]
metasean[m] has quit [Quit: Bridge terminating on SIGTERM]
DenKn[m] has quit [Quit: Bridge terminating on SIGTERM]
JordanBrown[m] has quit [Quit: Bridge terminating on SIGTERM]
jochen[m]1 has quit [Quit: Bridge terminating on SIGTERM]
Cadair has quit [Quit: Bridge terminating on SIGTERM]
<JordanBrown>
Come to think of it, another important reason that I keep them detached is that I often shrink the 3D view to nearly its minimum, to take pictures for e-mail.
Cadair has joined #openscad
<TIBL>
in the past I ran the 3d window at like 50x50px, that was the only way I could use openscad pre-vbo on my laptop :)
mikolajw has joined #openscad
Notkea has joined #openscad
one-star-chef has joined #openscad
JordanBrown[m] has joined #openscad
KREYREN has joined #openscad
DenKn[m] has joined #openscad
phas858[m] has joined #openscad
jochen[m] has joined #openscad
metasean[m] has joined #openscad
Bram[m] has joined #openscad
juri_ has quit [Read error: Connection reset by peer]
juri_ has joined #openscad
juri_ has quit [Ping timeout: 252 seconds]
juri_ has joined #openscad
J1A8454 has quit [Quit: Client closed]
J1A8454 has joined #openscad
qeed_ has joined #openscad
qeed has quit [Ping timeout: 260 seconds]
<dalias>
j1a8454, i'm confused why you'd get geometry errors if they're not overlapping, just stacked against each other. is it because of numeric precisions with same-z but the outlines of the butted faces not matching perfect?
<dalias>
if so, i think you can solve this (albeit stupidly) with some overlap between them
<dalias>
could also, instead of using offset to make the segments...
<dalias>
use slices of the base roof() for all of the segments
<dalias>
basically just a single roof, then grabbing and scaling the parts of it you want
<dalias>
intersect with a translated-in-z linear_extrude of the base outline gets you that
<InPhase>
TIBL: I just tested release, master branch before the latest tab updates, and master branch after the latest tab updates. All three correctly opened a new file and switched to that file while using an external editor and having the built-in editor hidden.
<InPhase>
TIBL: If you are getting different behavior please give very specific reproduction steps.
<InPhase>
TIBL: Regarding external editor use, if you are also a terminal user, this script is how I typically open files, such that under normal use I'm firing up a new OpenSCAD instance with every file anyway: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#I_don't_like_the_editor,_can_I_use_my_favourite_editor_instead?
<InPhase>
(But I tested the other method of opening just to see.)
TIBL has quit [Quit: Client closed]
TIBL has joined #openscad
J1A8454 is now known as J1A84
<J1A84>
dalias the error come from roof itself, when creating the skeleton, points to near to each other cause problems.
TheAssassin has quit [Ping timeout: 258 seconds]
<dalias>
ah
TheAssassin has joined #openscad
<dalias>
trying to difference these lofts, i got "normalized tree..." errors
<dalias>
but just making the loft module use render() fixed it
<dalias>
render() is so ridiculously fast now it doesn't matter
<dalias>
anyway wow this is going to make it possible for me to get done a bunch of stuff that i had temporarily shelved becuse it was too slow or too hard to do without roof
<J1A84>
i wonder how the offset extrude will incorporate that
<J1A84>
only bad that all designs using these cool new features are not usable with the official 2021 release
<dalias>
yes. TAG PLEASE
<dalias>
offset_extrude is just a couple lines of scad on top of roof
<dalias>
(intersection over all angles of skewed linear extrude :)
<dalias>
i've actually used this with just 4 steps for passable chamfers :-p
<InPhase>
If I recall offset_extrude's potential to make roof obsolete is the primary reason to keep roof experimental.
<dalias>
inphase, i don't see how that makes sense
J1A84 has quit [Quit: Client closed]
J1A84 has joined #openscad
<InPhase>
dalias: Well you don't want redundant features set as deprecated.
<InPhase>
dalias: Better to get it right the first time.
<dalias>
they're equivalent and a basic offset_extrude (without twist, scale, etc) can be implemented as roof
<dalias>
and roof can of course be implemented as offset_extrude
<InPhase>
Yes. The code certainly can be reused. The hard question is always about the language features, since that's what you want to keep long term stable.
<dalias>
if "offset_extrude" is really the desired long-term direction, just provide it now without all the bells and whistles, using the roof() code
<dalias>
and expose that instead of roof
<teepee>
that's the interesting question, roof is offset extrude + angle
<dalias>
then the fancier features can be added later as a new implementation of it
<dalias>
teepee, ?
<InPhase>
That was one of the ideas on the table in the offset_extrude PR. But it was deferred as an option because the interface for offset_extrude hadn't been finalized.
<teepee>
where offset extrude + delta might not easily reproduce roof, or am I missing a trick?
<dalias>
well it might in some degenerate way fail to
<dalias>
but like roof() is just offset_extrude with infinite height and infinite offset (and them both being the "same infinity")
<InPhase>
I think I had at one point supported the notion of "offset_extrude()" with no parameters defaulting to roof. But once you set a default you want to be consistent with variations away from that default, so it might not actually be a good idea. offset_extrude really has to be sorted out first.
<dalias>
if offset_extrude doesn't specify "offset at end" but "slope of offset" then it could just accept undef/infinity/whatever as the height and it would behave just like roof (with default slope of 1)
<dalias>
this would differ from how scale and twist work tho
<dalias>
but i hate how scale and twist work now
<dalias>
i *always* want them to be "per unit z" not "final value at end"
<InPhase>
The best offset_extrude would take a function reference for the offset. :)
<InPhase>
But also have some simpler features.
<dalias>
:)
<dalias>
i always end up having to manually compute the final twist or scale to get the right per-unit-z amount
<teepee>
InPhase: yes!
<teepee>
please!
<teepee>
:)
TIBL has quit [Quit: Client closed]
TIBL has joined #openscad
<dalias>
wow i can't get over how fast this is
<dalias>
render takes basically no time even for complex things
<teepee>
there are still a couple of cases where it exploded but ochafik did really dig into the details to minimize issues
<teepee>
now the question is if the manifold library would be even faster :)
<peepsalot>
InPhase: any idea about the assignment operator I mentioned? I am actually stumped on that one.
<peepsalot>
I kinda did want to learn the "best practice" way, but its starting to grow into a lot of stuff just to replace one line of improper code
N4buc0 has quit [Remote host closed the connection]
N4buc0 has joined #openscad
eric2k has joined #openscad
eric2k has quit [Client Quit]
ur5us has joined #openscad
Fleck has quit [*.net *.split]
othx has quit [*.net *.split]
Xeha has quit [*.net *.split]
rue_mohr has quit [*.net *.split]
gbruno has quit [*.net *.split]
gbruno has joined #openscad
othx has joined #openscad
othx has joined #openscad
othx has quit [Changing host]
rue_mohr has joined #openscad
Fleck has joined #openscad
gbruno has quit [Changing host]
gbruno has joined #openscad
Xeha has joined #openscad
<InPhase>
peepsalot: Yeah, understood that it was supposed to be a "remove warnings" PR and not a "refactor the world" PR.
<InPhase>
peepsalot: It would be fair to take the simplest approach that removes the warnings, and maybe open an issue and/or add a comment about what should probably be refactored.
<InPhase>
peepsalot: I think I missed the assignment operator question.
<peepsalot>
peepsalot> like assignment, i tried: Transform3d& operator=(const Eigen::Affine3d& a) { this->m_matrix = a.m_matrix; return *this; };
<peepsalot>
<peepsalot> and a.m_matrix is protected even though Transform3d inherits Eigen::Affine3d
<peepsalot>
the difficulty is that I have to define things to convert back and forth between Eigen::Affine3d and Transform3d
<peepsalot>
InPhase: ^
* InPhase
nods.
<InPhase>
Transform3d does not inherit Eigen::Affine3d
<InPhase>
It appears to, quite grossly, be a #define Transform3d Eigen::Affine3d
<peepsalot>
no, in the replacement code I was writing
<InPhase>
So I'm a little confused.
<InPhase>
Ah.
<InPhase>
Is that part in the PR?
<peepsalot>
no, cause I hadn't commited any of it. it was in that original bpast I showed that started you talking about double dispatch
<peepsalot>
this is the latest revision I was working on: https://bpa.st/FLKA (it doesn't compile)
<InPhase>
Oh! Yeah. Now it hits my brain clearly. That will fail.
<InPhase>
You can access it in this-> because there it is inherited. But inheriting doesn't give you the right to directly access protected members of a base class object that's not the inherited type.
<InPhase>
If that operator= took a Transform3d, you would be allowed to access it.
<InPhase>
peepsalot: Minimal testcase: Uncomment the two lines, and it will fail: https://bpa.st/RG7Q
<InPhase>
Frankly I think this is a pretty arbitrary language design decision, and it could reasonably have been allowed. But that's how it is.
<peepsalot>
yeah, i mean i get it now. it was just unexpected at the time. it just makes conversion assignment operators really difficult
<InPhase>
I think you can write something like... static_cast<Eigen::Affine3d&>(*this) = a;
<InPhase>
Assuming they have an operator= in the base.
<InPhase>
That implementation is hard to follow, as I don't know what these indirection types are. But it looks like that might exist.