<ccox>
the angle given in the parameters is a rotation, not a segment of the ellipse.
<ccox>
I think I can apply the circle logic, by using delta as a section of the ellipse more or less ($fn * 360 / delta)
<peepsalot>
ah, ok, but yeah it looks like delta is also already calculated, assuming that is the correct arc angle
<peepsalot>
the other big thing which caused me pause when I thought about implementing those, is that SVG has its own transforms. so to properly get the dimensions for fs etc, i think you need to track the transformation stack in some way.
<ccox>
yep, so it's not 100% correct because of the nested transforms (and the way the SVG code is currently parsed).
<ccox>
But is a definite improvement.
<Zauberfisch>
ccox: oh wow. that was indeed fast
<Zauberfisch>
looking through your merged PR right now
<ccox>
ok, got improved code for arc_to, testing it now (arc examples in SVG aren't that common)
<peepsalot>
curve_to could also estimate length numerically. quadratic curve could even calculate an angle which is swept over, but cubic i'm not so sure
<ccox>
and my arc changes look good (now follows circle logic)
<ccox>
yeah, sweep angle is kind of an odd parameter when you're talking about curves that can loop.
LordOfBikes has quit [Ping timeout: 252 seconds]
<ccox>
arc length or chord length might be a more useful measure, but the current code is based on parameter steps (not uniform in space).
LordOfBikes has joined #openscad
<ccox>
ok, rewriting the bezier curves to use chord length and try to use $fa correctly.... is a big can of worms. It can be done. But it is a lot of effort for minimal gain.
<teepee>
for more complex imports it might not be that minimal
<teepee>
especially if we would also allow to reduce the resolution compared to the previously fixed values
<ccox>
Possibly.
<ccox>
All of the SVG import code could use some improvement and refactoring. But it comes down to finding cases where the improvement justifies the effort.
ferdna has joined #openscad
<ccox>
Freetype rendering uses the size of the glyph to estimate $fn. Unfortunately the curves don't know the size of the shape they render, and are basically created as they're parsed. I could approximate that with the bounds of the curve, but then you still end up with odd segment lengths between curves.
<ccox>
knowing the size of the closed shape would require delaying poly generation in the SVG parser, which would need significant refactoring.
<ccox>
(note that the FreeType rendering could also be improved with chord/arc length rendering)
<teepee>
yes, there's even the idea to push the 2d stuff up even more
<teepee>
but that's a bigger topic again
<ccox>
yep
<teepee>
introducing those feature into the language and having the import essentially generate that
<teepee>
possibly adding the option to convert text/svg into that file making it fixed regardless of font changes and such
<ccox>
ok, that's yet another level of complication, but would eventually make the results more uniform.
<ccox>
(and I don't think I've really read the SVG specs since they were in draft form at Adobe 20 years ago... they really haven't gotten better with age.)
<Zauberfisch>
wonderful
<Zauberfisch>
I just built openscad from source, and $fn is indeed working now
<Zauberfisch>
thanks a lot ccox
<ccox>
Zauberfisch: you're welcome
<Zauberfisch>
might I request that you also update the docs?
<Zauberfisch>
then I'd be happy to pay out the bounty
<ccox>
I needed a project to take my mind off of Omnicron and peer reviews.
<Zauberfisch>
(docs and maybe the cheat-sheet)
<ccox>
And pay any bounty to the openscad "we need build machines" fund.
<Zauberfisch>
sure. Where can I find that fund?
<Zauberfisch>
All I can see is the general purpose open collective page
<ccox>
it is the general fund
<ccox>
(there were a lot of comments about needing funds for build systems yesterday)
<Zauberfisch>
sponsoring hardware is probably not interesting for security reasons, right?
<Zauberfisch>
as in, providing a server for free
<ccox>
I don't know, I'm still new here.
<teepee>
it was not really much about funds actually
<teepee>
more like stable access and such
<teepee>
the bigger problem is that the services change constantly and that's eating quite some time to follow along
<ccox>
man, the wikibooks documentation is way behind.
<teepee>
the money discussion was only the crazy suggestion from the CircleCI dashboard
<ccox>
ah, ok.
<InPhase>
teepee: Would it be easier or more terrifying if we had a CI VPS with full root or something available?
<ccox>
Is there any other "official" documentation I should update?
<Zauberfisch>
the idea I've come up with: extrude to 120, then greate a gigantic sphere to cut it with
<Zauberfisch>
(with cut I mean intersection)
Jack2181 has joined #openscad
<Zauberfisch>
is there an easier way, or is that the best way to do it?
Jack21 has quit [Ping timeout: 256 seconds]
<teepee>
in case it's really just a sphere, probably not much way to make it simpler
<teepee>
is it really just a circle in the svg?
<ccox>
there really isn't a simple way to extrude a circle and end up with a dome/lens shape in OpenSCAD
<teepee>
sure, rotate_extrude
<Zauberfisch>
teepee: well, it's a circle with details inside
<ccox>
that would work, but he said he's starting from a circle. And rotate_extrude needs at least half the profile cross section.
<teepee>
linear extrude with function height would be cool though
<Zauberfisch>
so yes, the outside is truely round
<teepee>
right, if there's inner structure, rotate extrude only works if things are cut in OpenSCAD later
<teepee>
we still have not tried if that is possible but in theory it should be possible to pass a function to built-ins
<teepee>
linear_extrude(h = function(x, y) ...)
<ccox>
a radius profile as a function of height -- hmmm, could be a special case of the sphere code.
<ccox>
I was thinking sphere (r = function(z)... )
<Zauberfisch>
ok, not a big deal. I'll just cut it with a sphere
<ccox>
though it's really closer to a cylinder in concept.
<Zauberfisch>
ok, yeah, I am creating a cylinder from an svg and cutting it with a shpere at the top
<Zauberfisch>
sorry if I explained that poorly
<ccox>
heights and radiuses defined by functions opens up a lot of possibilities. Easiest to start implementing would be height maps (aka surface which currently uses an image as input).
<ccox>
on the C side of things, there are many ways it could be done. But there are many questions to answer to choose the best approach: how complicated to add the code, how complicated to document and get people to use it, how flexible should it be?
<ccox>
I can see a possible use for several different approaches: height maps, lathed objects, deformed spheres, and general surface deformation (displacement maps) on arbitrary geometry.
<teepee>
that example code should allow to implement something like implicit_mesh(f = ...) taking a single implit function to describe the surface
<ccox>
an implicit function surfacer is an even more complicated issue (going back to voxel conversion issues) - mostly because you can have cusps, many distinct surfaces, etc.
<teepee>
so the mesh part is already there, the interesting part would be getting the scad function evaluation into that code, well and seeing how the performance is
<teepee>
it's already implemented in CGAL, not sure how good it is though, and what the limitations are
<ccox>
yeah, most implicit surface creation has problems somewhere - it is not an easy set of problems to solve. (nor easy to define what the optimal solution is in the first place)
<ccox>
but for defined Z heights, or radii, or normal offsets - those are *mostly* easy to define and manipulate.
<ccox>
(normal offsets can self intersect, depending on the geometry)
<ccox>
so I think the first step is being able to pass in a real function (not a list), then build geometry from that.
<ccox>
if that works reliably, then other styles can be implemented
<lf94>
Got it, all good!
ccox has quit [Ping timeout: 240 seconds]
ccox has joined #openscad
ferdna has quit [Quit: Leaving]
<Jack2181>
zauberfisch if i understand this right you could stack linear extrudes to make that
Jack2181 is now known as Jack21
<lf94>
I'm bummed Day 2 is not really printable lol
Xeha has quit [Ping timeout: 256 seconds]
Xeha has joined #openscad
ur5us has joined #openscad
<Jack21>
tried a 75% printable rate
ur5us has quit [Ping timeout: 252 seconds]
<Jack21>
forgot the instructions for the todays puzzle game :(
<Jack21>
well maybe they find out that it fit into a 3×3 box without the 4×1 cube
<Jack21>
well that also doesn't fit 27 cubes ..
<Jack21>
tetra cubes will never fill 27 .. but 16 may fill 64
othx has quit [Ping timeout: 252 seconds]
othx has joined #openscad
<Jack21>
added a TriCube for the puzzle ..
<Jack21>
This is more challenging than i thought - i think you can't build a 4×4×2 with only one Set
arebil has quit [Read error: Connection reset by peer]
<peepsalot>
Zauberfisch, what is the reason for going through SVG in the first place just to get a circle? why not just define the circle in openscad?
<Jack21>
iirc there was some inner structure on the inside
Guest726666 has joined #openscad
Guest726666 has quit [Client Quit]
<Scopeuk>
does the HID input code work with class compliant "multi axis controlers"
<Jack21>
it was working with a spacenavigator but not very smooth
<Scopeuk>
I should also caveat this is on windows. I'm aware that the hid input bind to those space nave devices
<Scopeuk>
I'm plotting building my own device
<Scopeuk>
thought I had a 6dof lying around but it looks like its only a 3 axis accelerometer, we shall see if I can get it to behave with that before progressing further
<Jack21>
you may want 10dof to compensate for drift
<Jack21>
there is one with a ARM chip that is already do that and give you a clean 6dof vector output .. iirc from bosch
<Scopeuk>
I'm well aware running 9 axis and compensating works well, I have my eye on a nice self contained board to do a wireless bluetooth le 6 axis system adding only a battery. drone style calibration is probably sufficient for short periods
<Scopeuk>
i.e. zero rotation to stationary gravity vector, lock that in and then use that to rotate and compensate gravity vector going forwards
<Scopeuk>
its not perfect but its a start
<Scopeuk>
at the moment I'm just playing with what I have lying around
la1yv_b has quit [Read error: Connection reset by peer]
<InPhase>
lf94: All you need to do for Day 2's is print with supports... and then leave them on. ;)
<Scopeuk>
tree supports could look pretty cool
la1yv_b has joined #openscad
<Scopeuk>
chance of it printing "properly" however :P
<Scopeuk>
Jack21 I've had similar results for rotation in open scad with a hacked in google day dream controller (but the controllers disappeared and I sort of lost interest)
<Jack21>
i would assume you could use the IMU in a smartphone for that
<Scopeuk>
I would think so
<Scopeuk>
the thought in my head was that I wanted to be able to manipulate the controller to manipulate the on screen item
<Scopeuk>
I never did get translation working quite right there was something odd about how the daydream remotes report acceleration
<Jack21>
there is a trackball that track 3 axis .. it is not for those things but i thing it would work like a charm with a switch button for rot and translation
<Jack21>
using shift with a normal track ball also works fine
<Jack21>
so since the advent calendar is closing all doors after reload - it is like a game of memory - Ü
<dTal>
oh geeze the last openscad advent calendar just feels like last week
<InPhase>
2020 was a separate life in a parallel universe.
<Scopeuk>
I've also considered building an old school encoder wheel board, I assume there is a reason that professional cad moved away from them towards the current 6dof mice but they still look cool
<Jack21>
before i found the alt arrow thing (and when it was working better) i was building an SCAD scroll knob with an 600 steps/turn optical decoder - running pretty smooth with the double ball bearings
<Jack21>
for the same reason - changing numbers
<Jack21>
(encoder)
lastrodamo has quit [Quit: Leaving]
jonasbits has quit [Ping timeout: 268 seconds]
ferdna has quit [Quit: Leaving]
TheAssassin has quit [Remote host closed the connection]
GNUmoon has quit [Ping timeout: 276 seconds]
TheAssassin has joined #openscad
jonasbits has joined #openscad
linext has joined #openscad
<Zauberfisch>
peepsalot: the outside is a circle, but it has details on the inside