sinvet has quit [Remote host closed the connection]
ccox_ has joined #openscad
ccox has quit [Ping timeout: 250 seconds]
ccox has joined #openscad
ccox_ has quit [Ping timeout: 256 seconds]
retrosenator has quit [Ping timeout: 248 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
KimK has joined #openscad
Guest48 has joined #openscad
Guest48 has quit [Client Quit]
Guest48 has joined #openscad
Guest48 has quit [Client Quit]
ricekot has joined #openscad
qeed_ has joined #openscad
qeed has quit [Ping timeout: 276 seconds]
rvt_ has joined #openscad
ur5us has joined #openscad
rvt_ has quit [Quit: rvt_]
rvt_ has joined #openscad
<dTal>
InPhase: >OpenSCAD can produce pretty much any shape computable
<dTal>
well I dunno if it's fair to say that "OpenSCAD" can produce any shape, if you're having to generate the points yourself and feed them into polyhedron()
<dTal>
and sure OpenSCAD is (I think?) Turing-complete so technically you can generate any computable points in it, but that doesn't make it a pleasant or expressive language for doing so, especially when you have to reimplement all the stuff OpenSCAD is supposed to provide (because once you feed points to an OpenSCAD builtin, you don't have points anymore but rather some opaque data structure)
rvt_ has quit [Quit: rvt_]
<dTal>
The logical endpoint of "you just need to write the right libraries" is to reimplement all of OpenSCAD in OpenSCAD, including hull() and minkowski() and all the other complex geometry functions
<dTal>
this is why people keep asking for access to computer geometry from inside OpenSCAD, it's a fatal defect
<dTal>
s/computer/computed
<dTal>
OpenSCAD functions do not compose with user-generated functions
<InPhase>
dTal: OpenSCAD is as Turing Complete as all the other languages confined to finite computing resources.
<dTal>
Is it?
<dTal>
There's a pretty big difference in finitude between "16 gigabytes of ram" and "can only loop a few thousand times"
retrosenator has quit [Read error: Connection reset by peer]
<dTal>
I've never tried to do non-trivial computation in OpenSCAD and I'm not sure how I'd go about it - it seems to be a language explicitly designed not to do that
<dTal>
the philosophy appears to be rather a declaritive scene description language that is intentionally hostile to state manipulation
<InPhase>
You can manipulate all the state you want.
<InPhase>
You just need to be explicit about what state you're manipulating in a routine.
<InPhase>
This is pretty standard for functional languages, that you need to pass state being modified along and return back the parts to be preserved.
<peepsalot>
dTal: if openscad is so unbearaable, then use something else... or try improving the source yourself. there's a reason most commercial CAD packages cost thousands of dollars and are developed by multi billion dollar companies. because CAD is hard.
<J2281>
there are just not so many you can sell it to .. but with "office" we still have this and there are some open alternatives - or blender which was made open source for 100 000€
<peepsalot>
and arguing over Turing completeness is meaningless academic faff for finite creatures such as humans. the whole "ignoring runtime and memory constraints" aspect is inherent in the question, such that all kinds of hopelessly impractical devices pass for it
retrosenator has quit [Ping timeout: 276 seconds]
<J2281>
isn't intelligence also to use the best tool suited for a job .. well even if you can use SCAD - it is probably not the best tool to create an AI.
<dTal>
peepsalot: it's not meaningless academic faff at all! I do in fact use something else, when I hit the limits of SCAD I turn to Python to generate points, in the same way that J2281 has reimplemented a bunch of geometry stuff in .scad
<dTal>
because when it comes time to implement an "offset shape" routine, it's incredibly easier in python
<dTal>
doubt we'll be seeing minkowski() or hull() implemented in SCAD anytime soon
<teepee>
and as I said maybe once a month already, the problem is more that the geometry engine lacks features not the language
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<InPhase>
dTal: What does your Python "offset shape" routine look like?
<dTal>
I think I posted it to this channel a while back
<InPhase>
Is it a 3D offset? I don't recall seeing one of those.
<dTal>
I have a function which approximately calculates the local derivative by newton's method
<dTal>
it doesn't deal well with points, it can't "inflate" a point into an arc like minkowski() can
<dTal>
I tend to do everything in parametric space when generating points myself
<dTal>
no, 2d only
<InPhase>
Oh. Well yeah, 2d offset is pretty easy. That's how we have one of those already. :)
<dTal>
this is the thing, you can't really compete with CGAL
<InPhase>
2D offset on a list of points would also be pretty easy to plunk into an OpenSCAD function.
<dTal>
Is there some fundamental reason why OpenSCAD can't access generated geometry?
<InPhase>
The only reason I didn't implement it is because I prefer to do my contours parametrically by things like function composition and boundary conditions instead.
<InPhase>
There are some challenges to it, but there's a PR up for doing this.
<InPhase>
It's the data = render() PR
<InPhase>
Some edge cases with variable scope could get a little wonky, and will need good testing and thought.
<J2281>
hmm WARNING: undefined operation (undefined + undefined) .. why is this not just "undefined" ?
KimK has joined #openscad
<teepee>
because it's some sort of "a + b" with both undefined
<J2281>
if everything is undefined - the result should be too .. Ü
<teepee>
e.g.: a = 0; echo(a + b); is "number + undefined"
<J2281>
yes a number + undefined is a problem
<J2281>
but if a is also undef .. why is that a problem
<teepee>
echo(a + b); gives that error and still does not make sense
<teepee>
sure, it *could* echo undef
<teepee>
as it did in old versions, but it's still more likely there's some issue with the code
<J2281>
i just have a vector2 but the function also works with v3 so without v.z it is now complaining
<J2281>
.. however why is offset 3D such a problem cant we just use the normal vector to add part of a sphere ?
<peepsalot>
how do you tessellate the sphere surface to match up with an arbitrary number of edges / dihedrals?
<peepsalot>
J2281: also vertices don't have a (well-defined) normal vector
<J2281>
the normal would be used from the faces - and if the vertex connects 3 faces a segment of a sphere should work (probably not if more than 3 faces connect on a vertex)
<InPhase>
J2281: peepsalot and I had some debates (discussions?) on what to do with undefineds. I endorse the warnings, because usually operations on undefineds mean that you screwed up your code, and it gets REALLY hard to track it down in complex code without a warning at the first instance close to where it first goes wrong.
<InPhase>
J2281: People who intentionally want to parse undefined as "ignore" can code that up. But most of the time it's just mistakes.
<J2281>
hmm yeah i was lazy and thought i could get away by just adding undef Ü
<InPhase>
J2281: As for offset, we all immediately picture the cube which is easy. But now try to do a vertex with a series of faces which are convex.
<InPhase>
Make the worst case of a figure C coming to a vertex.
<InPhase>
Do you do the average of face normals? What if the inside of the C has 5 times the faces of the outside?
<InPhase>
It's a vertex so no face is "bigger" in length. Do you weight by the angles traced out by the face edges?
<peepsalot>
yeah lots of CAD operations are pretty trivial if you only consider 90 degree axis aligned boxes
<InPhase>
It's possible, but that's a lot more to compute for the vertices when you have smoothed features.
<J2281>
we extending every face in direction of the normal .. so a gap will form on every convex edge .. this is filled with a cylinder segment and a sphere where edges meet
<InPhase>
I'm also not sure that weighting by the angles solves the scope of problems. It might at least do a point expansion okay for a majority of cases. Smoothed expansion in a spherical manner though is the most desired, and that gets a lot more complicated with the C like vertex shapes.
<InPhase>
I can probably construct some example objects where a simple point expansion makes some shapes become self-intersecting where they were not before offset.
<InPhase>
I would have to think for a bit, but it seems like you could construct some contorted monstrosities which would self-intersect. And if it's possible to do by trying hard at it, then someone is going to do it by accident on some small features hiding in the tiny parts of some object, and get a mysteriously non-manifold result.
<J2281>
the concave points need to connect - like in 2D , maybe this is a problem in 3D
<InPhase>
3D contortions are the key place where it gets tricky.
<InPhase>
Yes, now expand the vertices of those people outward. ;)
<J2281>
people are donuts
<InPhase>
That's how you get a kidney in your brain.
<J2281>
i mean minkowski gets unusable when dealing with concave geometry too
<J2281>
maybe other mesh software remeshes the whole geometry
<J2281>
in 2D vertices get deleted in expanding concave sections
<J2281>
so for 3D we can not work with vertices but with faces
lastrodamo has quit [Quit: Leaving]
Virindi has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Virindi has joined #openscad
<peepsalot>
InPhase: i think the best conceptual simplification for 3D offset is convex_decomposition -> offset -> union, this should avoid any self intersections, but then its back to possibly very slow unions. also it doesn't address the sphere tesselation issue
<peepsalot>
i would really love to see convex_decomposition as a builtin operation, but that raises complications of how to iterate over multiple "returned" geometries
<peepsalot>
ie would it have to be a "data = render()"-only type of operation, or require modules as first class objects, etc.