<othx>
Jack21 linked to YouTube video "Firefox (1982) - Must Think in Russian" => 1 IRC mentions
<teepee>
oh, it's that easy? that would have helped a lot in school :)
ali1234 has quit [Ping timeout: 260 seconds]
ferdna has joined #openscad
ali1234 has joined #openscad
LordOfBikes has quit [Ping timeout: 260 seconds]
LordOfBikes has joined #openscad
<ali1234>
someone came to #blender with an interesting problem earlier. basically, cut holes in a spherical lampshade to produce a specific shadow shape on a wall, given the desired flat shadow shape as a 2D curve. turns out it is quite tricky to do. any ideas how you'd approach that in openscad?
<ali1234>
something with linear extrude scaling down to 0 i suppose
<ali1234>
(blender can't really cope with such complex booleans)
<ali1234>
render or preview? cos it previews okay for me, but if i try to difference the result from something i get non-manifold errors
<InPhase>
render.
<ali1234>
but only when rendering
<ali1234>
if this thing ever finishes rendering i'll make a simpler example
<InPhase>
Usually union with a stray cube is enough to trigger such errors. Can you testcase the difference which fails?
<InPhase>
Ok.
<InPhase>
I remember a recent issue discussion on this, but I am not confident I remember a resolution arising.
<InPhase>
scale=0 is definitely something theoretically fixable, unlike height=0.
<ali1234>
right. extrude height=0 is obviously bonkers anyway though :)
<LeviHarris-Brown>
the wiki suggests that fn shouldn't really go past 100? But when I render something at 100 it's still pretty rough instead of smooth? Is there any downside to setting it to e.g. 200, 250? Or is it only the time it takes?
<ali1234>
i mean it should be a no-op if anything
<InPhase>
Oh right. I remember there were complicated cases which were much more difficult like polygons with holes.
<ali1234>
ah i do have some of those
<InPhase>
peepsalot was involved in this discussion and pointed out the trouble with holes.
<ali1234>
text "O" for example
<ali1234>
that is probably why then
<InPhase>
A possible solution raised was adding a tiny layer just below the top to close the holes, but it's not clear if this can work for all cases.
<InPhase>
There might always exist pathological cases.
<ali1234>
yeah i completely forgot holes, that will be a big problem
<InPhase>
Topology is cruel sometimes. :)
<ali1234>
when you difference more than two objects, what order does it happen in?
<ali1234>
does it union everything after the first and then difference that? or does it difference everything in sequence?
<ali1234>
or maybe something else?
<InPhase>
I think it differences them one at a time.
<InPhase>
There's a for loop over children in applyOperator3D in cgalutils-applyops.cc that continually does a difference on all children, which I think is the thing doing it..
<ali1234>
could it be faster to union first then? if the first object is really simple, and then all the rest are really complex, but don't overlap?
<InPhase>
Probably it's less efficient to do that.
<InPhase>
You'd on average end up with a lot more faces to deal with.
<InPhase>
union first would be faster only in the edge case where one object trivially eats others that are complicated but first in the list.
<ali1234>
hmm okay
<InPhase>
In most cases union would make a giant combo beast that then has to be differenced.
<ali1234>
well i already have 5 of those
<InPhase>
And, you can always explicitly add the union when you know this should happen.
<ali1234>
i start with a sphere, difference one huge object, then i have to difference the next huge object aganst the result, which is now also huge
<ali1234>
repeat 4 times. where as unioning the 5 huge objects, then i have one difference with simple object + huge object
<InPhase>
If your positive object is much larger than the negatives, you might benefit from an explicit union. I guess that's the other edge case.
<ali1234>
nope, the positive object is smaller (see screenshot above)
<InPhase>
Keeping difference iteration as the default is still the better choice, because you cannot explicitly go the other way without really ugly code.
<InPhase>
Tossing in a single union is clean.
<ali1234>
as the default, sure. i mean for this specific case :)
<InPhase>
In the case of your screenshot I'm not sure if there's any real way to win on performance between these options.
<InPhase>
That looks like intrinsic computational load, with maybe small differences if you try to tweak it.
<ali1234>
yeah, it's a nightmare. blender can't handle it at all :)
<ali1234>
i crashed it like three times trying
<InPhase>
Hahah.
<InPhase>
Well I hope OpenSCAD can beat blender on this for pride points.
<ali1234>
it produces a result so that's a win in my book
<InPhase>
Excellent.
<ali1234>
blender either produced nonsense, or just took so long i had to kill it, or used all my ram and crashed the whole computer
<InPhase>
I don't know how many of these you're doing, but that definitely looks computable.
<ali1234>
er... just the one? but the difference SVGs will be more complex than this test
Jack21 has quit [Ping timeout: 256 seconds]
<ali1234>
but really the complexity of the positive sphere shell is what kills it
<ali1234>
it's reverse shadow projection. compute the geometry that produces the desired shadow.
<InPhase>
ali1234: In your final object are you putting an LED or something in the center of the sphere?
<ali1234>
yes
<InPhase>
ali1234: Then I guess you don't need scale=0
<ali1234>
nope
<InPhase>
That solves that. :)
<InPhase>
Did you figure out the inverse position problem? It shouldn't be too difficult, as OpenSCAD will do all the dirty work on that.
<ali1234>
not yet. i'm thinking more about how to structure the entire thing. like how to capture the room geometry in the first place
<ali1234>
since it isn't a cube
<ali1234>
having to manually measure the angle and distance of the perpendicular from the wall to the light will be annoying
<InPhase>
Well basically you just resize your surface to the target wall dimension, linear extrude with scale to the target distance for that display dimension, translate down by the same amount, and then rotate.
<ali1234>
but that's what it needs to calculate ultimately
<InPhase>
And well, center the surface before you start.
<InPhase>
It's like any projector in the end though. Move it farther away and it will just get bigger.
<ali1234>
yeah, it would work if you scaled the room proportionally. but if the room is a completel differen shape, it will not
<InPhase>
It's a right angled room, right?
<ali1234>
no
<InPhase>
Some sort of domed ceiling or something like a stellarium?
<ali1234>
it has 6 walls, but one is like 10 degrees away from being a cuboid
<ali1234>
the others are right angles
<ali1234>
from above, it's a right trapezoid :)
<InPhase>
If you're trying to project to walls not perpendicular to what you want, sheer is probably what you want. This is explained in the multmatrix part of the manual.
<ali1234>
i'm not though
<ali1234>
i mean i kind of am
<InPhase>
s/to what you want/to the source/
<ali1234>
but sheer isn't the way
<ali1234>
the way is translate the image so it's on the wall, then linear extrude it down to zero at the light source
<ali1234>
it's not supposed to look "right" when viewed from the side or anything like that
<ali1234>
it's supposed to be like projected wallpaper
<InPhase>
For straight out, yes.
<ali1234>
so the geometry on the shadow caster is sheered and warped, so that the shadow looks right head on
<ali1234>
this isn't even my problem btw, someone else raised it and i just thought it was interesting
<ali1234>
maybe i'll end up making something with it one day
ali1234 has quit [Remote host closed the connection]
ali1234 has joined #openscad
submariner has quit [Remote host closed the connection]
<InPhase>
ali1234: Perhaps you can sell them on the merits of OpenSCAD with a demo. :)
Jack21 has joined #openscad
othx has quit [Ping timeout: 260 seconds]
othx has joined #openscad
ali1234 has quit [Ping timeout: 260 seconds]
ali1234 has joined #openscad
ali1234 has quit [Remote host closed the connection]
ali1234 has joined #openscad
la1yv_a has quit [Read error: Connection reset by peer]
la1yv_a has joined #openscad
philip4g[m] has quit [Quit: You have been kicked for being idle]
<othx>
erickrdini linked to "Home Sweet Home Key Holder by joecity" on thingiverse => 1 IRC mentions
<teepee>
without the source file it's pretty much designing from scratch
<erickrdini>
understand
ur5us has joined #openscad
<InPhase>
erickrdini: And that would be much easier to do from scratch than to try to customize anyway.
<InPhase>
The essentials of that are super simple to make.
<erickrdini>
sure
<erickrdini>
any one got some project like that?
<erickrdini>
anyone*
<erickrdini>
any project!
<InPhase>
erickrdini: I mean like super simple. Here's the 5 minute version: https://bpa.st/U7PA
<erickrdini>
ok
<erickrdini>
lets see
<InPhase>
erickrdini: You'd want mounting holes yet, you can difference in some text, and really you probably want to take those hardcoded values and set them as parameters at the top to make it parametric.
<InPhase>
I went ahead and made the hooks a superior design slightly less likely to break.
<InPhase>
Right angles are your fracture points.
<erickrdini>
super
<InPhase>
When you do it yourself you have the liberty of making smarter choices like that. :)
<erickrdini>
i wanna put some test on it
<erickrdini>
text*
<erickrdini>
i gonna use doble stick face
<InPhase>
Text can be protruding, inset, or all the way through. Although if you go all the way through that will reveal your sticky tape. :)
<InPhase>
You could mitigate that by first solidly gluing some sort of backing black construction paper or something on the back after through-words
<erickrdini>
i gonna put on top
<InPhase>
Through words with a constrast color behind it would make the lettering stand out better.
<InPhase>
Words from 3D printing are made harder to see by the fact that we're mostly all saddled with single-color printers.
<InPhase>
Although you can configure your slicer with a z-stop, and make your hooks and letters a separate color to remedy that as well.
<InPhase>
I figured OpenSCAD moved on a lot since his initial OpenSCAD2 plan.
<teepee>
it's still a good guideline, even with Doug having decided to go his own way
<Jack21>
InPhase: what a creative way to make a hook an engineer would never thought of that solution
<InPhase>
Jack21: You mean exploiting the residual? ;)
<lf94>
InPhase: well in a sense yes and no: he ended up with a new language that's IMO better :)
<Jack21>
yes so the arc doesn't have a constant width and would be a pain to manufacture with a mill
<lf94>
InPhase: and uses shaders
<InPhase>
Jack21: Yeah. I've tried to train myself to look for the opportunities where the imperfections don't matter, like the uneven base width of that circle residual.
<teepee>
I don't agree with "better", different and probably worth having
<teepee>
better would be working more together, but that seems difficult to happen
<Jack21>
if small enough it is just someone would wonder if measuring the part - and .1 could change the number of walls in 3D-printing but in general this is a fast valid solution without using a lib
<lf94>
teepee: again, better *IMO*, for sure it's objective.
<lf94>
blaaaaaaah
<lf94>
I meant subjective!
<Jack21>
just watched the video on curv3D and nothing you couldn't make with scad but the performance seems to be better - probably because you just didn't see the mesh resolution due to the shader.
<teepee>
it's sdf based, so it does have different properties
<teepee>
basically openscad can do edges, curv can do curves :)
<Jack21>
Signed Distance Field ? SDF
<teepee>
not that this is anything new, ImplicitCAD is doing that for years
<teepee>
yes
<lf94>
Heh, it can do edges too. :)
erickrdini has quit [Quit: Client closed]
<Jack21>
well scad is not for demoparty - although could be a challenge
<othx>
Jack21 linked to YouTube video "Revision Online 2021 - Compo - PC Demo" => 1 IRC mentions
<Jack21>
getting tunes into scad could be a problem
<lf94>
Is ImplicitCAD using SDFs and shaders?
<lf94>
For sure this is just like Curv but a different language on top
<Jack21>
it seems SDF is not intended for making mechanical parts
<InPhase>
SDF will be faster for certain things, but not others. And the mechanical quality certainly gets compromised.
<InPhase>
I've spent a long time daydreaming about ways to try to merge these approaches, but this is a very challenging proposition.
<InPhase>
I really enjoy smooth designs, but my bread and butter is mechanically accurate parts.
GNUmoon has quit [Ping timeout: 276 seconds]
<lf94>
Not sure why you say that. You can be infinitely precise with SDF.
<lf94>
SDF is just a way of rendering - it can render anything which any other rendering model can do.
<peeps[zen]>
doh, erickrdini left. was gonna link him my cable organize design which could be adapted for that. had a couple distractions while getting my thingiverse account reset to find the link
<othx>
peeps[zen] linked to "Customizable Cable Organizer by thehans" on thingiverse => 1 IRC mentions
<InPhase>
Well when I lay out a round part that should have mechanical function, my extruder head might only be 0.4mm, but if there are 0.1mm deviations from roundness they end up as texturing in the output that produce friction and sticky spots. So yes, you can in principle calculate to any desired smoothness, but at what cost? SDF approaches tend to start slowing down again when you drive them to extremes of
<InPhase>
smoothness, because the algorithms typically don't let you do this for just one part of the design, but require that resolution then all over the whole thing.
<InPhase>
I can get extremely predictable vertex placement with an OpenSCAD approach, such that I can micromanage and count on it.
TheAssass1n is now known as TheAssassin
<InPhase>
peeps[zen]: Right, I forgot all about that thing, since it's not a key holder. :) Just, shaped about the same.
<InPhase>
Regardless, now I have a Christmas Key Holder for the advent calendar...
<Jack21>
i am sure erickrdini will be back soon
<InPhase>
Wait, my Christmas Key Holder is stupidly designed and won't print. I made the classic through-letter floating piece blunder.
<peeps[zen]>
InPhase: but how many Christmas keys do you have that need holding? :P
sinned6915 has joined #openscad
<InPhase>
peeps[zen]: I tell you I never understood key holders... But probably that's because I have pockets.
<InPhase>
Jack21: We tried to stick with CC0 so that they can be freely used as examples to rip from.
<Jack21>
i thought you talked about the peeps[zen] keyholder on thingiverse..
<InPhase>
The attribution licenses get in the way of examples, if people have to keep putting attributions every time they follow the examples.
<InPhase>
Oh, no, based on the example I showed erickrdini.
<Jack21>
oh yeah great .. only a few left to fill
<InPhase>
I still plan on working on that eye thing. I opened the file last night I just got tired before I got anywhere.
<Jack21>
btw: what was your meatball approach?
<InPhase>
Jack21: The first thing that came to mind. I planned on 30 minutes, spent an hour. https://bpa.st/QXZA
<InPhase>
Also we had just done the core funcutils work not long before that, so I grabbed a bunch of pieces from there as they were fresh in mind. :)
<InPhase>
The MeatballPts function with the random spherical coordinates is the meat of it. Then I fudged some function to make a surface based on distances from these spherical control points.
<Jack21>
you mixed an irregular cube into a sphere?
<InPhase>
It's not a cube, it's points generated within a cube.
<InPhase>
Then selected out based on a radial distance from the origin, so it's random points within a sphere, but less of them.
<Jack21>
and interpolated or how does it get smooth
<InPhase>
That's a classic algorithm for generating random values uniformly within a sphere.
<InPhase>
That's that dp calculation.
<Jack21>
if you get the lib out - would make nice snowballs for the scalender
<InPhase>
c*p is a dot production, and selects more strongly points in the same direction as the radial surface point being plotted. w is a weighting factor, 0 if the point is on the other side of the meatball, and doing a mathy thing to fine tune the meaty texture around these points.
<InPhase>
s/production/product/
<InPhase>
30 minutes of my 60 were spent fine tuning that dp value with different fudge factor approaches. :) It was trial and error of things that seemed right.
<Jack21>
that AxialFunc1 isn't used anywhere ?
<InPhase>
It's called internally by PlotAxialFunc
<InPhase>
This design predated function literals.
<Jack21>
ah i see
<Jack21>
i assume this could be used for landscape generation
<InPhase>
I can merge things and it drops down to 124 lines.
<InPhase>
Maybe that's sufficiently compact for a demo.
<Jack21>
maybe we should have a scad section "you wouldn't think this can be done with scad"
<InPhase>
Oh, and then I can throw in actually using a function literal. :)
<InPhase>
Yeah, I could integrate this.
<InPhase>
This makes use of a large number of function literals now, with several ripped from funcutils, and passing a function literal to be plotted.