<Claws61821>
I'm having an odd issue with `linear_extrude()`. I used a vector as a module parameter to feed a for-loop for a `difference()` at 90* angles with a complex `polygon`. It works properly when 2D, but as soon as I extrude, iterations for [0] and any multiple of [4] fail to cut.
<peeps[zen]>
Claws61821: can you pastebin an example of the problem?
<Claws61821>
I tried changing to 45* on a whim just now and it changed to effecting multiples of [8] instead of [4]. Oddly enough, changing a different for-loop to 45* fixes this issue, at the expense of the other feature; but changing the incremental value of that feature breaks this one again.
<Claws61821>
I did try setting a few different convexity values for the extrude, to no effect.
LordOfBikes has joined #openscad
<peeps[zen]>
Claws61821: seems like an issue of having you positive and negative objects sharing coincident edges. usually its best to have the negative object extend past the bounds of the positive one even just a little bit, so that floating point inaccuracies don't mess with the result
<peeps[zen]>
otherwise the it can't always tell if those faces are part of the geometry or not
Guest41 has quit [Ping timeout: 256 seconds]
<Claws61821>
peeps[zen]: I think I have an idea of what to change for that, then. Thank you.
<peeps[zen]>
no problem :)
<Claws61821>
That was the issue. Thank you. (Delay was due a phone call)
ferdna has joined #openscad
<Claws61821>
Do parameters need to be defined in each level of a module tree, or only in the top level or the target child?
<InPhase>
Jack21: The Eyes attempt is failing so far. Every algorithm I tested is either too wildly unstable, too monotonous, or too computationally intensive in a declarative language.
<InPhase>
If I could store state between animation frames this would be pretty easy.
<peeps[zen]>
a variable in the top level can be accessed anywhere within the same file. a variable within a module is only accessible within that block
<peeps[zen]>
then there's "special" variables denoted by leading '$' character, which have dynamic scope (they get passed down the call chain)
<InPhase>
Jack21: I got a lot of crazy eyes and terrified eyes along the way. :) But nothing expressive or emotive coming out of the dynamics because of the difficulties of modeling persistence. I'll sleep on it for a day to a few days and see what some fresh thought brings.
<peeps[zen]>
Claws61821: ^^
rawgreaze has joined #openscad
rawgreaze has joined #openscad
rawgreaze has quit [Changing host]
<Claws61821>
peeps[zen]: I thought it was something like that but when I set the parameters only in the top-level module, the target-child returns "unknown variable". Do I need to define a variable to match the parameter? I made this work a few times before but I never remember how.
<peeps[zen]>
Claws61821: when i say top-level i mean outside of any module
<Claws61821>
As it turns out, yes, you *do* have to define a variable inside the first module to hold the parameter for its children...
<peeps[zen]>
i'm not sure i understand your meaning
<Claws61821>
Module parameters, arguments, whatever you want to call them on any given day, the things that you put inside the parentheses when you call the module
<peeps[zen]>
are you defining modules within modules?
<Claws61821>
both defining and calling, yes. I do it to keep things organized instead of an endless stream of unmanageable tiers of code.
<peeps[zen]>
ok, i still don't see what your issue is though. what does "hold the parameter for its children" mean? this defines a parameter which is accessible to its children, and doesn't require a variable definition also within the top module https://bpa.st/QSTQ
<Claws61821>
Except that never works for me when I write it that way. It always fails to pass the parameter to the child modules unless I define the parameter for both or all modules AND define a variable with a different name as equal to the value of the parameter.
<peeps[zen]>
without an example of what is failing, i can't help much further
Jack2168 has joined #openscad
ferdna has quit [Quit: Leaving]
Jack21 has quit [Ping timeout: 256 seconds]
<Claws61821>
peeps[zen]: Here is the version that returns "unknown variable", with explanatory comment. https://pastebin.com/eYX5rSDW
<peeps[zen]>
Claws61821: well, VRailProfile is not defined within VRailVitamins
<peeps[zen]>
if you want to propagate values down the call chain, then you need to use special variables. replace "Slots" with "$Slots" in your first example
<Claws61821>
No, but it is *called* within Vitamins, which the manual says makes the backend treat Profile as a child of Vitamins. That being the case, the entry on Variable Scopes suggests that defining and calling the parameter in Vitamins *should* pass the parameter along without it being a variable; but it doesn't, regardless of whether the parameter is still defined in Profiles as well.
<peeps[zen]>
what is part of the scope explanation implies that?
ur5us has quit [Ping timeout: 268 seconds]
<InPhase>
Claws61821: It definitely doesn't, but if you look back at the manual and can point out a part of the manual that's confusing on this point, maybe we can fix that part up.
<InPhase>
peeps[zen]: Totally unrelated, just that I happened to check that section of the manual just now... Do you think we should purge this partial sentence? "Because OpenSCAD calculates its variable values at compile-time, not run-time"? When I use rands to pick a random function literal to call to generate a value to assign to a value, I'm pretty sure we shouldn't be calling that compile time. :)
<InPhase>
s/assign to a value/assign to a variable/
<InPhase>
I guess one could in the past argue there's a perspective of compile time generating the tree, but I think the language has grown past that.
<peeps[zen]>
status messages in console still refer to compiling steps fwiw
<InPhase>
I think this is not at all analogous to constexpr. Instead I'd say we have a full compute phase of runtime, and compile time should be reserved for the period that gives us syntax errors and produces things in value.h that get evaluated.
<InPhase>
And with x = render() getting thrown into the mix, that's even more reason to stop calling that compile time. :)
<InPhase>
If we accept that, and we probably should in at least some form, then going forward the runtime phases are getting interleaved in a tree-like manner.
<peeps[zen]>
i don't know, semantics around compilers/interpreters/whatever we have is not really my forte
<peeps[zen]>
InPhase: if its not compile time then what do we call it?
<peeps[zen]>
is there a PR for x = render() yet?
<peeps[zen]>
i'm still wary of whether we will be able to keep .csg format and caching all functioning the same when those types of changes involving multi phases like that
<peeps[zen]>
that's maybe more of an issue with the whole proposal to accept functions as module params
<InPhase>
I had planned on going over that during Thanksgiving break, but then I started cleaning up the house a bit, and the break came and went. :)
<InPhase>
And I think we should probably call them the compilation phase, the compute phase, and the geometry phase.
<InPhase>
x = render() then simply runs a geometry phase interleaved with the compute phase.
<InPhase>
The CSG tree still gets output at the end of the compute phase as it always did, but it's just that some of the values in it were calculated by an interleaved geometry phase calculation.
<InPhase>
I poked him about that when he was first developing it, since I knew you would be very concerned about the CSG trees. :)
noonien has quit [*.net *.split]
ubitux has quit [*.net *.split]
Polsaker| has quit [*.net *.split]
redlizard has quit [*.net *.split]
siege has quit [*.net *.split]
Alexer has quit [*.net *.split]
dalias has quit [*.net *.split]
dalias has joined #openscad
Alexer- has joined #openscad
redlizard has joined #openscad
Polsaker has joined #openscad
siege has joined #openscad
ubitux has joined #openscad
Xeha has quit [*.net *.split]
buZz has quit [*.net *.split]
clemens3 has quit [*.net *.split]
buZz has joined #openscad
buZz is now known as Guest859
Xeha has joined #openscad
clemens3 has joined #openscad
Claws61821 has left #openscad [#openscad]
PovilasCNC has joined #openscad
GNUmoon has quit [Ping timeout: 276 seconds]
ochafik has joined #openscad
ochafik has quit [Ping timeout: 256 seconds]
Guest41 has joined #openscad
Guest41 has quit [Client Quit]
Guest38 has joined #openscad
Guest38 has quit [Client Quit]
<peeps[zen]>
should i not be?
teepee has quit [Remote host closed the connection]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
teepee has joined #openscad
GNUmoon has joined #openscad
Jack2168 is now known as Jack21
ur5us has joined #openscad
mhroncok has joined #openscad
ur5us has quit [Ping timeout: 256 seconds]
Colt has quit [Quit: Leaving]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Ping timeout: 256 seconds]
Colt has joined #openscad
af is now known as he
Guest859 is now known as buZz
ochafik has joined #openscad
sauce has quit [Read error: Connection reset by peer]
sauce has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
he is now known as af
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
<teepee>
convexity is not *both* front and back sides
ochafik has quit [Remote host closed the connection]
<ali1234>
front and back vs inside and outside
<Jack21>
register how many times a ray would cross like entering or exiting
<ali1234>
the image is more informative than the text there iirc
<teepee>
yes, the question is, is the image showing a convexity of 2 or 4
<teepee>
I had a look some time ago as there were conflicting infos and concluded it's 2
<teepee>
now someone is changing it to 4
<Jack21>
2
<ali1234>
i'm pretty sure i've asked literally that question myself
<ali1234>
and i'm still not 100% sure what the answer is
<Jack21>
i mean think about what would be a convexity of 3
<ali1234>
good point
<ali1234>
it would mean non-manifold geometry
<teepee>
aha, OpenCSG website is clearer " The convexity of a primitive is the maximum number of front (or back) faces of the primitive at a single position. For example, the convexity of a sphere is one and the convexity of a torus is two."
<teepee>
so revert it is :)
<ali1234>
well the examples are clear but i don't understand that explanation
<ali1234>
have can you have multiple faces at a single position?
<ali1234>
"or" is doing a lot of work there right? it means exclusive or
<Jack21>
take two points inside the geometry and how many times you would enter or exit the shape to connect them
<ali1234>
that would give a sphere convexity 0
ochafik has joined #openscad
<teepee>
not a position, the ray from eye pointing through the position on the object I think
<ali1234>
yeah i think it is the maximum number of front faces that a ray can intersect
<ali1234>
the "(or back)" is just confusing
<ali1234>
it is saying "you can flip any ray around" not "you count front and back faces" (you don't)
<Jack21>
if it is not the inside the "back" is also a front
<ali1234>
no, because however you enter a sphere, you leave through a face facing the other way
<teepee>
yep, exactly
<teepee>
and there's no other way ignoring a tangent
<Jack21>
from eye ↦ arbitrary point inside — how often you penetrate the surface
<ali1234>
yes but for the torus that can also give the wrong answer (depends what point inside you pick)
ochafik has quit [Ping timeout: 264 seconds]
<Jack21>
now in those cases a convexity of one would not cause errors
<ali1234>
right given a fixed eye point
<Jack21>
if i view a gear it looks fine from above but at an certain angle i need convexity 3-5 .. same for fonts
ochafik has joined #openscad
<ali1234>
yes, that is expected. the idea is you set convexity high enough for any eye point
<Jack21>
did anyone know hat the colors in libera.chat mean ?
<ali1234>
and that "high enough" value is what we're talking about
<Jack21>
if the standard value would be 2 you would reduce problems by over 80%
<ali1234>
yeah i've suggested this before :)
<Jack21>
in rotate_extrude it is 2
<ali1234>
re irc colours, that's most likely your client. there's no colour here and you rarely see it on libera
<Jack21>
using the web front end .. and had one color all the time .. and now i got a different one
<Jack21>
the only change was that i got a different nick in the beginning
<Jack21>
just was curious…
<ali1234>
right nick colouring is usually pseudo-random based on hashing the nick, so it is stable but evenly distributed colours
<ali1234>
it is done by the client
<Jack21>
if they used the IP (location) would give you a hint about the timezone
<ali1234>
yes but it would also leak information
<ali1234>
since there's only 2^32 IPs
<ali1234>
you can't hide it with a hash cos i can trivially build a table
<Jack21>
ip v6 .. i think it would also cause a more monochromatic discussion
<ali1234>
how about "convexity is the maximum number of overlapping front faces when the object is viewed from any angle"?
<Jack21>
overlapping is the wrong term .. it is more like stacked or overlapping in a projection
<ali1234>
overlapping as in overlapping the same pixel in the 2d projection, yes
<Jack21>
(while in a projection they are removed so this is also wrong)
<Jack21>
if the object would be glas with mirrored surfaces .. ah no doesn't work
<ali1234>
well this isn't ray tracing... that's part of the reason why convexity is even needed
<ali1234>
convexity is actually "the maximum number of depth tests made against any single pixel when rasterizing the object"
<Jack21>
yes sounds good - probably doesn't help most people to understand it - Ü
<Jack21>
"how many surfaces can be behind each other"
<Jack21>
and only the face with a normal towards you are counted
<InPhase>
teepee: "Just setting high numbers in general may result in slower preview rendering" was removed. What should go in its place is a note that setting very high numbers can result in slower navigation in the preview display. People should be informed of this so they don't go slapping 100 on things and then wonder aimlessly about why they can't spin their designs around with the mouse.
<InPhase>
The most practical bits of information are "bigger numbers are more accurate with overlapping faces but slower to navigate". The rest is explanatory detail.
<ali1234>
how does the convexity value actually end up getting used?
<ali1234>
does it bucket sort the faces or something?
* JakeSays
slaps 100 on all the things!
<InPhase>
:)
<ali1234>
i do that sometimes when i am in a hurry
<JakeSays>
lol
<teepee>
InPhase: I thought it's still in there
<teepee>
well, the wording is not ideal... "Setting it to 10 should work fine for most cases. Just setting high numbers in general may result in slower preview rendering."
<JakeSays>
what are you guys talking about?
<ali1234>
convexity, what it means, and how to explain it to users
<InPhase>
teepee: That's inadequate phrasing. Also, convexity is described in MANY places in different ways each time. Perhaps we should invest in some of those wiki links and describe it correctly in one location.
<ali1234>
+1
<InPhase>
It looks like that convexity image is in like half a dozen different places too.
<ali1234>
btb it's also really ugly
<InPhase>
lol. That too.
<teepee>
yeah, very true
<InPhase>
If it were in one location and not ~6 it would be easier to update. :)
<teepee>
I just wanted to first reject the change that I think was explaining it wrong :)
<InPhase>
Each location describing convexity should just link to a convexity section, instead of suggesting values at each place.
<InPhase>
If it's not front AND back, then the image is wrong. But once that is centralized this could be addressed.
<ali1234>
the image isn't wrong, it's just that you only count two of the intersections, depending on the direction of the ray (which is not indicated)
<InPhase>
The polygon section explicitly states that the convexity image has a convexity of 4 with 2 front and 2 back crossings. I don't know if that's correct or not.
<InPhase>
Hence the problem of spreading this all out.
<ali1234>
if there's a single reference section, it can have multiple explanations aimed at different levels of technicality
<InPhase>
Someone could probably invest in an actual 2D shape made with some sort of fancy program like OpenSCAD to demonstrate 2D convexity.
<ali1234>
the ray explanation, the rasterization explanation etc
<InPhase>
Perhaps a linear extrusion of a 2D shape with a very small linear extrusion so that it's easy to see, and is already 3D.
<InPhase>
You could also use the zoom-in icon, because it also makes the picture bigger.
<InPhase>
I'm going to say yes, use the zoom-in instead of info.
<ali1234>
yes
<InPhase>
My first mental thought is "that's tiny I want it bigger".
<ali1234>
me too, exactly
<InPhase>
So you could also make the zoom-in icon about 70% bigger?
<teepee>
zoom or search
<InPhase>
Zoom-in
<InPhase>
Search makes me think I'd look for something else, but what I really want is to see the thing I just clicked on better because I have interest in it. Then my interest will lead me to the download button and I will have learned intuitively that this is where download is. :)
<teepee>
current size is 24
<InPhase>
40 maybe.
<InPhase>
I can hit 24 but I'm very dextrous and not using a phone or tablet.
<teepee>
that is huge
<teepee>
I can hit 24 on ipad fine :P
<teepee>
well, on phone it's probably not much use anyway
<ali1234>
hmm yeah 40 is too big. it's about right for the big door
<InPhase>
Jack21: Nice. That with the word labels could be our new convexity image.
<Jack21>
i think we should put the calender (2019,2020,2021...) also in the gallery section - it seemed to me they are not linked anywhere on the website
<teepee>
ah, good point
<teepee>
I always wanted to add an extra page with some sort of word-cloud pointing to the scripts
<teepee>
sort of "howto"
<teepee>
but so far that always dropped off the list
<Jack21>
could be documentation but in gallery we have only one menue item on the left - so this also would fill things and the scripts are not always that explanatory written
<Jack21>
teepee: are you planning to integrate a 3mf viewer (https://threejs.org/) ?
<teepee>
hmm, I did not think about that yet
<Jack21>
was asking because of coloring the 3mf files - but in hindsight i think they should be as they came out of scad
<teepee>
you mean you would hand color them somehow?
ur5us has joined #openscad
EkpyroticFrood has quit [Quit: So long, and thanks for all the fish.]
EkpyroticFrood has joined #openscad
siege has quit [Remote host closed the connection]
siege has joined #openscad
<peeps[zen]>
here is my proposed example for convexity, including a random ray which requires maximum convexity for the object: https://bpa.st/7V5A
ali1234 has quit [Ping timeout: 265 seconds]
<peeps[zen]>
you can set convexity to 2 or 1 and move the camera around to see how it affects when camera rays pass through the object x>convexity times
<peeps[zen]>
my description would be "convexity is the maximum number of times an arbitrary camera ray can pass through the object"
<peeps[zen]>
sort of off the cuff, s/pass through/intersect/
<peeps[zen]>
and i agree the example image on the wiki is atrocious
<peeps[zen]>
which is why i made that example a while ago... just hadn't replaced it on the wiki. also having a single linked wiki page for convexity would be much easier to maintain as I also noticed it explained differently on different pages
<peeps[zen]>
i thought there was an open issue about it, but can't find it now, i am thinking it was some other issue which got hijacked into convexity discussion
<InPhase>
peeps[zen]: Hmm. convexity=2 is not doing the convexity=2 things for me on that design, but it's mysterious as to why.
<InPhase>
Removing cube(7); also fixes convexity=1
<InPhase>
The example might just mystify them more if it's not consistently logical.
<peeps[zen]>
yes, it only matters if the object is involved in a difference or intersection
<peeps[zen]>
InPhase: you have to position the camera such that rays will pass through that many times to test lower convexities
<peeps[zen]>
for usage on the wiki I would make that image a top down "2D" view just like the existing one. but here is a sample of convexity=2 to show that it is not enough https://imgur.com/a/gTFpQjW
ali1234 has joined #openscad
<ali1234>
found it - it's caused by the extra title element in the grid
<peeps[zen]>
if the object is not involved in intersection or difference, then the standard depth buffer tests are enough
<ali1234>
oh my previous messages never came through
<InPhase>
peeps[zen]: Interesting. It fails from the back but not from the front. I expected the three prongs of the extruded polygon to fail looking through them from the other side, which it does with convexity=1 but not convexity=2.
<InPhase>
peeps[zen]: There is something hard to predict going on internally, such that the failures are possible but not guaranteed. :)
<ali1234>
okay so how do i do a pull request on a private repo that isn't mine?
<InPhase>
ali1234: For the calendar stuff we've just been pushing.
<ali1234>
i see :)
<InPhase>
ali1234: Small group, not public yet, and trusted set of people.
<InPhase>
Just try not to screw everything up, and don't force push. ;)
<ali1234>
well i could push to a branch and make a PR
<ali1234>
didn't realise you gave me push access
<InPhase>
You can PR to a branch if you want something reviewed that you're uncertain about.
<ali1234>
i'd rather that than causing merge conflicts and whatnot
<ali1234>
this css grid is new to me but i think the fix i've made is correct (it involved deleting what i think is an old, unused element from the html)
<peeps[zen]>
InPhase: it fails on the "third" ray intersection for convexity=2, makes sense to me *shrug*. the correct convexity is not hard to predict IMO, you just may have to wiggle the camera a bit to notice effects for cases where it is set too low
<peeps[zen]>
btw i am suggesting that example just as a source script for a top-down image, not necessarily to include the scad example on wiki as well (but we could if it is considered helpful)
<peeps[zen]>
InPhase: the intersection bit is more just to prove to myself and others that it is in fact how convexity works though (its not meaningful in a top down image)
<InPhase>
peeps[zen]: I extended the two points to alter the face shading, and it still doesn't bleed through.
<InPhase>
Which upon reflection (hah) would improve the merit of this as an example.
<InPhase>
Perhaps altering the relative angles a little more would be even better.
<peeps[zen]>
InPhase: strange, I tried to reproduce your image but I see artifacts unlike yours https://imgur.com/a/SoNeV8R
<InPhase>
peeps[zen]: I thought that might be what's happening. Some difference in video drivers or something.
<peeps[zen]>
yeah possibly
<InPhase>
So we should definitely rig up the failing testcase images instead of sharing the code. ;)
<InPhase>
And maybe note in the description that actual results can vary by details of the platform.
<teepee>
ali1234: thanks, uploaded to the test page
<peeps[zen]>
InPhase: if you "force goldfeather" does it introduce artifacts?
<peeps[zen]>
also fwiw i'm testing on nightly for ubuntu 20.04, with nvidia gpu
<InPhase>
That does not change it.
<InPhase>
Oh...
<InPhase>
But using my latest master branch compile does...
<InPhase>
I was using the release build.
<InPhase>
Weird.
<InPhase>
Yep. Master branch with or without goldfeather introduces artifacts.
<ali1234>
teepee: hmm this makes the image behind the doors be the same shape as the doors which i didn't intend, but i was going to propose as i think it looks better (i cleaned up those properties in order to make this easier to play with)
<InPhase>
Now your turn to try 2021.01 :)
<peeps[zen]>
hrm, yeah i don't see them with 2021.01. probably something about the VBO changes (still seemed reproducable for me with VBO either on or off)
<teepee>
ali1234: looks good to me, I suppose I'll just declare Safari broken without any hope ;-)
<ali1234>
unfortunately i don't have a mac to test, i did find a stack exchange question that might be the answer though
<InPhase>
peeps[zen]: Well your changes at least fail better according to the specs, so not really a regression.
<peeps[zen]>
VBO wasn't me :P
<InPhase>
Oh.
<InPhase>
Well, someone's then.
<InPhase>
I only talk about those changes with you so it's incorrectly implanted in my mind as yours...
GNUmoon has quit [Ping timeout: 276 seconds]
<peeps[zen]>
no prob, it was obliviand iirc
<Jack21>
teepee: yes hand coloring (until scad writes the face color into the 3mf)
<InPhase>
Jack21: Yours shows artifacts from the jagged side for both 2021.01 and the master branch, yet interestingly the artifacts are slightly different. 2021.01 does not bleed through the top surface, but the master branch does.
<InPhase>
(For me at least.)
EkpyroticFrood has quit [*.net *.split]
ur5us has quit [*.net *.split]
ochafik has quit [*.net *.split]
sauce has quit [*.net *.split]
Xeha has quit [*.net *.split]
Joel has quit [*.net *.split]
pie__ has quit [*.net *.split]
Zauberfisch_ has quit [*.net *.split]
ToAruShiroiNeko has quit [*.net *.split]
johnstein_ has quit [*.net *.split]
af has quit [*.net *.split]
markasoftware has quit [*.net *.split]
rogeliodh has quit [*.net *.split]
ndnihil has quit [*.net *.split]
SamantazFox has quit [*.net *.split]
castawayc has quit [*.net *.split]
ali1234 has quit [*.net *.split]
mhroncok has quit [*.net *.split]
JakeSays has quit [*.net *.split]
Ekho has quit [*.net *.split]
Fleck has quit [*.net *.split]
little_blossom has quit [*.net *.split]
Taneb has quit [*.net *.split]
gbruno has quit [*.net *.split]
hisacro has quit [*.net *.split]
dTal has quit [*.net *.split]
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
EkpyroticFrood has joined #openscad
ali1234 has joined #openscad
ochafik has joined #openscad
ur5us has joined #openscad
Zauberfisch_ has joined #openscad
Joel has joined #openscad
mhroncok has joined #openscad
pie__ has joined #openscad
Xeha has joined #openscad
sauce has joined #openscad
johnstein_ has joined #openscad
ToAruShiroiNeko has joined #openscad
af has joined #openscad
markasoftware has joined #openscad
rogeliodh has joined #openscad
JakeSays has joined #openscad
Ekho has joined #openscad
ndnihil has joined #openscad
Fleck has joined #openscad
SamantazFox has joined #openscad
little_blossom has joined #openscad
dTal has joined #openscad
castawayc has joined #openscad
hisacro has joined #openscad
gbruno has joined #openscad
Taneb has joined #openscad
Colt has quit [Remote host closed the connection]
Colt has joined #openscad
<teepee>
ok, now loading the designs from a json file, anything else we need?
<Jack21>
publicity
<teepee>
well, that we do once it's finished :)
<teepee>
but yeah, I'll change the banner on the homepage again, and we can post at least on the mailing list, reddit and thingiverse
<Jack21>
think we are still some designs short .. having 2 more in my pipeline (mind)
<teepee>
I want to grab 2 from that twitter feed
<teepee>
got a nice response to my email
<teepee>
simple but nice math
<teepee>
if we end up with more designs, we can always stash them already for next year :D
<Jack21>
can we also borrow some from next year? - Ü
<ali1234>
the image behind door 1 doesn't work any more
<ccox>
(nice to know I'm not the only one running behind on creating/getting christmas gifts)
<ali1234>
also you've hardcoded a js file under the demo site
<teepee>
yeah, I need to push the updated index file
<ali1234>
ah yes it works locally
<ali1234>
i have another css fix tweaking the info icon
<ali1234>
fix the alignment, and i assume the background should have been removed with the border?
<ali1234>
hmm the images don't work on firefox
GNUmoon has joined #openscad
<ali1234>
door 1 is trying to show img 3
<ali1234>
hmm i'm not sure what is going on here
<ali1234>
ah i see, chrome is caching something
<ali1234>
yeah, there we go
<teepee>
quick reload :)
<ali1234>
now it's 403
<ali1234>
and now it works
<teepee>
I'm leaving the folder blocked by default, that will happen later too, just need to update the cron job, so no client hacks :)
<teepee>
ok, reload now
<teepee>
all those scripts look awesome, very cool
<teepee>
only 4 to go, with 3 on their way already
<teepee>
and the snowballs need an image
<teepee>
ali1234: did you reload the page? I'll close the access again an get something to eat
<ali1234>
yes
<teepee>
yeah, I have to hard code the link as the webpage goes via github pages and the files are on the file server
<teepee>
I guess redirecting the pages to the file server would work too, but then it would be 'files.openscad.org' as domain
<InPhase>
teepee: So we're full up on 24 designs?
ur5us has quit [Ping timeout: 264 seconds]
<InPhase>
My eyes attempt was a fail. Nothing popped into mind to fix it yet. Perhaps if I let it percolate for another year. :)
<teepee>
almost full, just 1 missing
<teepee>
well, at least I understood those 2 from twitter are ok as CC0, I'll check again, but that sounded ok in the mail
ochafik has quit [Remote host closed the connection]
<InPhase>
I could still do that exploding wobbly cube idea bridging off of Jack21's wobbly rectangles if Jack21 wants to share the source for that. :)
<Jack21>
which what?
<InPhase>
Jack21: You had 3 wobbly rectangles with shifting color hues.
<teepee>
InPhase: I'm not going to stop you, animations are extra cool now with the much bigger detail window
<InPhase>
If the scad file is compact enough I'd love to morph that one into a slightly different sort of entry that transitions between that and a rotating cube.
<InPhase>
It looks like it would be compact, and I think you got the wave patterns and color patterns basically perfect already, so it's a great starting point.
<Jack21>
found two files .. first works without lib
<InPhase>
Excellent.
<InPhase>
47 lines, or probably like 90 with some whitespace. ;)
<Jack21>
first is the one you showed in the gif link
<InPhase>
teepee: We still need to write an auto-formatter for Jack21's code. To make space for his cleverness he does not use spaces. But we can fix that part with some auto-processing. :)
<Jack21>
kachel seems to be the size of each tile .. while "frei" should be space between them
<Jack21>
increasing "frei" may contribute to some explosion effect
<Jack21>
.oO i am using so much space in the last scripts my space key is getting smooth
<InPhase>
Yep, this structure looks easy to work with. And it animates faster than I thought it would.
<Jack21>
made that 2018
<InPhase>
Just need to figure out a few of these German words...
<Jack21>
i wish i would use more comments
<InPhase>
I forgot most of the German I ever knew sometime around 1994.
<Jack21>
as i said "frei" should be the space
<Jack21>
and kachel means tile and probably the size
<InPhase>
I'll probably Englishify them for the calendar code.
<Jack21>
wert means value .. ( you can be happy that i used existing words)
<InPhase>
kachel... stove? Heat maybe?
<Jack21>
it is called kachelofen because the stove is sourounded by tiles
<Jack21>
oh actually Kachel is the resolution
<Jack21>
inverse , it is the size of the tiles but determine also number of tiles
<Jack21>
i wouldn't write it that way today - Ü
<teepee>
pff, don't give in to those native english speaking people, they just assume everyone else does that too :P
<teepee>
which is not totally wrong though ;-)
<Jack21>
i suck in german (written) too - so languages are not my strong side
<Jack21>
like a little boy told me once - math is so easy everything is logical, but language you have to learn and memorize everything as it doesn't make sense
<teepee>
yeah, there's one or two exceptions in german
<teepee>
and I never really got to understand russian, which is a bit sad, but that's how it goes
<teepee>
I'm working with a couple of people from Romania, they seem to be all language geniuses (if that's a word)
<teepee>
pretty much all speak very good german but they all also speak english aswell
<Jack21>
if your mother tongue is english - german looks like a nightmare but you haven't heard of russian
<Jack21>
what i told ya .. but the grid isn't getting bigger
<Jack21>
just fitting less tiles
<InPhase>
Yep.
<InPhase>
Okay, this will definitely work. I'll refactor out the redundancy and add the extra animation after dinner. It's nicely parameterized already, so this shouldn't take too long. :)
<Jack21>
maybe use $fn=4 instead of 3 to make it more symmetrical (and turn each cylinder by 45°)