<teepee>
I probably should have added some more tags on bluesky, probably not many people have seen the posts there
mtm has quit [Ping timeout: 248 seconds]
<teepee>
but then, I like Mastodon better anyway :)
mtm has joined #openscad
<teepee>
aha, door 24 is open. very nice
linext has quit [Quit: Client closed]
<InPhase>
Just in time. I just figured out the high level of the math that would have bent the needles properly. :) I was getting too sleepy last night to think about it further.
<InPhase>
It needed to be a torque-like pivot rotation, which all the numbers are there for.
<InPhase>
Next version!
<InPhase>
If anyone here is curious, the core rationale for using the affine transformation matrices in that model is that if all transformations are done by passing along an affine transformation matrix, and multmatrix applying it, rather than chaining together operations on the modules, you still get identical geometric behavior "as if" you chained along transformations of modules, but then you also get all of
<InPhase>
the coordinates of every element in numerical form, regardless of how complicated or convoluted the call chain path is to get there. And with those coordinates, you can add in other transformations that are NOT dependent upon the call chain (like the breeze here).
<InPhase>
i.e., elements know where they will end up, because the transformations that place them are not up the call stack, but instead, were passed down into them.
<InPhase>
There is a one-to-one mapping of transform / rotate operations with this approach. I copied and pasted those transformation and rotation vectors from my old 2019 tree model, and just passed them into the function versions instead.
<InPhase>
I am hopeful it works as a demo of this idea. I think it has much more general utility for many of those cases where people want to extract the numerical coordinates of things in a complicated process. Because this is one way that yields them, for the case of a module call stack.
<teepee>
that sounds very useful, I need to have a closer look once the family stuff is over in a couple of days
<teepee>
also, whew, we made it :)
<InPhase>
:)
<InPhase>
Every year so far!
<InPhase>
Tutorial elements was a meritorious idea in the end. I wasn't as sure about it when you proposed it, but it worked nicely I think.
<teepee>
I'm pretty sure I did not have enough ideas for the usual models
<InPhase>
It was good to vary up some of the content approaches. It keeps ideas from getting stale and going repetitive, and then more freshness will trickle in with time.
<teepee>
I also like the idea from J24k53 having one task and x different solutions/approaches
<teepee>
but I suspect that needs full preparation to work out
<InPhase>
And a particularly well chosen task or set of tasks. :)
<teepee>
right, that too, or the outcome might be very boring
<teepee>
I have another idea too, but that will need some research first
teepee_ has joined #openscad
califax has quit [Remote host closed the connection]
<J24k33>
InPhase - the interesting thing is that you will not see the changing colors when it rotates faster (at that fps) - somehow our brain can not match the images anymore
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 264 seconds]
teepee_ is now known as teepee
mmu_man has quit [Ping timeout: 260 seconds]
mmu_man has joined #openscad
aiyion1 has joined #openscad
aiyion has quit [Ping timeout: 264 seconds]
califax has quit [Remote host closed the connection]
califax has joined #openscad
mmu_man has quit [Ping timeout: 265 seconds]
<InPhase>
J24k33: Yeah, similarity matching is our prequisite to change recognition in a moving object. Otherwise it's just stuff blinking into and out of existence randomly.
<J24k33>
there is quite an nice effect if you rotate discs with pattern under strobe light (or computer render) as this will not have any motion blur - our brain is not trained for that and starts to create virtual sections to rotate on that disc
mmu_man has joined #openscad
<InPhase>
I also like the effect where an LED strand is spun quickly with a synchronized timing controller such that it can make a stationary pattern.
<J24k33>
hehe i made that as a kid .. putting LED (red/green) on AC and then spun the kable - so i got a circle with alternating red / green sections
<J24k33>
some years ago i made a clock with a laser on a rotating mirror - the laser was timed by a μC and so i got the 12 dots for the clock (two dots at 12)
<J24k33>
and a 3 moving dots for the hands
<J24k33>
Or if you use long exposure you can create text by moving an LED stripe with addressable LED .. some one visualized WLAN strength with that
<feep>
wiki says |vec| is just one particular kind of norm
<feep>
technically norm(vec) is undefined
mmu_man has joined #openscad
<feep>
cause like, which norm? euclidean? taxicab?
<Scopeuk>
the wiki defines norm (within openscad) as euclidean norm
<feep>
ah yeah then it's identical yeah
<meshugga>
is there a trig library for openscad where i can ask stuff like "i want to intersect the line defined by points A B to intersect with a plane defined by unit-vector P at coordinate Q"?
<meshugga>
specifically that problem would be interesting :)
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
snaked has quit [Remote host closed the connection]
hyperair has joined #openscad
mmu_man has quit [Ping timeout: 244 seconds]
<meshugga>
aaaah, bosl2 can do it. plane_from_normal()