<church__>
Guys: theoretic question on how should i write more efficiet in openscad. I have made module that gets run with values in row of constant array and then with several If-s with || ORs and && ANDs do several actions, generate various objects, including running other modules for that, move them at specific places and so on. I call this module multiple times (for every row of param constant array)
<church__>
Observed problem seems, that some heavy object generation gets called way more times then they are. Suspecting that they get called for every possible "If branch". When i should have just 4 times that object module ran, according inserted echo("module X is running") it gets ran way more times which i suspect is inefficient/multiplies few times rendering load.
mmu_man has quit [Ping timeout: 252 seconds]
<church__>
For example, one of params in array row might be object orientation - right/left/both. another param might be object modification choice (with tip/without). When i should end up with just 4 such objects .. then why for debug purposes echo(); in module of that object generation gets run way more times? :/
<church__>
of course, setting params fixed manually and manually duplicating object generation module will probably run it just 4 times. But then i'll loose parametric adjustability/choice (by generating that parameter array with customizer in advance to choose various configurations per multiple slots/array rows)
<church__>
Might it be that || Or-s in if-s are culprits for running multiple times? Something along lines that submodules that get called are setting their own variables/constants in them with cycle (for generation of object segment by segment), and i recall that "constants" in openscad get set "during compile time of code in openscad", thus - their setting gets ran for every If branch?
<InPhase>
kintel: Did you clean build?
<InPhase>
kintel: Never trust an unclean build after the first crash.
<InPhase>
kintel: The theory of incremental building and the reality don't always align.
<InPhase>
church__: ^ Try using https://bpa.st to show the code you're talking about?
<InPhase>
church__: It'll be easier to understand the nature of the issue while actually looking at it.
<church__>
InPhase: are there limits on paste code side there? and hmm .. i suspect i'll need to accompany with long explanations, as due work in progress & my in general very bad habits regarding code syntax, my model code might be hard AF to read :/
<church__>
err, typo. "on paste code size"
<InPhase>
There are some limits, but it would take a pretty big file to go past.
<church__>
1K long rows should work?
<InPhase>
Yeah.
<InPhase>
I'm not reading 1K rows, but I'll skim it to see the structure of what you're talking about better. ;)
<InPhase>
And it can't be TOO bad. I mean, I've seen J25k18's code. lol
<InPhase>
(An inside joke. J25k18 and I sometimes implement pretty similar types of things, but with wildly incompatible mindsets and typing styles.)
<church__>
InPhase: my bad habit is to have as much code as possible on screen so that i have to scroll less & in most cases have all relevant code within single screen. That makes many operants per row, and harder to do insertions or individual operant commenting out (as row needs to be split first) .. and probably makes way harder to read
<InPhase>
That's probably a terrible idea, but go ahead and bpa.st it. :)
<church__>
way i observed in others code, they split almost each and every translate/rotate and base object in separate rows, but it puts just like 1/10 of code per unscrolled screen :)
J25k11 has joined #openscad
J25k18 has quit [Ping timeout: 240 seconds]
<church__>
https://bpa.st/PTGA .. few notes 1) don't increase quality to max unless powerful box as it can drop $fs to 0.04 in [F6], 2) see twrun echo's in debug output (per rendering intensive submodule run). I run per each of slots/rows (of translate vals/if enableed/direction) from eg. near end commonbody() module cablepath(), which then with if-s forms from in-module code shape .. and also runs twistanglelift module .. should be just 4 times, but why so more
<church__>
echo-s in debug output?
<church__>
(and don't tell that code is awful and unreadable. i do know and warned about that :D )
<InPhase>
Your link doesn't work...
<InPhase>
Is that the right link?
<church__>
oh, sorry, as there is no direct paste to here, i wrote manually and erred even with that :/ .. https://bpa.st/PGTA
<InPhase>
I figured, but couldn't sort out what rearrangement of the letters. ;)
<InPhase>
Okay. Fancy elaborate contraption. Now what part of the code corresponds to your question?
<church__>
in module commonbody() there is for(i=[1,2,3] { running cablepath() module with params from cblpath array
<InPhase>
Okay.
<church__>
cablepath module per each slot forms pathway. including running other module twistanglelift. there should be just 4 runs of it (two one sided, one two sided)
<InPhase>
You have one of those ridiculously wide monitors, don't you.
<church__>
but that twistanglelift seems to be called way more times if i beleave echo("twrun" in it
<church__>
I usually work on 4K 55", but in this case i run openscad via rdesktop of 2560x1440 :)
<InPhase>
Okay. I'm working on tracking the behavior. First thing I'll advise is that you have sequential if statements that are at the same scope level but are actually indented differently from each other.
<InPhase>
This is a good way to shoot yourself in the foot on understanding what the code does. I'm checking your bracket matching with my editor to check on these.
<InPhase>
But I'm not 100% sure that what you have there in cablepath is what you intended to have, because of the indentation mismatch.
<InPhase>
e.g. line 455 and 472
<church__>
well, question was how to write more efficiently, as i suspect as i did it seems wrong
<InPhase>
First I'm trying to sort out what you were trying to do.
<church__>
depending if (for slot) direction of object needs to be to right or left or both, to generate/orient according twistanglelift object. optionally it's variety with tip on top, if there is outlet also pointing up
<church__>
you can click "dbg_showcable" checkbox in Quality.. customizer tab, and play with cable path front/cable path mid/cable path rear in customizer tab "Cable management paths.."
<church__>
then it should show up as object, not just something pathway was diffed with
<InPhase>
church__: This is aside from the fact that assemble/disasemble calls cablepath.
<church__>
commonbody gets diffed with cut-shape brick to form innerbody. rest of what's left is outerbody. assemble/disassemble just places them around.
<InPhase>
church__: But do you intend to call cablepath so many times through that innerbody path?
<church__>
but even if you comment out for(i=[1,2,3] cablepath rows in assemble/disassemble so that just diffing/cutting in commonbody gets run .. it still ends up in way more runs of twistanglelift
<InPhase>
I see 8.
<InPhase>
4 times 2, which makes sense.
<church__>
but if i need just 4 of them to end up in model, why it's not run just 4 times :/
<InPhase>
Each call of commonbody is a call to cablepath...
<InPhase>
And innerbody calls cablepath twice, by the act of calling commonbody which calls cablepath, and by calling outerbody which calls commonbody which calls cablepath.
<InPhase>
Now the question for you is why. ;)
<church__>
i have extra cablepath calls in assemble/disassemble to enable showing them, IF i click dbg_showcable in customizer to better visualise changes. but if it's off, should it run? if(dbg_showcable && $preview)
<church__>
and even if commen those out there ..
<church__>
just leave single !for(i=1,2,3 with prefixing to leave just single run, with nothing of rest of model. still full of twrun in debug output
<InPhase>
If you comment out line 768, the commonbody in outerbody, 12 twrun outputs goes down to 4.
<InPhase>
But this is not surprising. You call innerbody and outerbody, and outerbody has 1 call to commonbody, while innerbody has 1 direct call to commonbody and 1 call to outerbody that calls commonbody.
<church__>
LOL. now i'm trying to find out, why it got there in first place :)
<InPhase>
The question of how to better organize this would center around the question of what you're really trying to do. ;)
<church__>
i wrote this with small increments/additions over long period of time with lot of procrastination involved, so even remembering intentions is not easy :D
<InPhase>
Yep, clearly.
<InPhase>
Which is fair. Everybody has done it after some time doing these things. ;)
<InPhase>
The way to try to address it, is to keep the code neater (better and more consistent indentation and formatting would help you a lot), and to try harder to break code up into more well-labeled sections that keep clear what things actually are.
<church__>
my bad habbit reasoning was to have more of code unscrolled in front of my eyes. with doing code cleanup later on :D
<InPhase>
Yeah. But you also can't mentally process that much code at once.
<InPhase>
It's a blur.
<InPhase>
Human brains just don't work that way.
<church__>
also in most cases those long "rows" are linked. eg. multiple transformations ... or single object
<InPhase>
So you have to use language structures (maybe more modules), or comments, to mark off sections of code. Then you can think in terms of the higher level reasoning of those pieces.
<InPhase>
church__: It's actually pretty tough to see what things are single objects, because you have braces very inconsistently placed, and a lot of floating semicolons in the middle.
<InPhase>
I had to be very careful to check which if/if and if/else chains were actually nested and which were sequential. I'm sure it's equally hard for your brain when you come back to it after a delay.
<InPhase>
A good rule of thumb is to ALWAYS use braces { } for if and else statements.
<church__>
as my rows already are long, often i remove them if it's for single object;
<InPhase>
And always close the brace with indentation matching the indentation level of the if. Then you can track what's inside of what by just looking.
<InPhase>
Yeah. But it will cause you mental parsing issues.
<InPhase>
And leads to bugs.
<church__>
and i rely a lot of openscad's editor syntax highlighting. if i select one bracket end, other gets highlighted
<InPhase>
That wasn't the bug here, but the harder you make the code to mentally parse, the harder it will get to track down bugs when you have them. :)
<church__>
i see people often also using union-s. should i?
<InPhase>
And in fact, that's what happened to you. You thought you had a problem with your conditionals, because you were having trouble parsing them. But it was just something more straightforward with your chain of calls. But your if/else chains and sequences got your brain too distracted trying to re-understand them.
<InPhase>
Lining it all up will help you out a lot. :)
<church__>
InPhase: LOL, that's why initially i tried to put it in words, to not have to show such ugly code :D
<InPhase>
Yeah. :) But alas, the nature of the problem is in the code.
<InPhase>
church__: Now, for how to do things better... Line 446, has a bunch of ifs, and then does something. Tell me in 1-3 words what it does after that.
<InPhase>
That's the up/leftup/rightup/all line.
<InPhase>
This requires a label-by-code solution, so the 1-3 word description matters.
<church__>
one slot's pathway is formed from several bits. like inlet, sideconnector, outlet. and some possible extras. eg. if one of bits lack something, i fill lacking with other bit
<church__>
as there is no hull possible due lot of concave things, i need to fill out differences with generated objects
<InPhase>
Distill those lines 447 through 453 to a description of 3 or fewer words that makes sense to you.
<church__>
straight outlet up + rounded to front bend
<church__>
oh, 3 or fewer :)
<InPhase>
It doesn't have to make sense to me. It has to make sense to you.
<church__>
InPhase: did i win award of "worse then J25k18 code"? :)
<InPhase>
Ehhhh, keep at it, and maybe you'll reach that status. lol
<InPhase>
church__: Do you have those 3 words? I'm waiting to explain the next step of what to do with them.
<church__>
oh, sorry, i lied, second half of those lines have small bend to left
<church__>
but i guess i get where you are pointing. due bad structure/syntax/comments i myself have hard time to read what i have
<church__>
i'm just used to temporarily prefix with # to visualise part, and structurising/commenting .. pay too little attention to do properly
<church__>
even if i lack comment, i see what it is after # & F5
kintel has joined #openscad
<kintel>
InPhase Yeah, but I should probably also cleanup out my ccache..
<InPhase>
church__: Yeah. Those tools are there to provide that capability. But, as you saw, past a certain complexity it'll get away from you. And then you'll need to make things neater and better abstracted into components, and use more precalculated values to simplify the logic flow.
<InPhase>
church__: There's a learning process to it. As you practice it, eventually you'll start just doing it naturally for everything from the beginning.
<church__>
i just over course of many days/weeks/months incrementally add/change small bits (procrastination dictates workflow) .. and it ends up .. as such steaming pile :D
<church__>
as for myself .. i'd rather learn better trigonometry. i still haven't got that twistedanglelift exactly how i want, to have everything smoothly joined/rounded/filleted
<church__>
but as due lack of trigonometry skills / making up bits from googled up work of others & googled up specific trigonometry bits + lot of experimenting adjusting here & there .. it's not straightforward/time consuming/inefficient
<church__>
and as it happens, way too often geometry/trigonometry is needed to workaround openscad limitations (eg. not being able to hull convex objects, thus forming from parts. or to align one bit to another)
rawgreaze has quit [Remote host closed the connection]
<church__>
InPhase: the more i think about it, cannot think of way of not running cablepath twice. both inner/outer need to be diffed with them. be they cut from commonbody with cablepath diffed, and then diffed from it, or via designing each separately and cablepath diffed each.
<church__>
so commenting 768 line is "not it" :)
<church__>
unless there is single part divided by cut line, but if i'll print in such way not-disassembled it probably will melt/stick together
<InPhase>
church__: Yeah, I figured there was probably a reason you did it, if the shape looked okay.
rawgreaze has joined #openscad
<church__>
InPhase: how openscad deals/caches such cases? does it run commonbody/cablepath separately twice, or in 2nd call reuses what rendered in first call?
<InPhase>
If it's called with identical parameters, the result is cached.
<church__>
hmm, so theoretically there shouldn't be no performance gains trying to halve those cablepath calls
<InPhase>
You'll still see echo and such. The geometry calculations are what get cached.
<InPhase>
Almost always, the geometry calculations are the only heavy part.
<church__>
is it the same way for calculations done per segment with cycle?
<InPhase>
I'm not sure what that means.
<InPhase>
But also, typically only the caching of the big chunks makes a meaningful difference in the runtime.
<church__>
innerbody > commonbody > cablepath > multiple twistanglelift module calls with building from segments .. innerbody > commonbody > cablepath > multiple twistanglelift module calls with building from segments
<InPhase>
If it has components that are identical in their parameters repeated within it, then those would also get cached on repeat calls, assuming you don't fill up your cache.
<church__>
i see. thanks for clarifying that
<InPhase>
But it's not like your model is slow anyway. It's rendering in a third of a second for me.
<InPhase>
Total rendering time: 0:00:00.340
<church__>
at low quality. with max quality ($fs=0.04) F6 render after flushing caches runs for ~ 20min and uses upto ~ 25G RAM on amd 5900x / 32G RAM box
<InPhase>
Which one of your $fs lines?
<church__>
also untill i stuffed render() in intersections and few other places, often CSG object limit prevented from rendering
<church__>
InPhase: just rise quality slider to end. it will change $fs.
<InPhase>
You don't have one set to $fs=0.04
<church__>
(in customizer)
<church__>
in preview i have limited it to 0.4, but in F6 render it should go down to 0.04
<InPhase>
This is of course a wild setting choice.
<InPhase>
But it takes 13.7 seconds for me at $fs=0.04 with design flush caches.
<InPhase>
Are you perhaps still using the last stable release?
<church__>
why, to not wait much for rendering and doing small changes here and there and see them in draft, and then push quality up for final render for print/export?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<church__>
no, i use 2025.01.16 .. F6 render often is faster then F5 :D
rawgreaze has joined #openscad
<church__>
all hail to sun^H^H^Hmanfifold gods :)
<InPhase>
church__: Most 3D printers max out at around 0.4mm resolution, so I usually don't go below that. But I tried your 0.04, and 13.7 seconds for me with a build from today.
<church__>
my max out at 0.08 layer size, so thought that half of that should produce smoothest mesh
rawgreaze has quit [Client Quit]
<church__>
(as in 3d printers have nozzle sizes .. but also can print at thinner layers then nozzle diameter)
<InPhase>
Oh, I see you're also trying to set $fa=0.01; That's crazy stuff.
rawgreaze has joined #openscad
<church__>
$fn=0 & $fa=0.01 .. this way i can just change $fs for consistent segment size throughout
<InPhase>
$fa of 0.01 means 36000 steps around a circle for very large circles.
<church__>
IF $fs also smaller
<church__>
way i found in docs & models of others, $fn=0;$fa=0.01 just means "to not limit" if quality is adjusted with just $fs
<InPhase>
Well don't do that. :)
<church__>
as in? i can adjust single constant to change render quality. without calculating needed $fn for each and every microbit throughout
<InPhase>
Yeah, I mean set $fa to something more reasonable, like $fa=1
<church__>
segment size will stay same both for larger and smaller diameter rounded surfaces. and as i use $fs as segment size, there aswell
<InPhase>
Even $fa=0.1 is wildly smooth.
<InPhase>
Exactly how shiny smooth does the model really need to be? :) What sort of system do you plan on printing it on?
<church__>
but if i have eg. $fs=1mm .. so even if $fa=0.01 - i will still have small number of segments in cylinders/spheres/circles. 0.01 is rather "not limit" from angle side
<InPhase>
Exactly, which doesn't make sense.
<InPhase>
The angle changes are so small that they are not discernible in the printed result.
rawgreaze has quit [Client Quit]
<InPhase>
There's a reason both $fa and $fs are used. It's because these separately correspond to limits where you end up having changes that aren't meaningfully represented in the finished product.
<church__>
but $fa=1 will mean, that if i'll have LARGE radius shape, i'll get visible big segments
<InPhase>
Have you tried printing a cylinder in this setting?
<InPhase>
They're extremely round. :)
rawgreaze has joined #openscad
<church__>
I have in past printed fanduct/adapter (with in similar way set quality). with constantly changing radius from like 5cm to 0. average mesh triangle size stays constant which is what i wish
<InPhase>
If the angle size is below a certain limit, you can't tell one polygon from the next on a rounded piece.
<church__>
with no excessive increase in count when radius small, with no visible big segments when rad is big. just single place/constant to change throughout. convenient & what i wish
<church__>
InPhase: but if $fs is larger then what small $fa would dictate, then no problems from that.
<church__>
i now touch only $fn and only if i want to get specific shape like triangle or hexagon from circle. for rest quality wise - $fs only.
<InPhase>
church__: The trig is as follows. For $fa=1, to figure out how round it is, you draw a triangle in the middle of your polygonal piece making up 1/360th of the circle. So from the middle of that polygon to the edge, is a right angle triangle with an angle of half a degree. cos(0.5 degrees) is 0.9999619230641713. This means that with $fa=1 the middle of your polygon is 1/26262.6 inset from the edge of
<InPhase>
your polygon. This is what you're trying to correct by making $fa smaller.
<church__>
or rather if i draw circle with $fs=1 but of radius .. let's say 20cm .. for $fa "to not hit in" and produce visible big segment lines :)
<InPhase>
By setting $fa to 0.01 you are aiming for the middle of your polygon being only 1/262624511.5th smaller that the edge. These are crazy unrealistic thresholds to aim for.
<church__>
$fs doesn't let small $fa to do bad things :)
<church__>
i just "take $fn & $fa out of picture"
<InPhase>
If your circle is 1 meter in diameter... An entire meter... $fa says that your target polygon radius precision is 1 nanometer. lol
<InPhase>
Sorry, 2 nanometers.
<InPhase>
$fa of 0.01, that is.
<church__>
of course, at some point of theoretically very large model i will use larger segment sizes too
<church__>
but as set $fs doesn't let $fa to do bad, it's just one thing less to care about
<InPhase>
But you have circles of different sizes. Using both $fa and $fs at reasonable values, gives you good precision across the full range, without calculating tons of useless polygons.
<church__>
as in? i don't see that calculation of useless polygons. not in result not in performance hit?
<InPhase>
Did you follow the entire long description I just gave about the radius precision by setting $fa?
<church__>
i guess i missed some if you ask so
<church__>
you mean that "The trig is as follows.."?
<InPhase>
Yes.
<InPhase>
I'm trying to explain what sort of precision $fa values actually correspond to.
<church__>
just for any sake i changed $fa from .01 to 1, flushed caches, maxed quality ($fs=.04) and trying out F6 render
<InPhase>
The trig functions are non-linear, so they start getting really good really fast as angles get smaller.
<InPhase>
cos(x) is approximately 1-0.5*x^2 for small x. This comes from the Taylor expansion for it. But that also means that as you shrink $fa by a factor of 2, the precision you get is 4 times better. This goes really fast.
<InPhase>
For a 1 meter circle, your radial precision with $fa = 1 is already as good as 20 microns. That's 1/50th of a millimeter.
<InPhase>
If you have a printer with a 1 meter print bed that can print better than 20 micro resolution, let me know what brand it is. ;)
<InPhase>
s/micro/micron/
<church__>
obviously i have simple consumer FDM bambu printer. But i hate 3d printing artifacts (like layer lines) so for self, where i don't care about print times, often print with small layer thickness.
<InPhase>
For which you're probably doing 0.1mm, or 100 micron.
<church__>
and somehow my line of thought was that i should generate 3d models with twice the smaller dimension i can spec, to never see any limitations from those
<church__>
err, wrong wording. with twice smaller mesh triangle size then smaller dimension i can spec on printer
<church__>
so if layer thickness can go 0.08, decided to max out at .04
<InPhase>
That's probably a little excessive, but even if you do that, that maps to $fa = 2 for a 250mm diameter circle at 0.04mm target precision.
<InPhase>
Sometimes I do $fa=1 because it's slightly prettier on screen.
<InPhase>
The key thing is, the precision in question is not the arc length... It's the radial precision.
<church__>
from openscad manual i see that IF $fn=0, then choose ceiling from $fa or $fs segment count
<InPhase>
If you relied on $fs only, then you would be setting only the arc length. On that same 250mm diameter circle, using just $fs=0.04 gives you 19634954 segments around the circumference. Setting $fa of 1 gives you 360 segments around the circumference. And both give you an exactly identical print result.
<InPhase>
Sorry...
<InPhase>
Dropped my decimal point there making that look wilder.
<InPhase>
19635 segments around the circumference with $fs=0.04
<church__>
but 250mm diameter cylinder in just 360 segments - won't it show visible lines on sides? as segments will be few millimeters each?
<InPhase>
How can it when those segments are the same radius all the way across to within much better than your print resolution?
<InPhase>
How can you tell they are flat or rounded, if the printer cannot print a difference between flat and rounded at that radial precision?
<church__>
so in first case for 250mm diameter i have 39269 segments of 0.04 size, in second case i have 4.36mm segments. clearly showing out as many flat sides on such cylinder
<InPhase>
Except they cannot show out as flat sides...
<church__>
but mesh triangles are not curved? they are flat?
<InPhase>
You have to measure what "flat" means at that small of an angle.
<church__>
so if they are 4.36mm sized?
<InPhase>
Calculate how much flatter they are than perfectly rounded pieces would be.
<InPhase>
for 250mm diameter, $fa=1.0: (125mm)*(1-cos((1.0/2)*pi/180)) = 0.00476mm
<church__>
gonna wait for 2nd test run with $fa back to 0.01 to finish, then for interest/test sake will generate some cyl of 250mm with $fn=0 & $fa=1 and will see how it will look in slicer
<church__>
hmm, so these lines are only something that can be seen due how graphics/lightning rendered, but won't be discerned on actual print?
<InPhase>
What properly done lighting effect could make those segments darker on the left and brighter on the right all the way along? :)
<InPhase>
Real light doesn't do that. It goes by how each plane is angled.
mmu_man has joined #openscad
<InPhase>
You can try something more modest so it's less wasted filament, but try a more modest sized thin disk, and print them the two ways.
<church__>
no no, i certainly won't print that :)
<InPhase>
Get something closer to a few cents worth of filament and 15-30 minutes. :)
<InPhase>
It'll take less time to print then than your render times.
<church__>
so test run ended. with $fa=1 10min, with $fa=.01 it was 36min. it certainly increases segments to larger then $fs of .04 then. if by chance on few spheres in those twistanglelift modules on each very numerous step, possibly there
<church__>
hmm. with $fa, what are "rules of thumb" of setting it?
<InPhase>
My rule of thumb is "1 or 2"
<InPhase>
1 for slightly prettier on screen, 2 for slightly faster.
<church__>
min(360/$fa,r*2*PI/$fs) so i guess this works as: whichever segment count is smaller, be it by $fa, or by $fs. But as by "1" it's not discernable in real objects unless enormous size, then no need to limit $fa below that?
mmu_man has quit [Ping timeout: 252 seconds]
<church__>
InPhase: just for mental note, at which sizes $fa <1 may start make sense?
<J25k11>
church__ parts over 10cm
<J25k11>
$fa is a limiter to definition is via $fs and $fa just prevents that huge object become too detailed
<J25k11>
$fa of 1 results in $fn=360 for bigger parts which should be fine for most. But if you want a very smooth 20cm cylinder and you have a DLP printer .. you may see fragments
<church__>
parts .. or rather "radiuses >10cm"? and i wonder by what extents should i increase in such cases and if maybe i can set it autocalceable by having constant setting such max sizes
<church__>
err, decrease, not increase
<church__>
i prefer to make some copypasteable code that i can reuse in models. for example said quality/$fs calc that i can just change in customizer :)
<church__>
so thinking if single constant of max rad size in model from which $fa gets set later on, may make sense
<J25k11>
If you print part of a 100cm cylinder this may be needed - but else you are fine with $fa=1
<J25k11>
the resolution is done with $fs .. but if you have a lot of big objects your render will need more memory and takes more time and result in bigger files - so you limit the fragments for big objects
<church__>
but in such theoretical case of 100, certainly $fa doesn't need to be .01 like i had .. so $fa for such .5? .1?
<church__>
or some formula by what i should decide optimum $fa?
<J25k11>
very rarely you need a object with over 360 fragments so i would use explicit $fn for these objects
<J25k11>
$fa = 0.5 ↦ 360/0.5 = 720 fragments
<J25k11>
it just means no object can have more
<church__>
i'm thinking rather other way around. "if human seen/felt/discernible as non roundness flatness of segments side by side is of size X, and max rad size in model is Y, then $fa should be ..."
<J25k11>
if you make designs that other use via customizer - and they don't have fast computer with 32GB RAM .. use $fa=2
<J25k11>
church__ this is not the idea behind it - if you want something smooth you use $fs or $fn .. $fa just prevents your system from crashing
<J25k11>
think about you enter d=1000 by accident - without $fa limiting this would freeze your system
<church__>
if i reduce $fs size to smoothen .. at some point it will hit $fa limit as that code on openscad manual says, yeah. echo(n=($fn>0?($fn>=3?$fn:3):ceil(max(min(360/$fa,r*2*PI/$fs),5))),a_based=360/$fa,s_based=r*2*PI/$fs);
<church__>
previously, with $fa=.01 $fa will never limit me
<J25k11>
$fs of 0.5 will result in over 360 at a radius of 30.. but even a radius of 50 is fine with 360 fragments as the angle between is small.
<church__>
.. hence my questions regarding best practices & for when and by how much it changes :)
<J25k11>
and again if you have a beefy PC run with $fa=.01 .. just don't wonder if other people have problems with your settings
<J25k11>
church__ you should just print some stacked arcs with different $fn so you get a better understanding what number and size is what you want
<J25k11>
so having a fine resolution of $fs 0.1 (printing with a 0.2 nozzle) and making a cylinder with d=200
<J25k11>
result in 6.283 fragments .. if this is a dome or sphere you will get STL files with 100mb
<church__>
so with my previous approach i just decreased some mesh sizes past discernible in printed result, just increasing rendering perf hit/increasing times
<church__>
gonna keep this in mind for future
<J25k11>
Think about your print bed .. what fragment size do you need .. with 360 you are still under 2mm
<J25k11>
But if you have a curve with r=500 and you only print a section this may become visible. So ask yourself what size did your objects have.
<church__>
hence i'd wish just to enter at beginning max rad once, and forget about $fa :D
<J25k11>
try this sphere(1000,$fs=.1,$fa=.01);
<J25k11>
church__ maybe just use $fa=1 until you are experienced enough to understand the consequences, until then forget about it
mmu_man has joined #openscad
<church__>
aha, and from your sphere example i see that spheroidal curved objects multiply problem much more then eg. circles/cylinders
<church__>
even with same rad
<J25k11>
yes
<J25k11>
you can use something like $fa=$preview?10:1; and even bigger designs can be done and are rendered in fine detail
<church__>
mention of sectors in circles/cylinders/spheres popped up in my mind another question, how openscad renders and if discards objects
<church__>
as in in case of eg. two hulled spheres. after hulling .. do those not observable anymore inside sphere sides still put extra hit on rendering?
<church__>
is there sense of rendering performance boost to rotate extrude by 180 angle circle and fill in with linear extruded circle inbetween?
<J25k11>
after CSG generated the hull it will use those points .. if you change this the hull need to be recalculated else it is cached
<church__>
and CGAL?
<J25k11>
is the same CSG tree
<church__>
thanks for nfo
<J25k11>
using multiple operations ( linear extrude and rotate extrude) is often a bit slower. However calculating the polyhedron your self is often also slower
<J25k11>
using minkowski is often slower than hull
<church__>
hmm, interesting. i thought that polyhedron should be faster then eg. gaining same shape from combining eg. cubes and such
<church__>
due rendering from very beginning just what is needed exactly
<J25k11>
in the end you see the render time and can experiment yourself. There are also occasions like with the sphere example where the number says 0.9sec but it takes several seconds to display
<J25k11>
polyhedron are fast but the calculation internaly is faster than what you do in openSCAD
<J25k11>
if you make your own sphere() module it will not have the performance of the built in sphere()
<church__>
sphere seems a bit overexaggerated example :). but eg. to get some prism shape object .. better to combine/rotate/diff multiple cubes or just define points/faces in polyhedron?
<J25k11>
linear_extrude() shape; or use cylinder($fn=3);
<ali1234>
details of the object that were invisible in openscad are revealed in blender
<InPhase>
ali1234: Oh, that. Yeah, there was some PR content working on that.
<ali1234>
another alternative would be a reduced wireframe, where it only draws edges where the two meeting faces are not parallel and the difference exceeds some arbitrary angle
<ali1234>
that's the approach most othe cad software seems to take
<teepee>
well, this is bootstrapping a clean debian container too
<stealth_>
there you go, is there anyway to set it to use all the cores?
<teepee>
sure, but the server also hosts the download area, so I'm not going for shortest build time. there's no need for that, it's just building once a week an updated docker image
<stealth_>
i see, well you can also set it to use 50-75% of the process as well, just to get the task done sooner.
<teepee>
trigger is: "every-monday-at-3-am-utc" :-)
<teepee>
I'm usually asleep at that tima anyway
<teepee>
(4 am local time here currently)
<teepee>
well no *now* that 3 am trigger is
<stealth_>
whatever works for you. for me i would run it asap with all the cores so if there is a error i know about it vs waiting 5hrs later to find out.
<teepee>
we have that as github actions on checkin already
<teepee>
so minus some docker specific issues, that's covered
<Murr>
teepee: I'm surprised the image got there. It looks like the push in the original run failed. Did you re-run?
<Murr>
Ah yes, I see that you did.
syserrio has joined #openscad
<teepee>
Murr: yes, it failed due to the original push using image/image.tar
lastrodamo has quit [Quit: Leaving]
<syserrio>
I've been using OpenSCAD 2021.01 on MacOSX for a month. I was successful in using colorscad with it. I needed textmetrics feature in recent builds, so I'm running 2025.01.31 today. Lots of advancements! I see it renders 3mf in multi-color, but it's multi-color doesn't appear in Bambu Studio. Currently, I'm using colorscad's 3mf in Bambu
<syserrio>
Studio, but have to manual fiddle with the object colors. Has anyone had success printing a natively generated 3mf that contains multiple colors?
<teepee>
yes and no
<teepee>
colors as such are imposibe with current bambu studio
<teepee>
there is a hack in openscad "preferences->features->lazy union = on" that exports multiple objects
<teepee>
that might work in bambo, I know it works in prusaslicer
<syserrio>
teepee, thank you! I'll look into lazy union! I'm new to (modern) 3D printing apps, I was lucky to figure out how to tweak colorscad's object colors in Bambu Studio. I imagine most OpenSCAD users are after automation, me too. Thanks again!
<teepee>
sure, would be interesting if that works in bambu too
<teepee>
they did quite a number of things compared to prusa