New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Probe (bounding box, volume, centroid) #1713
Conversation
Hmmm.... seems that this attempt passed the comlete build, but failed testing for the 3 examples I added (examples/Probe/...). Any suggestion on how to proceed to get these examples to pass? |
Did you add all the files? Easiest solution is to use I'm getting:
|
I see... running "TEST_GENERATE=1 ctest -R probe_bbox" (without -C Examples) provided the missing file under regression/dumptest-examples/ Maybe docs/testing.txt could be adjusted to reflect this? |
In an attempt to answer the need for the computation of bounding box, volume and centroid, here is my proposal for a new command: probe(). See previous discussions about this: pull request #1388 , issue #1504 , issue #586, issue #301, and in the forum at http://forum.openscad.org/Volume-and-Center-of-mass-td15421.html probe() will analyse the geometry of its first children, then define preset variables (empty, bbsize, bbcenter, bbmin, bbmax, volume, centroid) which can be used during the evaluation of its subsequent children. The variable only exists for the children of probe(). The first children is never added to the render tree. The volume/centroid is only computed on demand, with parameter volume=true. The bounding box is always fast to compute. The volume can be fast or slow. It relies on a nef-polyhedron decomposition into convex shapes, so the more non-convex is your shape.... To print the volume of a geometry, just do
You could illustrate the bounding box of any geometry with this module:
Obviously, it make it extremely easy to center/resize/align any geometry. For example, this will center the geometry according to the bounding box:
It is possible to go much further and align two geometries on any axis and with any anchor point. This is ideal to place text on objects, and simplifies managing stl imports. Using recursion, probe() makes it possible to do the following things:
Anyway, this pull request is not very complete at the moment. More examples are needed and, of course, documentation. However, I hope it can be tried so we can discuss this feature and see how if it is a worthwhile addition to openscad. |
Thanks for creating the pull request. I think it's an essential feature, however, I'm not convinced this is the right way of going about it. See my comment on #301 about bringing geometry back into variable space with This method only exposes some useful variables about the model, not the actual geometry. Additionally, it can only be invoked from module space. I would be happier with an option to probe that exposes the geometry in a probe_geometry special variable or similar. But it would still not be callable from functions (e.g. no function centerOf(points)), which is unfortunate. That all being said, if the maintainers would prefer this over a full merging of function / module space (without a complete language overhaul), I'd much prefer this over where we are now. |
When is this feature added to OpenSCAD? There is a huge crowd waiting for it. It is desperately needed. Hurry |
No plans on adding this? |
Hi,
Sorry, I got tired of asking and justifying why measuring bounding box,
centroid and volume is a good thing in a 3D parametric CSG system like
Openscad.
If there is renewed interest, I'll gladly update my fork of openscad
and send a new pull request. But I need assurance that I won't do all
this to be told "we don't want it".
Sincerely,
Sébastien
Le lundi 18 décembre 2017 à 02:54 +0000, Made Velasco a écrit :
… No plans on adding this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi! I want this feature. I need it for precise computation of aerodynamics models. I think it could be the demonstrable application of this function. It is because of the surface of models is the complex function itself the function is approximated by polygons. But the volume, center of gravity and other related parameters need to be known precisely. |
Hi,
Le jeudi 03 mai 2018 à 14:04 -0700, Jakub Kákona a écrit :
Hi! I want this feature. I need it for precise computation of
aerodynamics models. I think it could be the demonstrable application
of this function. It is because of the surface of models is the
complex function itself the function is approximated by polygons. But
the volume, center of gravity and other related parameters need to be
known precisely.
Thanks for your interests in this feature. I also think it is a must
for Openscad. If the maintainers of openscad show interest, I'll send a
new pull request and we can integrate it.
Otherwise, I put it in a lua-based version of openscad that I made,
just for fun, checking how the lua syntax can be used to emulate
openscad...
Sebastien
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I would also like this feature - enough that I'm considering building my own version of OpenSCAD just to include this patch. Baffling that you can't measure geometry in a parametric system. |
The issue is that it would require a render, as for preview the geometry is not calculated. |
Hi everyone,
On Tue, 2019-10-01 at 01:25 -0700, Michael wrote:
The issue is that it would require a render, as for preview the
geometry is not calculated.
As I am the one who implemented this feature a while ago. I would like
to reafirm that features such as probe have a deep impact on what can
be modelled in openscad, so it should be considered for inclusion, even
if a render is needed to compute it.
We all know that openscad has no way of positionning geometry relative
to other geometry, and this is a severe handicap.
The first example that comes to mind is the import of external STL
geometry, which is impossible to automatically center or scale.
Some shy attempts have been made to tackle this... for example text()
has alignment options, but there is still no way to know what is the
bounding box of some text string. This is not acceptable when you
consider that the string might be a parameter, which can change. After
all, openscad is advertized as ideal to make parametrized models...
I am sorry for my pessimistic tone, but my probe() pull request was
rejected years ago, and I will only update and resubmit if I am told it
is a desired addition to openscad. By the way, functions like probe(),
volume(), centerOfMass() and render() could be highligted in red, just
to illustrate the fact that they are more computationaly expensive (I
would make minkowski red also...). Such functions, even if they are
computationaly expensive, are very very powerful. Reducing a language
expressive power for the sake of a fast preview is, in my opinion, not
a good compromise and hurts the language in the long run.
In the mean time I implemented my own openscad "clone" with lua as a
base language and two dedicaded modules: "nef" for rendering and
"opencsg" for previewing. Works very well, and it has boundingBox(),
volume(), centerOfMass(), ... and you can use +-*/ for CSG operations
:-)
Sorry for the long message. Its long because I truly appreciate they
"openscad way of modelling", and care about improving it.
Sincerety,
Sébastien
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Yes I can't see why your code can't be merged because it doesn't make render any slower, it just makes it more useful. People already use render in preview and know the consequences. For 2D objects it is negligible so could easily work for text. |
Another vote for resurrecting and merging this. I just spent a few hours with Blender re-coloring a complex geometry that openscad would only export as STL, and I know the issue is simply that it contains some edge-sharing polyhedra. As I understand the proposed functionality, it would make it trivial to scale these around their centroid so that they no longer touch (while still keeping this impression in a 3d-printed model) |
Hello people. Recently i came in the need of calculating the volume of an object made in openscad. Meanwhile, do someone have an advice on how i could compute a part's volume ? Thanks for reading. |
Hi!
As we know, the pull request was rejected on the basis that volume (and
center of mass and bounding box) require the equivalent of "render()"
to perform the computation. This was considered a danger to make
openscad slower than it already is...
My view on this is that when you really need volume/center of
mass/bounding box, you dont care to wait for a render.
So if I get a clear "we wont reject a pull request for volume/center of
mass/bounding box", i'll update the code and make a new pull request
immediatly.
Sincerely,
Sébastien
DIRO/FAS/Université de Montréal
…On Fri, 2020-02-07 at 13:39 -0800, CaptainFalcon92 wrote:
Hello people. Recently i come in the need of calculating the volume
of an object made in openscad.
First i would like to thanks and congratulate all the peoples
involved in making openscad, what a great tool ! It has been years
since this pull request opened, but still i think having such
powerful functions could really bring openscad to an other level.
Although i would like to get volume from CLI (command or flag), i
sincerely think this topic deserve to be rebirth.
Maybe you guys could work on such a powerful feature together and
find the sweet spot ? :)
I'm unfortunately too ignorant in this program sources and internal
to be of any help, but encouragement.
I wish this find it's way in, as is, or maybe rebuilt differently
idk..
Meanwhile, do someone have an advice on how i could compute a part's
volume ? Thanks for reading.
Best regards.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Is it even possible to calculate the center of the bounding box without performing a render? |
Hi Marius,
On Sat, 2020-02-08 at 18:36 -0800, Marius Kintel wrote:
Is it even possible to calculate the center of the bounding box
without performing a render?
Usually, any computation which requires accurate knowledge of the shape
will require a (slow) render.
However, now that you mention it, bounding box is a special case... By
rendering the object using OpenCSG (the fast "preview" mode) offscreen
from three directions (X, Y, and Z axis, respectively), with
orthographic cameras, it is perfectly possible to get the XYZ bounding
box of an object... But bounding box is not a very accurate measure. At
least it would be computed fast.
One very useful of fast bounding box computation would be to detect if
an object is empty. This makes it possible to detect when parts
overlap, for example, and adjust recursively positions until objects
appear to be in contact (some kind of "slide object X in direction Y
until it rests on another object").
This needs testing.... If I can find some time, I'll check it out. Mybe
we could start with those fast operations, then do the slow ones.
Sebastien
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Hi @kintel, I'm really happy with OpenSCAD but this is kind of a mandatory feature for several engineering and physics projects. I'm currently rendering the STL and using Numpy-STL the center of gravity To be honest, I would support to have the implementation developed by @blobule as it is. You don't need to calculate the centre of gravity every time you make a small change, in the same way, you don't need to render the whole model after every single small variation. What about an opt-in option? I'm kind to get involved in the development in order to make this happen. Actually, I'm working on a model that has different materials with different densities. So, it could be nice to extend this implementation to density-aware structures. Thanks, @blobule for your contribution! Jordi |
There is no disagreement regarding the feature. The question is how to fit this into the language in a way that is not based on magic variables. There were a number of suggestions in the discussions, some are linked above. It should not be needed to call a big black box function with lots of opt-in features. The better strategy would be features that behave the same but can be combined to be more powerful (Composable Building Blocks). Also an important requirement for this type of features is to have enough tests for all cases to prevent accidental changes. The test suite is an important part of making sure OpenSCAD can evolve at all. |
Hello everyone,
After seeing recent requests for a feature providing shape information
(bounding box, center of mass, volume, ...), which I implemented
experimentaly as "probe()" a while ago, I am interested in making these
feature work properly in openscad.
The main problem is this: how to you return a scalar (or vector) value
computed on a shape?
Openscad offers functions, which do not take a geometry as parameter,
and geometry operators, which must return geometry, not scalars.
One solution, which is not great I admit, is magic variables...
probe() geometry(); // does render() if needed and set magic variables
echo(boundingBox);
echo(centerOfMass);
echo(volume):
May I suggest another approach?
We could rely on module to "name" the geometry:
// Any module without parameters is actually "naming" this geometry.
// Name this geometry "test"
module test() { geometry(); }
echo( test.volume )
echo( test.boundingbox )
echo( test.centerOfMass )
When you call a module without (), then a render() is be performed on
that module called without parameters. The resulting geometry would be
used to compute some value which is returned.
So... magic variables? functions on named geometries?
Any other way?
Sébastien
…On Tue, 2020-04-28 at 04:31 -0700, Torsten Paul wrote:
There is no disagreement regarding the feature.
The question is how to fit this into the language in a way that is
not based on magic variables. There were a number of suggestions in
the discussions, some are linked above. It should not be needed to
call a big black box function with lots of opt-in features. The
better strategy would be features that behave the same but can be
combined to be more powerful (Composable Building Blocks).
Also an important requirement for this type of features is to have
enough tests for all cases to prevent accidental changes. The test
suite is an important part of making sure OpenSCAD can evolve at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Openscad2 is a future project, right? |
No, it's a path to an improved language, not a coding project. Quite a number of things suggested there are already integrated into the dev snapshots and more to come step by step. Most importantly function literals are working, making functions first class citizens. It also serves as guidance to go for things like composability instead of creating monsters like |
I'll chime in and lend my support for integration of even a slow feature that requires render() to retrieve bounds of a given 3D component. Heck, make it disabled unless you explicitly enable in preferences or require a flag at application launch... For non-random generative applications that don't have frequently changing parameters - esp. when I'm integrating objects into a complex assembly from STL or other libraries that may change when I change local parameters (i.e. if I'm using Customizer), at least let me call Meantime, to compensate for the absence of this functionality, I implemented my own OO ruby-based command line tool to compile to openscad (and allow for the use of variables to reference identical objects that get mirrored across axes, etc). I'd strongly suggest reconsidering this prior to implementation of Openscad2... require manual enabling, go ahead and make it more efficient later on - but this is crazy-essential for a lot of us. The time consumed by implementing workarounds and to maintain them as we update our language version is undoubtably >> the time it would take to do a low-fidelity render($fn=5) call. (If pentaradial symmetry is good enough for echinoderms, it's good enough for returning bounding box dimensions in most use cases 🤓) |
Again, OpenSCAD2 is NOT some kind of future project or version which could be blocking other things, it's pretty much the opposite. It's a guideline how to integrate new features without breaking backward compatibility. So if at all, it exists to help integrating features like this one. The argument "make it better later" does not work for this kind of changes. Once a language feature is released it's hard to change. If people would like to see that feature, I'd suggest helping with the design by discussing ways for integration. |
Hi,I was told a few times, and I understand, that there are no great ways to integrate geometry information (bounding box, volume, centroid and more) into the openscad language, openscad2 or not.I proposed a few approaches, all rejected. So anyone has any suggestion on how to return computed information on geometry in openscad without breaking compatibility? How about creating a new module info() which returns not geometry but numeric results and could be used in expressions?V=info("volume") sphere();Openscad needs a bridge from geometry to expressions... Can openscad2 offer a guideline for this?Le 11 août 2020 11 h 41 a.m., Torsten Paul <notifications@github.com> a écrit :
Again, OpenSCAD2 is NOT some kind of future project or version which could be blocking other things, it's pretty much the opposite. It's a guideline how to integrate new features without breaking backward compatibility. So if at all, it exists to help integrating features like this one.
The argument "make it better later" does not work for this kind of changes. Once a language feature is released it's hard to change. If people would like to see that feature, I'd suggest helping with the design by discussing ways for integration.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.
|
I cannot understand how the work and engagement of @blobule in order to provide a solution to the need of probably most typical OpenSCAD users, can be blocked and deferred for such a long time now, in favor of some pointless academic theories. Do you want to have a dinosaur that will die out in a few years, or a living and evolving species that, even when not evolution's perfect product, will change and adapt to actual real world challenges? When you cannot (after all the years) settle on merging contributions like blobules to the main code base, then at least provide an extension mechanism that allows easy plug-ins of user language extensions. |
This'd be really nice to have as a user. |
In the meantime it is 2022 and (afaik) there is still no way to calculate a volume in OpenSCAD. Even if the code is there. |
More useful feedback would be looking at #3956. |
Hi, and happy new year to all OpenSCAD enthousiasts.
Le 2022-01-01 à 12 h 29, davrandom a écrit :
In the meantime it is 2022 and (afaik) there is still no way to
calculate a volume in OpenSCAD. Even if the code is there.
Message ID: ***@***.***>
Yes... my pull request was in 2016... time flies :-)
I will not submit a new pull request for now, as I feel that consensus
has not been reached about how to incorporate geometric measures in
OpenSCAD.
However, if anyone want to use the feature, I made a fork with the
probe() feature, with examples :
https://github.com/blobule/openscad/tree/probe
<https://github.com/blobule/openscad/tree/probe> (make sure you use the
*probe* branch ).
openscad examples
The probe() module does the following:
* compute the bounding box. Great for resizing/aligning
anything,including imported STL.
* identifies empty or non empty geometry (to detect contact between
objects)
* optionally compute volume and center of mass
Probe makes it possible to perform a binary search for making two
objects touch each other, for example.
You must remember that probe() can' t compute anything without first
doing a "render", so you will lose some speed on the F5 preview.
However, the cache works fine, so its not that bad. In any case, probe
provides info that is usually worth waiting for... just make sure you
use it sparingly, only when needed.
I welcome feedback on this, and I will be happy to discuss how to
properly integrate this into OpenSCAD permanently, if the community
wants to go that way.
Best regards,
Sébastien
|
I'm less interested in a
Just a few additional staistics can be added to that list. I don't care if the volume, centroid, etc. are for all the parts being rendered at once. If I want to see it for a single part, I can just suppress the others. I mean, if you have to render it anyway to do this calculation, then it may as well be included the console output. Putting it there, instead of implementing as a script command, would remove all controversy about this feature requiring rendering. It can simply be included in the rendering process. |
PR#4478 provides this feature. |
@jordanbrown0 I don't see anything in PR #4478 about volumes or centroids, only bounding boxes. |
Ah, sorry. I missed / forgot the "volume" part, and confused "centroid" with "center". But it's at least a step closer. I believe there are techniques that can be used to derive the volume from the list of triangles, but I am not enough of a mathematician to be sure. |
Applying that algorithm directly to the output from 4478's render() is awkward because it wants triangles and 4478's render() can yield non-triangles. As the Wolfram page says, you can triangulate arbitrary polygons, but that's tedious. Well... I tried a cheesy triangulation algorithm against a couple of simple shapes, and give or take the fact that a single-object model gets the sign of the volume wrong, it looks right. (I suspect that the reason that it gets the sign wrong on single-object models is that CGAL doesn't actually get involved, and the non-CGAL result is in some way backwards.) But again I'm not really enough of a mathematician to be sure that what I'm doing is right. Here's that program. Of course most people don't have a 4478 build and can't run it, but you could build your own faces array.
yields:
|
https://mathworld.wolfram.com/PolyhedronCentroid.html |
Hmm. That triangulation algorithm only works for convex polygons. Still, there are other triangulation algorithms that actually work. |
Hi everyone, its nice to see that volume/centroid/bounding box might finally be added to openscad. In probe(), in order to compute the volume, you must first decompose the nef-polyhedra into a union of convex parts. Then you add the volumes computed on each convex shapes. |
A new attempt at making a valid pull request for probe() functionality.