<OlivierChafik[m]>
teepee: hah, exciting! I guess the hard bit is to start with some manifoldness guarantee somewhere. Self-intersecting meshes seem so costly to repair for instance...
<OlivierChafik[m]>
I guess we're gonna *have* to wire manifold into OpenSCAD, even if "just to see" haha
<peepsalot>
ah, just read this from manifold "Part of my road map is to migrate from Thrust to C++20 parallel algorithms, which will alleviate the need to install the Cuda Developer Kit to build."
TheAssassin has quit [Ping timeout: 240 seconds]
<peepsalot>
so dropping thrust is already in plans, which is nice
TheAssassin has joined #openscad
ferdna has quit [Ping timeout: 240 seconds]
<peepsalot>
OlivierChafik[m]: I'm trying to think about how we could clean up / refactor openscad codebase to make it easier to drop in different geometry libraries like this now
<OlivierChafik[m]>
you could potentially generalize the hybrid polyhedron, which already hides away its internals from most of openscad (w/ some exceptions)
<peepsalot>
i think it boils down to the geometry data structures used, like we need a competent lowest denominator for our own processing and display (currently Polyset which is not so good)
<peepsalot>
and then a consistent interface to perform conversions between that and whatever structures the library uses, plus more clear interface for geometric operations on those structures
<OlivierChafik[m]>
yes, I was hoping to push for the Surface_mesh as a replacement for PolySet but after dealing with it a bit more I think it's a bit too rigid
<peepsalot>
oh, really? i've been hoping for that too, but I haven't had much chance to use it yet. what problems do you have with it?
<OlivierChafik[m]>
and flag some "quality" attributes (valid, manifold, closed) on solids to match what those libraries support, with extra steps to give them what they need (Repairs, etc)
<OlivierChafik[m]>
it's really expecting manifold solids. Can't add 3 faces to the same edge
<OlivierChafik[m]>
unclosed is okay though
<OlivierChafik[m]>
(that strictness helped me find many bugs in my algo haha, I was trying to add the same remeshed faces too many times :_D )
ur5us has joined #openscad
<peepsalot>
OlivierChafik[m]: have you seen OpenMesh before? https://www.graphics.rwth-aachen.de/software/openmesh/ I think it is similar to some of CGAL's types, and even recall some example code in CGAL docs convert to/from it i think
<peepsalot>
i wonder if it is less rigid possibly in the ways you are looking for
ferdna has joined #openscad
<peepsalot>
that is another one I've briefly looked at as possible replacement, but haven't really dug into either
<OlivierChafik[m]>
Hah, came across the name while going through CGAL's codebase but didn't look it up, thanks!
<OlivierChafik[m]>
I'd wager they're also heavy on manifoldness, being a halfedge-based structure
<OlivierChafik[m]>
maybe we should just repair inputs and enforce manifoldness from the start.
<OlivierChafik[m]>
make invalid polyhedron calls to explode with a flurry of errors
<OlivierChafik[m]>
patch the holes, and go as far as to removing self-intersecting faces
<peepsalot>
i'm not sure what this means exactly, but one of the first things in openmesh docs: "Ability to handle non-manifold vertices (like two faces meeting in only one vertex)."
<OlivierChafik[m]>
once we have manifold & closed meshes we can use Surface_mesh, nefs and any other library like the new Manifold
<peepsalot>
yeah, failing fast on non-manifold input would be best
<OlivierChafik[m]>
meeting in one vertex sounds less terrible for halfedge structures than 3 faces meeting in one edge. That's like harakiri
<peepsalot>
i guess they are talking about situations like this? square(); translate([1,1]) square();
<OlivierChafik[m]>
cube yes
<OlivierChafik[m]>
oh yes in 2d although not sure if openmesh handles that too
<OlivierChafik[m]>
but cube(1); translate([1, 1, 0]) cube(1); has an edge with 4 incident faces
<OlivierChafik[m]>
it defies some of their concepts of "opposite halfedge"
<OlivierChafik[m]>
(there are 4 halves in that case :D )
<OlivierChafik[m]>
The nef introduces crazy abstractions to resolve those cases and know what's inside this mess of incoming faces and what's outside
<peepsalot>
yeah i don't see mention of non-manifold edges yet :P
<OlivierChafik[m]>
I think it's possible to get by by not merging the edges, or in the opposite direction, by duplicating them (just like CGAL has functions to duplicate non-manifold vertices)
<OlivierChafik[m]>
peepsalot: Gotta go sleep but I'd love to chat more about how to make the geometry more generic.
<OlivierChafik[m]>
I think generally the entry point can be the CGALUtils::{get,create}*FromGeometry, which can special-case easy conversions and fallback to just converting the geom->toPolySet()
<OlivierChafik[m]>
Also, I've done quite a bit of faffing with the tree-rewriting ideas and various versions of multithreaded computations and somehow haven't run into visible racing conditions.
<OlivierChafik[m]>
But it's really challenging to keep the cores busy, depending on the tree structure
<OlivierChafik[m]>
(usually getting a blip of 6-core activity for a couple seconds then quickly hitting the critical path on a couple of cores, then one)
<peepsalot>
yeah, unless singular boolean operations can be broken into sub problems. multithreading is kinda tough
<peepsalot>
I guess we just need a "(1/(2N))-edge" data structure
<OlivierChafik[m]>
peepsalot: wonder if we can have Surface_mesh to agree to this. Looks like corefinement accepts `cube(1); translate([1, 1, 0]) cube(1);` so the mesh it produces must have duplicate edges, each with their pair of legit half-edges.
<OlivierChafik[m]>
We'd probably need some import algorithm that ensures we create such duplicated edges and leave the mesh to that fake manifoldness (or maybe it's considered real manifoldness so long as you have duplicated vertices and edges)
<peepsalot>
btw i get this from your cube example if I force a union: WARNING: [fast-csg] Corefinement corefinement mesh union failed
<OlivierChafik[m]>
(oh, right, not sure why I didn't see that, cache playing tricks on my mind i guess)
<peepsalot>
does that mean it falls back to nef?
ur5us has quit [Ping timeout: 240 seconds]
LordOfBikes has quit [Ping timeout: 240 seconds]
LordOfBikes has joined #openscad
arebil has joined #openscad
ur5us has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
ur5us has quit [Ping timeout: 256 seconds]
J2234 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
kyki has joined #openscad
ccox has quit [Ping timeout: 250 seconds]
ccox has joined #openscad
ferdna has quit [Quit: Leaving]
kyki has quit [Quit: Leaving]
arebil has joined #openscad
aiyion has quit [Read error: Connection reset by peer]
TheAssassin has quit [Remote host closed the connection]
teepee has quit [Read error: Connection reset by peer]
GNUmoon has quit [Read error: Connection reset by peer]
aiyion has joined #openscad
TheAssassin has joined #openscad
GNUmoon has joined #openscad
teepee has joined #openscad
GNUmoon has quit [Ping timeout: 240 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
TheAssassin has quit [Remote host closed the connection]
teepee has quit [Write error: Connection reset by peer]
aiyion has quit [Read error: Connection reset by peer]
TheAssassin has joined #openscad
aiyion has joined #openscad
teepee has joined #openscad
ur5us has joined #openscad
ur5us_ has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
arebil has joined #openscad
ur5us_ has quit [Ping timeout: 240 seconds]
trashbird has quit [Quit: Ping timeout (120 seconds)]
trashbird has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
ur5us_ has joined #openscad
GNUmoon has joined #openscad
ur5us_ has quit [Ping timeout: 240 seconds]
<peepsalot>
OlivierChafik[m]: btw i noticed there are alot more "*cgal*" source files from your recent efforts. it would be nice if we started to structure our src directory better, like having all cgal specific stuff in its own subdir
<peepsalot>
i know there wasn't really any structure to begin with, so I don't blame you for just continuing with how things have gone, but I'd like to start making an effort towards a more manageable source tree
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
splud has quit [Remote host closed the connection]
splud has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #openscad
arebil has joined #openscad
Xeha has quit [Changing host]
Xeha has joined #openscad
fling has quit [Ping timeout: 272 seconds]
fling has joined #openscad
nelson_ has quit [Quit: Leaving]
myosotis has joined #openscad
ccox has quit [Ping timeout: 256 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
epony has quit [Ping timeout: 240 seconds]
Junxter has quit [Remote host closed the connection]
Junxter has joined #openscad
Danny77 has joined #openscad
linext_ has quit [Read error: Connection reset by peer]
Danny77 has quit [Client Quit]
arebil has joined #openscad
J2234 has quit [Quit: Client closed]
J2234 has joined #openscad
epony has joined #openscad
J2234 has quit [Quit: Client closed]
J2234 has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
af has quit [Ping timeout: 250 seconds]
ccox has joined #openscad
lf94- is now known as lf94
ur5us_ has joined #openscad
ur5us_ has quit [Ping timeout: 240 seconds]
EkpyroticFrood has quit [Quit: Ping timeout (120 seconds)]
EkpyroticFrood has joined #openscad
J4l13n has joined #openscad
rvt has quit [Remote host closed the connection]
castaway has quit [Ping timeout: 250 seconds]
Alexer has quit [Ping timeout: 252 seconds]
castaway has joined #openscad
Alexer has joined #openscad
ur5us_ has joined #openscad
rvt has joined #openscad
<J4l13n>
Hi, I would like to do a twist with a circle that decreases as it goes , linear_extrude(height = 10, center = true, convexity = 10, twist = -500)
<J4l13n>
translate([2, 0, 0])
<J4l13n>
circle(r = 1);
<J4l13n>
exemple the circle on the top = 10 en 1 a the end of twist
<J4l13n>
is it possible ?
<teepee>
there's also a scale parameter
<teepee>
but it scales relative to origin, so it might not be what you need
<J4l13n>
I tried : linear_extrude(height = 10,scale=[1,0.1], center = true, convexity = 10, twist = -500)
<J4l13n>
translate([2, 0, 0])
<J4l13n>
circle(r = 1);
<J4l13n>
but not good
<teepee>
then you may need to use one of the libraries allowing some sort of sweep operation
<teepee>
but if linear_extrude() works, that's great :)
<peepsalot>
btw I set $fs based on the size of your model, but if your actual model is much larger than r=1 etc, then you may want to increase $fs to 0.5 or 1 to keep it from being too many faces/vertices
_xxoxx has joined #openscad
Guest7 has joined #openscad
<J4l13n>
ok i will try different settings
Guest7 has quit [Client Quit]
J4l13n has quit [Quit: Client closed]
Junxter has quit [Ping timeout: 256 seconds]
TheCoffeMaker has quit [Ping timeout: 272 seconds]
TheCoffeMaker has joined #openscad
<OlivierChafik[m]>
teepee: such an unbelievably cool library!
<teepee>
I did not have the time to really have a look, but it sounds neat
<teepee>
c++20 is a bit ambitious though :)
<teepee>
did you see what operations it supports so far?
_xxoxx has quit [Read error: Connection reset by peer]
Junxter has joined #openscad
<teepee>
yep, lots of vertices on one side :)
Junxter has quit [Quit: Leaving]
<J2234>
if you use a even distribution the nose will have a sharp edge or you end up with 500+ points
<OlivierChafik[m]>
teepee: do you mean the manifold library? should be easy to plug the core csg operations yes
<OlivierChafik[m]>
we'd just need to make the entry points / conversion from polyset / results of extrude, hull and minkowski watertight if they aren't already
<teepee>
yep, the manifold library
<teepee>
the interesting point might be dependencies, if those are required
<OlivierChafik[m]>
peepsalot: agree some order would be nice... maybe a cgal folder?
<OlivierChafik[m]>
(it all looks legit and challenges my newly-acquired convictions about Surface_mesh :'-( )
<OlivierChafik[m]>
Ooh now I get where the c++20 is coming from haha
<teepee>
it would be nice to have an option for "existing" stuff :)
<teepee>
c++17 is pretty much on the table just now
<peepsalot>
OlivierChafik[m]: yes i think a src/cgal would be a good start
<peepsalot>
i'm just hesitant to do it myself since you are the one touching those files so much lately
<peepsalot>
OlivierChafik[m]: do you know what i mean about degenerate triangles in that comment? a zero area triangle could topologically close up a mesh while appearing to have a t junction
<peepsalot>
that's my current hunch of whats happening, i just don't know if such 0 area tris can cause further problems when passed to subsequent CGAL ops
<OlivierChafik[m]>
Oh right, absolutely!
<OlivierChafik[m]>
Hadn't understood that until now haha
<OlivierChafik[m]>
I'm filing a detailed bug / question to cgal now
<OlivierChafik[m]>
mmh so maybe the triangles aren't degenerate but "almost" degenerate haha
<OlivierChafik[m]>
yeah zooming in to the extreme shows some weirdness there
<OlivierChafik[m]>
I'm afraid the proper fix is exact numbers in the transforms, transform exact Surface_meshes instead of polysets
<OlivierChafik[m]>
also I've tried to add some tolerance in coplanar checks but then it messes the retriangulation I'm using so far, I'll have to use another one. Will keep this for later if we want.
<peepsalot>
hmm, how are you even zooming that close? GL casts down from double to float btw, so depending on zoom level, it could be just the graphics incapable of representing a double based mesh
<OlivierChafik[m]>
I think if it were watertight it would still converge to the same point. And I used the other day's trick of double clicking + zoom on mouse setting haha
noonien5 has joined #openscad
drkow has joined #openscad
JakeSays_ has joined #openscad
juri_ has quit [Ping timeout: 256 seconds]
<OlivierChafik[m]>
teepee: the remesh PR is ready again (https://github.com/openscad/openscad/pull/4117). I've added a gruesome fixed-ordering to ensure I start walking around each patch from its "smallest" vertex, so the tests should now pass (some vms in the previous run seems to have hung for like 2h, not sure if that's a transient issue? but some tests did pass).
<OlivierChafik[m]>
I'm also doing less coplanar tests than before, using the processedFaces bookkeeping as proof that the current patch can't be coplanar with a previously processed face (otherwise it would have globbed us into its own patch already).
noonien has quit [Ping timeout: 256 seconds]
JakeSays has quit [Ping timeout: 256 seconds]
auctus has quit [Ping timeout: 256 seconds]
noonien5 is now known as noonien
drfff has quit [Ping timeout: 256 seconds]
auctus has joined #openscad
JakeSays_ is now known as JakeSays
juri_ has joined #openscad
<OlivierChafik[m]>
peepsalot: mmh so in the light of this, not sure it's a bug in corefinement / can't be an actual T junction. The mesh is really in "good shape" as far as CGAL checks can tell. Here's the repro: https://gist.github.com/ochafik/61568f7f547bc67a0f2ecec8ad5f9ce6
<OlivierChafik[m]>
(I'm getting the hang of self-contained repro cases for CGAL haha)
myosotis has quit [Quit: myosotis]
ferdna has joined #openscad
ur5us_ has quit [Ping timeout: 240 seconds]
<teepee>
yeah, sometimes the builds get stuck, probably swapping when hitting a bad combination of cgal templates compiling in parallel