califax has quit [Remote host closed the connection]
califax has joined #openscad
J23k95 has joined #openscad
J23k3 has quit [Ping timeout: 245 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
ur5us has quit [Ping timeout: 250 seconds]
<InPhase>
peepsalot: I have only white and black PETG at present, but it really is a nice filament. I stockpiled a ton of PLA before I knew about PETG (or maybe before it was available, not sure).
<InPhase>
What I really want more colors of is TPU. I feel like I should be using it for more things, because it has such wonderful properties.
<InPhase>
It's not general purpose, but it has so many other purposes.
ur5us has joined #openscad
mmu_man has quit [Ping timeout: 264 seconds]
califax has quit [Remote host closed the connection]
<peepsalot>
i still haven't really messed with TPU. seen/handled a few prints by others, but never had a use case where I felt like I needed it I guess
fling has quit [Remote host closed the connection]
J23k95 has quit [Quit: Client closed]
J23 has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
fling has joined #openscad
hyperair has quit [Remote host closed the connection]
hyperair has joined #openscad
ur5us has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
ur5us has joined #openscad
cbmuser has quit [Ping timeout: 248 seconds]
use-value has quit [Quit: use-value]
pah is now known as pa
e2k has joined #openscad
<Church->
InPhase: i want to attach various parts to wall of nozzle, which is formed by segments of known height and known radius-es, X & Y offsets of top and bottom of that segment. So this simplified model in pastebin imho should represent "close enough" with all the rest of stuff, that doesn't matter to particular aligning/rotating task
<Church->
s/with all/without all/
<Church->
i can find needed offset to translate where needed to side of wall .. but stumbled upon calculation all the rotations right to fit to (sloped) wall of this (simulated) nozzle segment
foul_owl has quit [Ping timeout: 268 seconds]
cbmuser has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
<Church->
btw, completely non-important (as i didn't got any real performance gains with going non-minkowski), but it still slightly bugs me, https://pastebin.com/tKDa4vwq - why if i use module with minkowsky, preview works fine, but if similar module, but one that reaches same result using hull around, then by rendering time it seems that render() is used to force CGAL over CSG :/
<Church->
i rewrote to non-minkowski due all mentions how bad it is and shouldn't be used, but probably minkowski wasn't that slow due simplicistic shape it has to work on .. just that why forced render in rewritten one when i see no valid reasons for that :/
<J23>
you can make a minkowsi with 3 objects (cube, cylinder, sphere) else i would make a 2D hull of circles and extrude this.
rawgreaze has quit [Ping timeout: 240 seconds]
<InPhase>
Church-: With respect to the "simplified model", I suspect you are in an "xy problem" situation: https://xyproblem.info/
<InPhase>
Church-: But the solution is not available because we have abstract code about preserving the orientation of a yellow piece in an unclear orientation under unclear ranges of operations. When probably the real problem is to make some parameterized shape for which this is not actually the ideal solution approach.
Notkea has left #openscad [#openscad]
<Church->
InPhase: well .. to me it seems, that rewriting whole other fanduct code is not exactly option (especially when i absolutely have no clue in what direction i should rewrite, except obvious taking lot of wished other adjustment features out to make it dumb cylinder or rectangle cross section with straight vertical walls, or at most skewed in single plane. no more gradual sin-ed dimension change depending on inlet/outlet shapes & sizes, no more angling/skew
<Church->
ing/offsetting)
<Church->
nah, i just will give up, and leave manual adjustment slider in customizer. ones that will need to add parts to side, may spend few secs adjusting it manual. of course slight remore due "giving up" .. but wasted way too many days on trying make this work :(
<Church->
s/remore/remorse/
<Church->
IIRC there were some external openscad libs that helped aligning part, but using them probably will make model not thingiverse customizer compatible?
<Church->
(IIRC it was something about sweep functions or alike named)
mmu_man has joined #openscad
teepee_ has joined #openscad
<Church->
J23: can you take a look in pastebin above? one uses minkowski with circle around rectangle, other one hull around hull around for 0.001 high cylinders. And no clue why if non-minkowski one used, on each change in code (and on file opening) acts like as if i'd F6 instead of F5, IIRC as if render() had been used in that module ..
<Church->
damn. i haven't been in irc for way too long time .. too used in forums/discord, where i can edit submitted message if noticed typos later on :(
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
<J23>
church that paste uses cylinder not circles?
<Church->
well, minkowski one uses cylinders too
<InPhase>
Church-: I opened the minkowski code, but it does not run as shown. You did not include most of the values needed to illustrate it.
<InPhase>
Church-: It's easier to help on problems if the code examples run.
<J23>
2D↦ 3D is faster
<InPhase>
Church-: This helps with seeing the issue directly, and with making adjustments to fix the problem.
<Church->
but also you may ignore this :) .. this particular issue seems very unimportant .. just slightly bothering why it renders by time seemingly as if using CGAL over CSG, when i see no reasons to
<buZz>
typically if you need minkowski etc on 3D shapes, you'd likely get same results faster with 2D shapes and offset()
<Church->
minkowski in that roundedSquare was originally .. i just started with https://www.thingiverse.com/thing:1055536 and added lot of "bells & whistles", like extra nozzle shape adjustments/fan size auto calc, extra fanduct parts etc
<Church->
obviously with learning lot of things in process (first experience with openscad in general)
rawgreaze has joined #openscad
<buZz>
the sourcecode did give that impression ;)
<buZz>
btw a square is 2D , did you mean a cube?
<Church->
yes, cube (sorry, got used to freely for self interchanging squares/rectangles with cubes and circles with cylinders, simply according warnings of mixing 2d vs 3d and alike :D )
<Church->
cube/cylinder of .001 height seems "close enough" to me to 2d counterparts :)
<Church->
it's not really an issue, and just slight curiosity.
<Church->
pitty i couldn't make code to autoalign other parts to fanduct wall though :(
<J23>
if you run this with higher fn it will start to matter .. but the walls are curved so what do you want to align there
<Church->
low fn is just for speed of rendering. my thought of line was - quickly get sizes/transformations of duct as wished .. and "end it by using 'fining' slider in Quality tab to wished higher fining (and also more seqment count), as it multiplies not just $fn in code"
<buZz>
Church-: you could make it autoaligning if you had variables describing it :)
<Church->
aligning = rotating to wished angles & translating in place. i fail in getting right rotations calculated, thus thought of maybe trying in simpler code, as in here .. https://pastebin.com/eNg8MgXk
<Church->
which "mostly" works, but changing offsets ask for another rotation, which adapted rotation code from elsewhere didn't do
<Church->
my own math/trigonometry knowledge is "0", long since forgotten from school many decades ago, so i'm limited to adapting other people code, if i find "close enough" code that does similar things :)
rawgreaze has quit [Ping timeout: 264 seconds]
rawgreaze has joined #openscad
snaked has quit [Remote host closed the connection]
<buZz>
> Het boek Moderne Wiskunde, dat doorgaans veel wordt gebruikt in het voortgezet onderwijs, gebruikt sinds 2015 de term solcaltoa in plaats van soscastoa.
<J23>
in german it would be SGH CAH TGA .. no wonder this is not used
<buZz>
yeah german is indeed not used
<buZz>
:D
<Church->
buzz: some changes i did when "adapting others code" were done in a bit more stupid way :) .. like +/-, cos or sin .. and looking on result on preview :D
<buZz>
Church-: yeah, iterative design
<buZz>
its -a- method , i wouldnt call it programming ;)
<Church->
yes. and i know it's stupid approach :D
<buZz>
but, welcome to openscad :)
<J23>
it is not stupid if it works .. and try'n error is kind of a learning process
<J23>
but don't use 45° and try to figure out if it is cos or sin
<Church->
but try 'n error aproach fails if there are many variables, as too many possible combinations, thus it's too long for non very basic stuff vs knowing and doing right stuff.
<buZz>
split any daunting task into endless small bits
<J23>
i think there are different level and after some time you got a feeling for what is right or might work even without understanding it .. or after a while you use magic number like sqrt(2) and forget about why this is working
<buZz>
:) 'why does rendering take an hour'
<J23>
i remember my first designs of wavy knots that took 2 days to render
<J23>
using a lot of spheres (not hull or polyhedrons) .. make it smooth just use more spheres
<Church->
you guys actually waited that long for result? i know myself, that if something doesn't render in .. eg. half an hour, i'd kill it and think how to simplify/quicken
<buZz>
Church-: oh, sure, if need be and proven to finish
<buZz>
but indeed its usually a sign of 'you're doing this wrong'
<J23>
scad uses only one CPU core .. so still can use the others
<Church->
just that it seems PITA to wait 2 days even when you don't know yet if it will finish at all :D
<J23>
oh you have no idea how image rendering was in the beginning of raytracing in autocad or 3dmax .. you easy waited a week for a short animation to render
<Church->
(one of reasons why i added to my model adjustable in customizer "fining", so to get things done almost immediate while i code to see preview/result, while still retaining simple way to increase quality for final render)
<J23>
as you see in my example of your duct - it renders under a second even with fine detail
<Church->
mine offers big pile of alternative transformations though .. various rotations/offsettings/skewings/different outlet shapes/widening of base and so on .. i went a bit overboard probably with possible transformations, LOL
<J23>
the difference is to calculate a polyhedron - had nothing to do with the transformations you apply
<Church->
liked "sine" gradual change between outlet/inlet of various dimensions, but also liked in other found model that added those offsets/rotations .. thus started to add stuff to one from another
<Church->
well, even if i increased fining to 8, my model calculated in IIRC 8min, so don't feel yet need to change something completely
<J23>
and things like going from 2D to 3D increases speed as this step is done for each level. Also using extrude with scale in a hull reduces the triangles by 2 as even a h=.0001 cylinder have a top and bottom that leaves points.
<J23>
see 8minutes - i would not accept such long wait today .. however using manifold will probably reduce this time drastically
<J23>
but that is all in the process of learning
<Church->
at very beginning i thought to just quickly mash up something fitting just for me .. bet when found that there are nice ways to make things autocalc, and nice ways to present adjustable constants in customizer, gradually wanted to make something more univeral/useful to others :)
<Church->
s/univeral/universal/
<J23>
if you check how others do it will save you some time .. the gallery and advent calendar is a great place for this
<Church->
during my road of just starting using openscad there still seem many cases that could have been made easier. way too many cases where i saw posts/cries about not being able to do some things "simple in other cad-s", when googled "how to do X in openscad" to find code samples
<Church->
chamfering/rounding, and yes, attaching separately designed modules/parts to other ones aswell. there were external libs to ease several aspects, but i feel it would be helpful many bits from those libs to have in "base" openscad.
<J23>
some are like "roof" which allows chamfering but need to be activated as it is experimental
castaway_ has quit [Ping timeout: 240 seconds]
<Church->
or .. at least "single THE place" to go to, where people might share various functions/modules/snippets for more & easier code reuse. feeling that in some cases in openscad there happens much more bicycle reinvention then might have been.
<buZz>
well CSG isnt new :)
LordOfBikes has quit [Ping timeout: 240 seconds]
<Church->
btw, any advises from you guys, what fn on what radiuses / what segment heights/widths to aim for smoother surfaces in actual 3d print (to also not go overboard with segment count/size just increasing rendering time with no change on printed result)?
guso78 has joined #openscad
<J23>
use $fs instead
<J23>
that is why it exist .. and $fs =nozzle/2 works fine
<J23>
use $fa=1 as an upper limiter for bigger radii
<Church->
J23: that is for round surfaces. but for flatter or just sloped/angled ones? eg. in my case - where there is specific count of segments per specific length .. i wonder how many layers/segments to aim .. also nozzle/2 for eg. segment height?
<J23>
$fs is the segment size in all dimensions .. so you aim for a mesh that has $fs big triangles
<J23>
if you have height of 10mm fn = height/$fs so layer = $fs
<Church->
hmm .. original code had just nozzle lenght / specific number for numSegment and preset $fn .. i added multipliers to those .. but hmm .. gonna try to change it to $fs then
LordOfBikes has joined #openscad
<J23>
the problem with your code is that each edge is doubled https://imgur.com/a/Mup8OeK so you have twice the segments without any improvement in resolution
<Church->
well, i guess it's that way with original aswell. i mostly worked to add adjustments/features onto what was there initially.
<J23>
it is simply if you hull 3D objects just make sure there is a single edge .. so use cones cylinder (.1, r1=10,r2=0);
<Church->
btw, in your suggested way of extruding 2d for performance sake .. will it offer as many ways to alter/skew/twist?
castaway has joined #openscad
<Church->
adding "bells and whistles" on top of original https://www.thingiverse.com/thing:1055536 it seemed relatively simple. divide wished extra action by numSegments and apply portion of action to each segment. even such complete dumbass & newbie as me could add that offsetting/rotation/twisting and so on ..
<J23>
sure it is the same base
<Church->
also i wonder why there are double edges formed, as technically top of previous segment should be 1:1 in dimensions/position as bottom of next one. maybe due those smidges to counter z infighting? :/
<Church->
LOL, due unreadable code of mine serving as base it will take time to spot changes :D
<J23>
your segments are (simplified) a hull of two cylinders .. if the top cylinder is smaller you will have the height of the bottom cylinder - causing 3 slices .. if you use two cones you only have 2 slices
<J23>
the change is only in your rounded square which is the base shape for your hull segment
<Church->
interesting. gonna compare rendering times at higher fining numbers
<J23>
and using offset (r) instead of the minkowski with a circle would be better
<Church->
btw, is my aproach very bad/wrong, when first thing i do in most code i start working with, removing lot of formatting .. "to fit more lines in page" .. i find it much easier to understand/oversee/code, when i see more of it in one place ..
<Church->
wanted to readd formatting and such only at very end/finish of work on model
<Church->
scrolling far forth and back to see various related code bits of "properly formatted code" subjectively to me seems harder :/
<Church->
having some module or sequence of short transformations spreading half the page makes it maybe easier to change just one bit, but in some cases, less overseeable vs longer "oneliners"
<Church->
btw, speaking about modifiers .. is there a way to switch/enable them via customizer controls NOT via duplicating code with various modifiers added?
<Church->
(duplicating, and "if"-ing choice according inputs on customizer)
<J23>
modifier are only for development so they should not remain in the customizer
<J23>
* disables things so this already can be done with if
<Church->
but if i'd wish to temporarily make % transparent some part, not via editing code?
<J23>
highlight with #/ can be done with color ([rgba])
<Church->
yes, used colors sometimes too, also useful
<J23>
color uses alpha for transparency
<J23>
% is not just making it transparent it removes it from the calculation
<Church->
oh, right. i mistaken % & # regarding if it's there in final render
<J23>
which can cause weird results when used in a difference
<Church->
btw, for cable clip like this https://grabcad.com/library/cable-clip-4 - what would be render-quick way to chamfer similar shape? It seemed simple to have outer ends, or straight cuts .. but wondering what to do with rounded inner cut .. maybe difference with twist rotated/extruded polygon of shape of chamfering cut? or should minkowski be used as otherwise things get overcomplified too much for such small part?
<Church->
Also i wonder if it can be printable well, googled that part shouldn't be more then 45deg angle from vertical to not need supports, also not sure on reasonable minimum thickness that is still strong enough and not with lot of printing errors, in dependence on nozzle thickness ..
<Church->
sometimes thinking that minkowski is way too easy to use in code .. but it's performance hit often might be greatly alleviated, if one could better place limits on area it works on ..
<J23>
print vertical (cable axis)
use-value has joined #openscad
<J23>
you can use linear extrusion with twist
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
<Church->
hmm .. print vertical probably won't be an option, if these were one of parts (alongside eg. go-pro-ish mounts) that i wanted to add to side of fanduct :D
<Church->
as probably fanbase itself will be at floor, due nozzle walls mostly being vertical
<Church->
hmm. gbruno is some github changes announce bot? why it repeats same thing that often? :/
<teepee>
synchronize pull request means more changes are added to an existing PR
<teepee>
mr. bruno could use a bit more event filtering but it's probably not too easy
guso78 has quit [Ping timeout: 245 seconds]
<teepee>
with "not easy" == needs persistent state to actually work instead of just forwarding github events
<Church->
much simpler to add max frequency/interval between announces imho
<teepee>
but also wrong
<teepee>
I really would not want to miss an important thing because there were 5 non important before
<Church->
yes. easily imagine ways how .. eg. pooling too many changes to announce at once, or not announcing something "non-latest"
<teepee>
what we could do is moving it to another channel
<Church->
nah, it's not THAT annoying ..
<Church->
just seemingly it just repeated same change all over again, hence thought if it might have been glitched
<teepee>
well, if I ever find the time, I'd like to get our good old other bot back, and maybe we could add the feature there
<teepee>
this one has persistence anyway
<Church->
oh, right! simplest ever change. - if announce is of same textual content as one before, to not print it?
<teepee>
yeah, same with "edit PR" - if someone clicks update multiple times, it does publish all the changes
<Church->
i sometimes wonder, why there is only if else condition & for as loop in openscad. are there any gains to not have "case", and eg. while / until?
<teepee>
not 100% sure, but my guess is those are not really viable without mutating variables which is not supported right now
<Church->
hmm .. ok, for loops .. but isn't "case" just many if else but stringed together in MUCH more readable & compact manner?
<J23>
you would need to build recursive modules for it
<J23>
and if(var="label1") .. is not so much worse than ```case label1:```
<Church->
in common syntax, case just on top, with just subsequent "value: {}"-es below, no?
<J23>
your code formatting is worse than mine and that is something
<Church->
as i told, i wanted to left "beautifying" to very end, but while work in progress, keep things relatively compact :D
<J23>
but you can write a module that switches childs which would be very compact when used
<teepee>
a switch statement would make a lot of sense, nested ? : is quite annoying for multiple reasons
<J23>
yeah nested conditionals are hard to keep in nice formatting
<Church->
oh, right. and i'd really love to be able to have to specify newline in comments for customizer other way then just adding lot of spaces :/
<J23>
if your customizer has more than 10 variables - you can be sure nobody will use it
<Church->
that's why i organised in tabs
<J23>
10 total!
<Church->
making model that can be adjusted only by editing code, or making many models with just part of adjustments doesn't sound to me as better choice, when i wanted to make "universal one"
<J23>
people don't need so many settings - and the customizer is nothing you can use as library
<InPhase>
Church-: I see the "full fanduct code" you posted. What are those little colored rectangular solid bits even supposed to be doing on this model? As in what is their final purpose for the design?
<J23>
most people want 10 stl to download and not a customizer at all .. and people who can "scad" don't want a customizer but modules and libraries
<Church->
inPhase: those are test "parts" i tried to align to fanduct, prior reverting to "simpler model" :)
<Church->
inPhase: later one, when/if i get aligning code right, i thought to add way to simpler add some partX (eg. mentioned cable clips or specific side mounts) at nozzle sidewall at eg. 20,30,80% on specified side of nozzle
<Church->
with letting code deal with aligning that part to wall
* teepee
goes looking of Qt6 supports markdown natively
<teepee>
I would not say that. using sections to group things, it can be ok
<teepee>
but yes, just a huge list would be difficult to use
<teepee>
looks like there's some sort of markdown support - that's promising
<teepee>
that would also help with integrated documentation
teepee has quit [Quit: bye...]
teepee has joined #openscad
<Church->
inPhase: so those bits are only to show me if i adjusted them "wrong", and they eg. sink or separate from wall, if i adjust nozzle dimensions/transformations
<Church->
using visualised temporary debug helper parts help if using "trial 'n error" method :D