<guso78>
these are the extensions in the visit function of the offset node. i cant find anything wrong about it.
TheCoffeMaker has quit [Ping timeout: 246 seconds]
pa has quit [Ping timeout: 260 seconds]
TheCoffeMaker has joined #openscad
pah has joined #openscad
J234641 is now known as J23
<J23>
did an animation saves a backup file each frame?
castaway has joined #openscad
pah has quit [Ping timeout: 252 seconds]
pah has joined #openscad
pah has quit [Ping timeout: 265 seconds]
pah_ has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
pah_ has quit [Ping timeout: 260 seconds]
pah has joined #openscad
pah has quit [Ping timeout: 252 seconds]
pah has joined #openscad
aiyion has quit [Ping timeout: 255 seconds]
aiyion has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
pah has quit [Ping timeout: 252 seconds]
pah has joined #openscad
Number3[m] has joined #openscad
pah has quit [Ping timeout: 252 seconds]
pah has joined #openscad
<InPhase>
guso78: A 3D offset requires more consideration than just each face going in a unique direction. You must also decide how to handle each vertex of each face. If you are doing a spherical offset, then each vertex extends out spherically, meaning the faces are preserved in size and move out by their normals, but each convex vertex splits into multiple vertices spherically distributed from the original.
<InPhase>
guso78: For example, consider a cube. A spherical 3D offset results in volume with the same cube faces, but spherical rounding on the corners and rounded edges between them.
<InPhase>
guso78: An alternative attempt at an offset attempts to preserve face count and simply move the vertices "outward", which requires you you to attempt to define a "normal" for each vertex. This is somewhat tricky because there is not a single definition for a vertex normal when you have irregular faces around the vertex of irregular angular size and mixes of concavity and convexity of the faces along
<InPhase>
the edges that radiate outwward from the vertex.
Guest27 has joined #openscad
<InPhase>
Spherical 3D offset is probably the simplest one to attempt to start with because it is both commonly wanted AND the most obviously well-defined.
pah has quit [Ping timeout: 260 seconds]
<InPhase>
guso78: If you attempt to do the one I marked "alternative attempt", and your intuition says it should be easy, speak up and I can attempt to construct some pathological cases for you that illustrate the challenge of it.
<InPhase>
Or that at least should provide challenges or oddities for an implementation.
<InPhase>
It is easy to get overconfidence of the simplicity of that when reasoning from the regular polygons and spheres.
<InPhase>
s/polygons/polyhedrons/
<InPhase>
But my advice is to do spherical, at least as the baseline.
Guest27 has quit [Quit: Client closed]
pah has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
pah has quit [Ping timeout: 260 seconds]
guso78ggg has joined #openscad
guso7868 has joined #openscad
<guso7868>
Spherical Offset means Offset where each Corner becomes a Part of a sphere? If Not, please send a Link so that i can understand.
L29Ah has quit [Read error: Connection reset by peer]
<guso78>
InPhase, you imagination of 3D offset is same as 2d offset translated to 3D. where in 2d the lines move out by a constant value, in 3D the faces go outside by a constant value.
<guso78>
this is also my actual requirement for offsetting faces in 3D . And i need at least 3 faces to move out normally in order to calculate the new position of a vertex point which is member of all of the 3 phases. Maybe you can have a look into the PR and check the algorithm.
guso7868 has quit [Quit: Client closed]
<guso78>
The Intent of the PR was not " it was cool to have a 3D offset, i am playing around to maybe find something useful". rather it was "i am confident to have a solution which very much fits to my expection, how an offset should look like"
<guso78>
personally i like to have the 3D offset with small negative numbers of -0.3mm e.g. to fix 3D prints which are too tight to assemble.
<guso78>
If there are other "modes" of valid looking 3D offset, send me a sketch and i try to implement them in parallel.
<teepee>
I wonder if it would make more sense playing that topic indirectly
<teepee>
by solving it in whatever library we want to pick
<guso78ggg>
in Phase, i believe i have implemented your Alternative approach and i have an exact Idea in the correct Vertex normal. actually there is only one solution to have the neighboring faces Offset parallel and i have exactly this one.
guso78ggg has quit [Read error: Connection reset by peer]
hrberg has joined #openscad
GNUmoon has quit [Ping timeout: 255 seconds]
GNUmoon has joined #openscad
<InPhase>
guso78: Here's a testcase that encapsulates all the things I consider most likely to go wrong in a 3D offset: https://bpa.st/QR5J2
<guso78>
InPhase, thank you! Will have a look into this later :)
<guso78>
please tell me also the offset value, which you consider most critical.
Bocaneri has joined #openscad
Bocaneri is now known as Guest419
Sauvin has quit [Ping timeout: 252 seconds]
guso78 has quit [Ping timeout: 260 seconds]
Guest419 is now known as SenFache
nbr0wn has quit [Quit: WeeChat 3.5]
guso78 has joined #openscad
fury999io has joined #openscad
<gunnbr>
status?
<InPhase>
guso78: It's calibrated so +/- 3 or so could make some issues visible. But I'd recommend testing over some ranges. It's always helpful to go to extremes.
<gunnbr>
Ah. It's othx that's down. Sorry--I upgraded the server last night and it's got a DB connection failure right now.
fury999io has quit [Quit: Konversation terminated!]
* InPhase
salutes gunnbr's diligence.
<InPhase>
!botmaintainersnack
<gunnbr>
:grin:
<InPhase>
guso78: Issues to look for: Deformations in the inner and outer cones, deformations in the inner and outer cubes, cone orientation inconsistentencies on the cone bit that slices through the cube in the back, sensible cube merging of the open slit in the front on positive offsets, adjacent object merge issues on positive offset, and successful opening of holes from internal objects on negative offsets.
<InPhase>
guso78: At issue are disconnects between a particular algorithmic definition of what offset means, and user expectations for what it means in particular situations. We'll need to make sure it has a clarity that is appropriate and that if there are any intuition surprises, they can be minimized and/or explained with clarity, and are broadly acceptable as okay.
<InPhase>
And a few of those parts of that test are just trying to trip up some manifold-output challenges, which is a more fundamental requirement for correctness.
<InPhase>
I'm quite confident manifoldness can be solved, so that part is just to help it out and make sure it doesn't have any lurking bugs.
ur5us has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
epony has joined #openscad
Bocaneri has joined #openscad
Bocaneri is now known as Guest8231
SenFache has quit [Ping timeout: 252 seconds]
<guso78>
InPhase, this is actually a challenging testcase, i will see, how it goes ...
<guso78>
1st challenge here is: if i try size on two independant cubes instead of one, ps is a Nullpointer instead
<guso78>
believing that this is not an openscad bug i need to understand now, how to correctly receive the info about 2 independant objects
<guso78>
BTW my opencsg display issue was resolved, when i defined, that the result was concave even though its convex .
<teepee>
guso78: that likely means you have lazy union enabled so you get a list instead of a single polyset
<guso78>
ahh thank you for the hint.
<guso78>
how can check if i will get a list delivered and how do i receive the list ?
<teepee>
cast to the list and see if that's not null - there should be plenty example, e.g. in export_stl.cc
<guso78>
you mean: cast to: std::list<const PolySet> ?
<guso78>
is there an option never to receive a list ? as in size there is always the chance, that objects melt together, i'd like to handle everything a a single set of polygons ...
ur5us has quit [Ping timeout: 260 seconds]
<guso78>
hmm, when i receive a list, i could actually offset each set separately for efficience, and union the result together, in the end(i need to do that anyway)
<teepee>
or maybe not even do the union just yet
ur5us has joined #openscad
<guso78>
ahh, you mean the final union
<teepee>
could be none at all, e.g. if the next node above would be a hull()
<teepee>
skipping the need to actually do the union completely
guso7846 has joined #openscad
<guso7846>
the reason , why i want a final union is to get rid of corners of volume, which does not exist anymore or to get holes which were closed already. generally: git rid of corners of negative or double volume
<guso7846>
if cgal is not efficient for me enough, i also consider using other libs/own code
* teepee
points to Manifold again :)
<guso7846>
yep, message taken. i will act accordingly soon
guso78 has quit [Ping timeout: 260 seconds]
guso7846 has quit [Ping timeout: 260 seconds]
ur5us has quit [Ping timeout: 248 seconds]
guso78 has joined #openscad
Guest8231 is now known as SenFache
guso78 has quit [Client Quit]
rvt has quit [Ping timeout: 268 seconds]
rvt has joined #openscad
Av8r has quit [Remote host closed the connection]
ur5us has joined #openscad
lkcl has quit [Ping timeout: 265 seconds]
lkcl has joined #openscad
castaway has quit [Ping timeout: 268 seconds]
TheAssassin has quit [Quit: No Ping reply in 180 seconds.]
TheAssassin has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<sinned6915>
can anyone tell me what kind of sorcery and witchcraft this author used to get fillets on their parts?
<InPhase>
Also it has the weird result of rounding only on one axis.
<InPhase>
Or, two I guess.
<sinned6915>
is there a 'better' way of doing filets on something like this?
<InPhase>
It depends on the shape really. But if you have a pretty simple starting geometry, a minkowski to filet a bit is actually not too expensive.
<InPhase>
You get expensive when you start nesting heavy smoothness with more minkowski of that.
<InPhase>
Like on that hand grip piece, that looks like it's begging for a 2D geometry linear extruded and then minkowski'd with a small sphere.
<InPhase>
You could get the bulk of the 2D shape with some squares, circles, 2D hulls, and 2D offset, all of which are very cheap.
<sinned6915>
one sec, i am trying to mock it uip
<InPhase>
Although that's only if you want to reproduce that shape. If I were doing it myself I would 3D round it more. A professional pipette tip is not that blocky, because that would be too uncomfortable with long use.