<Scopeuk>
That is very email like. That being said I'll take slightly over formal email semantics in irc over rambling nearly inteligable nonsense
<Scopeuk>
My understanding is it is more than a little late for gsoc this year however
ferdna has quit [Quit: Leaving]
arahael has quit [Ping timeout: 255 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
<teepee>
indeed, reading the main GSoC website should have given some clues how it works. I understand there may be lots of open questions. Asking the most general "how does it work" is a very red blinking warning light
<teepee>
and yes, next week is basically the last week of the normal project timeline and we talked yesterday about wrapping things up so we have a neat status at the final checkpoint
<teepee>
recursion hits again... packaging the package manager :-)
fancsali has joined #openscad
fancsali has quit [Quit: Client closed]
<Scopeuk>
If only we had a package manager manager, maybe next year :p
<InPhase>
teepee: That step probably requires a Windows VM just to test it. Or a non-dev Windows user without python installed willing to give it a try.
<teepee>
WSL2
<teepee>
and snap for Linux
<InPhase>
Hmm. Alright.
<teepee>
well snap for Linux and WSL :-)
<teepee>
for those who don't want to touch python directly
<teepee>
not sure what other simple options there are, but one step at a time
<InPhase>
It's been years since I even touched WSL. Will this result in files adequately accessible and interoperable with the OpenSCAD binary?
<teepee>
I have not tried, but WSL2 can actually run the OpenSCAD gui application, we tried that last week in our GSoC call
<InPhase>
So we can abandon building for Windows? :)
<teepee>
no idea, is WSL2 installed by default?
fling has quit [Remote host closed the connection]
fling has joined #openscad
<teepee>
snap seems to have added RiscV, so just everyone buy one of those
<InPhase>
Hmm. You tested on what gpu?
<buZz>
is WSL ported to linux yet? :D
<InPhase>
Apparently there are issues with WSL2 and AMD cards.
<teepee>
buZz: yes, it's called Ubuntu :P
<InPhase>
Which is a pretty big gaping hole.
<teepee>
strange. but then, the package manager is command line anyway :)
<InPhase>
Yeah. I was just pondering the more extreme question of using the Linux build of OpenSCAD. :)
<buZz>
teepee: hehehehe
<teepee>
I suppose it's just a matter of trying. "issue with AMD" does not mean it overlaps with the relatively old/minor feature set of GPU stuff OpenSCAD uses
<teepee>
aww, latest code not yet checked in
<InPhase>
teepee: Yeah, specifics were not plentiful in the random posts, but something to do with no working passthrough, and thus bad performance. But OpenSCAD's needs are not too wild. Hard to know without trying it.
<InPhase>
I was checking to see if the calculation bits would be performant, and it seems so. But then I spotted that complaint in many locations.
Guest87 has joined #openscad
<Guest87>
Has this project ever humored the idea of a "subtraction" feature? I find myself unable to make a function that says "take this mesh and remove it from everything". Yes, difference() exists but it is very specific.
<InPhase>
What in your mind is the difference between difference and subtraction?
<InPhase>
Do you mean like a top-level negative geometry, rather than specifying what the difference should be applied to?
<Guest87>
Yes, precisely.
<Scopeuk>
Functionally you can do that by defining the things to remove in a module and differencing that with the final positive geometry
<InPhase>
It has been discussed, but it is harder to have clarity. One can achieve the same result by using structure to the design.
<Guest87>
Everything you just said is true.
<Guest87>
With that said, I'm not a talented CAD designer. I was hoping for a broad function to mimic conventional subtractive manufacturing.
<InPhase>
The difference operator does seem a little more confusing at first because you tend to feel like you have to keep moving things around to different levels of nesting. But that feeling goes away when you get yourself used to using a lot more module definitions in your design.
<InPhase>
Then you will see how difference fits in naturally with the declarative nature of OpenSCAD.
J24k85 has joined #openscad
J24k72 has quit [Ping timeout: 256 seconds]
<buZz>
this kinda aligns to my vague idea of using .scad language instead of gcode to run a cnc :P
<buZz>
(or 3d printer)
<buZz>
its a horrible idea :P
<buZz>
but yeah modules are awesome
<buZz>
i usually 'do stuff' by 1) dumping all measurements of parts involved in comments , 2) build module() stuff that represents the parts , 3) build module() stuff that is what i'm trying to design
<buZz>
kinda like assemblies or something, not really though
<buZz>
but makes it supereasy to seperate parts, or even subtract em off each other
<InPhase>
For difference you can typically get away with using a good bit larger than a small epsilon value, and it is often easier to just throw in a healthy extra amount for difference, and have fewer design mistakes.
drfff has quit [Ping timeout: 260 seconds]
<J24k85>
Guest87 also using render() will fully evaluate but without overlap and rotated/curved objects you will have float precision and some thin wall may occur.
<Guest87>
The more I read into it the more I realize its necessity, and the more I don't like it.
<Guest87>
It's like every grip I have with OpenSCAD stems around either problems with mathematical precision or that the math is done at compile time and not run time.
<Guest87>
*gripe
<J24k85>
that is what render(convexity=5) does - and when using manifold it is fast enough - also on complex objects it might take a short moment but improves viewing
<J24k85>
also helps when using transparent objects
<kintel>
pca006132 Looking at the polygon tessellation issue again: This happens after offsetting two separate polygons until they touch.
<kintel>
Offset is done using Clipperv1, which guarantees that the result doesn't intersect.
<kintel>
However, this is done in integer space (basically 64-bit fixed point with some scale factor), and my guess is that when we convert to float, the non-intersection guarantee no longer holds, and CGAL is forced to solve this by adding new vertices.
<kintel>
Not sure what is next; braindumping in hope of coming up with an idea :)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]