<teepee>
hmm, that's not actually changing import code :)
<JordanBrown1>
teepee any idea hat's going on with that tbb error that I'm getting in my CI runs? That's nowhere near the stuff I'm working on, unless it's a really obscure relationship.
<JordanBrown1>
oops What'
<JordanBrown1>
oops oops What's
<mmu_man>
repair_polygon_soup nice name :D
<teepee>
JordanBrown1: I have not seen that before, it sounds like maybe a naming conflict with "emit"
<JordanBrown1>
Yeah, but what changed to make it happen?
<teepee>
additional include file?
<JordanBrown1>
Hmm. I have not updated the submodules; perhaps I should do that.
<JordanBrown1>
I will check for additional include files, but I didn't do anything radical.
<teepee>
well, that unity build stuff seems very fragile
<JordanBrown1>
I see that schiele had the same error on macos (but not on Linux).
<teepee>
it feels like a huge hack that can get quite some build benefit, but still is just some very messy stuff internally
<JordanBrown1>
I haven't looked at it. I suspect that I don't want to :-)
<teepee>
as far as I understand it just mushes as many files as it can find into a single unity_xx.cpp file and compiles that
<teepee>
which breaks with various things like overlapping #defines or anonymous namespaces or whatever else did not expect to be thrown into a single file
<JordanBrown1>
Right.
<JordanBrown1>
File scope is a thing.
moonlight has joined #openscad
<mmu_man>
return vertices_.lookup(pt); < of course it won't add it if it's there already…
<mmu_man>
so I can't use PolySetBuilder directly, I have to make a map first
<teepee>
well, I lack the time to do all the more interesting stuff I would like to do
<teepee>
so I'll try to at least mop up some tiny things here and there :)
<teepee>
mmu_man: found the referenc in https://github.com/openscad/openscad/issues/4851 - "ManifoldGeometry: You should not use the builder with manifold. It purposely duplicate the vertices to maintain manifoldness, so deduplicating them will just cause you more trouble. Also, the mesh data structure is very much like the indexed polyset, so there is no point hashing everything again..."
<moonlight>
Okay, I really need to use manifold, there a commit hash which is known to work good? I can chechout that hash
<moonlight>
is there a commit**
<teepee>
not sure about the state of triangle faces, there was some discussion about that not long ago too - IIRC OFF supports more than triangles, or was that OBJ?
<teepee>
moonlight: what's wrong with the latest master commit?
<teepee>
ignoring platform or driver issues that are hard to catch, the test suite does a reasonable job in ensuring the latest snapshot works
<moonlight>
Ahh sorry I missunderstood, It was a message for mmu_man, sorry for confusion
<mmu_man>
teepee: OK, was about to try with an std::array<Vector3D> as a temporary index, and let the builder handle reindexing, but I suppose it'd be better to maintain them in the PolySet
<mmu_man>
checking #4937
<mmu_man>
ah, example, thanks
<mmu_man>
let's first commit what I did
snaked has joined #openscad
<moonlight>
Another question guys:
<moonlight>
On main branch version, when running from command line, is it necessary to specify --manifold or it's used by default ?
<teepee>
--enable manifold
<moonlight>
(y) (y)
<mmu_man>
teepee: wasn't that difficult, works now!
<teepee>
nice
<mmu_man>
except the color, which was the reason I looked at it in the first place but it seems it's way more involved
<mmu_man>
hmm the scale is wrong, I had to scale(1000)
<mmu_man>
should I fix the coords or just let people scale?
<teepee>
strictly speaking there's no units, but also there some sort of convention 1 unit = 1 mm
<teepee>
so if the multiply by 1000 would match mm that would be a good compromise
<mmu_man>
yes
<mmu_man>
not sure there's any convention on OFF files
<mmu_man>
I only tested a single KiCad export through meshlab
<teepee>
with CGAL it was always the issue that they do support properties, but not in the scenario we use
<teepee>
pca006132 mentioned it should be possible with Manifold as they have vertex properties that survive the boolean operations so it's possible to determine what part belongs to what input
<teepee>
and long time ago someone did a prototype with another geometry engine but unfortunately people happened on the mailing list and that effort died :/
<teepee>
ubitux: yep, watched that earlier, very nice
<teepee>
I was surprised about that tiny pin being printed so nicely
<ubitux>
yeah i was surprised too
<ubitux>
the prusa really isn't a bad printer
<ubitux>
compared to the one i had previously…
<teepee>
yep, owning a MK4 for a bit more than a month, I very much agree
<teepee>
the ancient MK1 worked well for years, but the tiny things making live really better are amazing with the MK4
<ubitux>
mk3s here
fling has quit [Ping timeout: 255 seconds]
fling has joined #openscad
teepee_ has joined #openscad
<mmu_man>
not sure what to look into right now, is there documentation about the architecture of what is used where?
<mmu_man>
anyway, should sleep
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<mmu_man>
and tomorrow is again a busy FOSDEM day
<teepee>
ahh, I'll miss the burger tram :)
teepee has quit [Remote host closed the connection]