Beveled/Rounded corners on box's
19 views
Skip to first unread message
Wink Saville
Jun 13, 2020, 2:42:16 PM6/13/20
to Curv
I've done some investigation into the "gap" problem originally I mentioned in this post and Doug identified the problem as a "crease" and he provided solutions in this post.
Anyway, "I think" the crease is happening because there is a "beveling/rounding" of a box's edges. I see this beveling when I look at the ".obj" file with vsize=1 in the prusa-slicer, see attachment. Note, in the live view I see no beveling/rounding.
I can reduce the effect by decreasing vsize, although at a vsize of 0.01 my 32GB machine runs out of memory, so I'm hoping there's another solution.
-- Wink
Doug Moen
Jun 13, 2020, 3:14:07 PM6/13/20
to Curv
So in other words, it is a side effect of the mesh generation algorithm that I am using. My current mesher comes from the openvdb library; they don't document the algorithm, but the output resembles marching cubes. Anyway the "beveling" effect that you mention is a characteristic of marching cubes. The sphere tracing algorithm that I use to render shapes on a display does not create these gaps, only the mesh generator.
One of my future goals is to experiment with alternative meshing algorithms. The next one on my list to try is "dual contouring", specifically the non-self-intersecting variant. There are implementations on github. This algorithm performs sharp edge detection, so that a cube is rendered with sharp edges instead of being "beveled". It's possible that when using this alternative meshing algorithm, the "gap" problem with go away. Since I don't understand the problem in all its details, only testing will indicate this for sure.
Adding an alternate mesh generator is a coding task that requires only minimal knowledge of the Curv internals, if anybody is interested. All of the relevant Curv code that you'd need to understand and modify is located in curv/export_mesh.cc.
Doug Moen.
--You received this message because you are subscribed to the Google Groups "Curv" group.To unsubscribe from this group and stop receiving emails from it, send an email to curv+uns...@googlegroups.com.To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/CAKk8ispOGoPkf_tft2B7TevKFiGvq%2Bv_xjknRP0OK-8x-kGBvw%40mail.gmail.com.Attachments:
- box.mitred.vsize-1.png
Alexandre François Garreau
Jun 13, 2020, 3:16:11 PM6/13/20
to cu...@googlegroups.com
Doesn’t libfive displays and hence generates meshes? what does it uses?
Doug Moen
Jun 13, 2020, 3:29:53 PM6/13/20
to Curv
libfive uses a new algorithm created by the libfive author, Matt Keeter.
Unfortunately, this algorithm appears to be incompatible with Curv. Curv shapes are defined by a signed distance function. The input to Libfive is not just a signed distance function (SDF), you also need to be able to do interval arithmetic on the SDF. The only SDFs that are suitable are those that are defined using closed arithmetic expressions (no conditionals, and no loops). Many of the shapes in Curv's standard library, or in the examples directory, use conditionals and loops to define signed distance functions. These shapes can't be meshed by libfive. Even among the Curv shapes that are compatible with libfive, I would need to modify the Curv compiler to automatically generate code for doing interval arithmetic, and that is a whole lot of work to do for something that would only be a partial solution.
Doug Moen
On Sat, Jun 13, 2020, at 3:15 PM, Alexandre François Garreau wrote:
> Doesn’t libfive displays and hence generates meshes? what does it uses?
>
>
Unfortunately, this algorithm appears to be incompatible with Curv. Curv shapes are defined by a signed distance function. The input to Libfive is not just a signed distance function (SDF), you also need to be able to do interval arithmetic on the SDF. The only SDFs that are suitable are those that are defined using closed arithmetic expressions (no conditionals, and no loops). Many of the shapes in Curv's standard library, or in the examples directory, use conditionals and loops to define signed distance functions. These shapes can't be meshed by libfive. Even among the Curv shapes that are compatible with libfive, I would need to modify the Curv compiler to automatically generate code for doing interval arithmetic, and that is a whole lot of work to do for something that would only be a partial solution.
Doug Moen
On Sat, Jun 13, 2020, at 3:15 PM, Alexandre François Garreau wrote:
> Doesn’t libfive displays and hence generates meshes? what does it uses?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Curv" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to curv+uns...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/curv/1901564.SeCXMcn8hf%40galex-713.eu.
> You received this message because you are subscribed to the Google
> Groups "Curv" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to curv+uns...@googlegroups.com.
> To view this discussion on the web, visit
>
Matthew Keeter
Jun 13, 2020, 3:56:33 PM6/13/20
to Doug Moen, Curv
libfive is mostly manifold dual contouring [1], which snaps to sharp features and is watertight + manifold, but may contain self-intersections. I experimented with a few other algorithms, but nothing is better so far.
I think that Doug and I talked about mixing libfive + Curv a few years back. At this point, the right way to do it would be using an Oracle, which lets you embed an arbitrary black-box into the math tree (then hide a CPU-side Curv interpreter in that black box). This isn’t super well-documented, but I could write it up if there’s strong enough interest.
For ease of implementation, you could even have the oracle return +/-infinity for every interval evaluation (which is technically true!). This would be less efficient, since it would force evaluation to recurse down to individual voxels, but would let you avoid implementing interval arithmetic in Curv.
You’d still need to calculate partial derivates, since that’s what libfive uses to place vertices on sharp features. Since Curv renders with shading, I suspect that you’ve already got a path for that, although partial differences would also work as a last resort.
-Matt
[1] http://faculty.cs.tamu.edu/schaefer/research/dualsimp_tvcg.pdf
> To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/bbe66f9c-cfaf-46a1-9985-0bf2385269c7%40www.fastmail.com.
I think that Doug and I talked about mixing libfive + Curv a few years back. At this point, the right way to do it would be using an Oracle, which lets you embed an arbitrary black-box into the math tree (then hide a CPU-side Curv interpreter in that black box). This isn’t super well-documented, but I could write it up if there’s strong enough interest.
For ease of implementation, you could even have the oracle return +/-infinity for every interval evaluation (which is technically true!). This would be less efficient, since it would force evaluation to recurse down to individual voxels, but would let you avoid implementing interval arithmetic in Curv.
You’d still need to calculate partial derivates, since that’s what libfive uses to place vertices on sharp features. Since Curv renders with shading, I suspect that you’ve already got a path for that, although partial differences would also work as a last resort.
-Matt
[1] http://faculty.cs.tamu.edu/schaefer/research/dualsimp_tvcg.pdf
Wink Saville
Jun 13, 2020, 4:56:23 PM6/13/20
to Matthew Keeter, Doug Moen, Curv
Seems I asked a good question, the proposed solution is beyond me at this point, but I'd like to track the progress. Does there happen to be an issue I can track/follow?
Alexandre François Garreau
Jun 13, 2020, 5:52:52 PM6/13/20
to cu...@googlegroups.com
This is really interesting. That recalls me of something I thought
meanwhile: I often ended up thinking that it would be useful to have a
kernel 3D procedural language that could both generate meshs, like
openscad (maybe compatible with it?), and SDFs (it would be like openscad
with SDFs added), so meshes can be generated when useful… but I’m unsure
it would be possible to do as much transformation as possible in curv.
I thought to it a lot and realized that what made me think this was the
“Right Thing” is that, in my head “the definition of a cube involves sharp
edges” so “if we get that while defining it as a mesh, then when doing that
as a SDF some information has to be lost in comparison”. Then I tried to
apply that on a lower level, thinking to the kernel SDF function for the
cube, and thought: doesn’t a sharp-edged SDF necessarily involves
discountinuous computation? such as min, max, abs, or, more generally,
conditionals? Isn’t there a way to do statical program analysis to
detect, for instance, when we clip stuff using max? are there algorithms
that do that? is what I’m saying all wrong? or what part of it?
Could one assert something as “marching cube is okay for continuous
volumes, otherwise try edge-detection looking at the function’s
implementation”?
meanwhile: I often ended up thinking that it would be useful to have a
kernel 3D procedural language that could both generate meshs, like
openscad (maybe compatible with it?), and SDFs (it would be like openscad
with SDFs added), so meshes can be generated when useful… but I’m unsure
it would be possible to do as much transformation as possible in curv.
I thought to it a lot and realized that what made me think this was the
“Right Thing” is that, in my head “the definition of a cube involves sharp
edges” so “if we get that while defining it as a mesh, then when doing that
as a SDF some information has to be lost in comparison”. Then I tried to
apply that on a lower level, thinking to the kernel SDF function for the
cube, and thought: doesn’t a sharp-edged SDF necessarily involves
discountinuous computation? such as min, max, abs, or, more generally,
conditionals? Isn’t there a way to do statical program analysis to
detect, for instance, when we clip stuff using max? are there algorithms
that do that? is what I’m saying all wrong? or what part of it?
Could one assert something as “marching cube is okay for continuous
volumes, otherwise try edge-detection looking at the function’s
implementation”?
Reply all
Reply to author
Forward
0 new messages