Openscad: Resize and centering

[elalish]

The new Resize command is great, especially for importing STLs, but it doesn't cover the other common problem besides unknown units: unknown origin. I propose adding a "center" argument to resize, which if true, also centers the bounding box of the child object on the origin.

I think it might also be helpful to have a function called "get_center" that takes any child object and returns the 3-vector of the center of its bounding box.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[hroncok]

I would rather see an separate command / transformation for that. E.g. center().

[GilesBathgate]

Here is RapCAD's implementation: http://git.io/wbnFOA

[kintel]

The challenge with a center module is that it cannot generally be done in preview mode since we don't know the correct bounding box for all types of objects. I'm a bit sceptical towards introducing mode modules with this behaviour..

[GilesBathgate]

I am sure we already discussed this before on another bug, where you said pretty much the same thing... To which my response was.... but OpenSCAD already has a bounds() module which introduces this dependency on CGAL evaluation, as does the render() module, and so would probe() as suggested in #301

[blobule]

I am not aware of a "bounds()" module...

resize() is practical because the final shape size does not require rendering to be known, since you specify it when you call resize(). Adding an option "center=true" would allow to predict the final position of an imported stl, not just its final size. I think it would be a useful addition.

However, the previous posters are right... making a "get_center()" module is not the same, since it must do a CGAL rendering _during_ parsing rather than when rendering in order to make the information available in the code.

[GilesBathgate]

My mistake, I meant resize() not bounds(). However resize() does require the bounding box to be known. The current implementation does a CGAL evaluation, and then calculates the bounds from the result. With the resulting bounding box the correct scale is calculated. (In other words resize is just a fancy version of scale() which calculates the correct scaling factor)

[kintel]

The challenge is that, since we require a full CGAL evaluation of the subtree of such modules, the preview can take a long time to calculate. I'm currently trying to reduce how often we do full CGAL evaluations and I'm thus wary of introducing more functionality requiring this. The goal would be that preview always is fast, and as often as possible accurate.

We could look at ways of clearly documenting this, printing warnings, highlighting slow parts of the code, rendering placeholders of not-yet-calculated geometry in preview mode etc.

[GilesBathgate]

Fair enough, I think these features are more suitable for RapCAD in the meantime. I would like to see how the probe() module of issue #301 might fit into RapCAD.

[nophead]

With a large project like Mendel90 I find I have to wrap render() around all my printed parts and vitamins. Without that the F5 preview becomes un-responsive. I.e. it can render small things quickly but for a complicated scene the individual components need to be rendered with GCAL and cached anyway.

When I work on a module that produces a printed part I have to not have a render in it, or it takes too long to see changes, but when I include it into an assembly I add the render at that point. The assembly is slow to render the first time I view it after changing the printed part, but is quick after that so I can add screws, etc and see the result very fast (as all vitamins contain a render() and so are cached.

This is the only way I find it practical as OpenCSG has limits to the complexity it can handle. Not only becoming unresponsive but also gives Z buffer artefacts where negative volumes in different objects collide. CGAL doesn't have these issues, but is very very slow.

[elalish]

For what it's worth, I really only see the utility of either "center" or "resize" with respect to importing objects. If the unknown render box is the issue, I'd be just as happy having that functionality simply as arguments to the import command.

[kintel]

I tend to agree.
We've also discussed redesigning import in a similar way as RapCAD, e.g. myobj = import<file.stl>;.
..and then implement queries against the imported object, e.g. functions/metods like myobj.center(), myobj.bbox(). This would make the compilation being independent of geometry, but it can also be seen as an alternative way of importing modules, plus we already have similar hacks implemented for DXF files.

Further down the road, we could discuss features supporting things like @blobule is trying to do, by defining dependencies on modules _instances_ in addition to module _definitions_. Queries could be then made available on module instances, and we can perform automated multi-pass compilation by building dependency graphs (like makefiles). This has, as mentioned, potential for breaking a lot of existing assumptions, so we should take our time figuring this out..

[kintel]

See #621

[stemark]

It's not that hard to approximate the center if the piece is at all symmetrical.
Just mirror the piece and then mess with the offset until the two images align.

If you really want to get close then you can difference() them.

module piece(){
import("file.stl");
}

off=[-10,-10];

%translate(off)
piece();

mirror()
%translate(off)
piece();