Hi there,
I was blown away when I found OpenSCAD last week - it feels like the modelling tool I’ve always been waiting for - and it’s also turning into an opportunity to think more about functional programming ;-) The first thing I built has been a VR headset to be laser cut out of ply. I’ve parameterised it to accommodate different head shapes, eye distances, eye strengths, glasses etc. The parts fit together with slots and tabs, so I use OpenSCAD to union the tabs with some parts, then intersect them with others to create the slots where the tabs will need to go. Finally, I iterate over all the modules describing the parts, putting them together and then translating them back to a single surface so I have a description of the parts to be cut. === The bit I don’t get: === I’ve started thinking about what it would take to have rounded edges on the headset. The “rotate extrude” operator will do this just fine… but if I then intersect this with tabs on that curve, I want to be able to flatten that curved element to the flattened cube from which it would be bent, and which would still contain those tabs to be lasered from the material. Is this clear? I put a small drawing here to explain a little more what I mean : https://cloud.eyeskills.org/s/iiTApF73Lg4bFFA Does anybody have a hint/suggestion how I might approach this “unwinding” of the extrusion and rotation? Kindest Regards, Ben _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
My first thought (maybe not understanding exactly the problem is to look at
"living hinges". This is where you laser a series of very fine lines so that you can flex a project; this is a way to then have curved edges on a laser cut. http://forum.openscad.org/Living-Hinges-td18217.html -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
That’s what I was planning on doing :-) But now imagine that you have another perpendicular surface that penetrates it…
In OpenSCAD I’d like to “roll the curved surface” - see where the next part intersects it… then compute the difference of the rolled surface (i.e. with a slot where the other part cuts it)… then “roll” the rolled part “flat” so that I know exactly what to laser cut, so that when I physically roll it back into shape the slot will be in just the right spot for the other part? Does that make more sense? Difficult for me to describe elegantly! > On 22. Jan 2019, at 12:37, shadowwynd <[hidden email]> wrote: > > My first thought (maybe not understanding exactly the problem is to look at > "living hinges". This is where you laser a series of very fine lines so > that you can flex a project; this is a way to then have curved edges on a > laser cut. > > http://forum.openscad.org/Living-Hinges-td18217.html > > > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > [hidden email] > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
You will probably have to do it the "long" way ... use the arc length of your
curved surface (radius & angle) to calculate the offset of the slot. https://www.mathopenref.com/arclength.html If you have a complex curve that can't be calculated easily, export to inkscape and use the "Measure path" tool and go from there.... -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Well, I guess that’s fine in principle, but it kind of negates the coolest feature of OpenSCAD somehow.
If the user’s eye strength shifts, all I have to do is shift the plate holding the lens moves along the Z axis. The “difference” calculations with the tabs on that plate and the surrounding case automatically (at the moment) produce all the tab holes in the right place. If I go down that route, then I am mixing two totally different approaches towards doing things - where I’m implicitly forming holes based on simulating construction, and another where I’m explicitly defining holes based on replicating a bunch of calculations about where the tab should be (which may require replicating a *lot* of steps as different groups of assemblies are moved into position). I hope there’s another way? > On 22. Jan 2019, at 13:33, shadowwynd <[hidden email]> wrote: > > You will probably have to do it the "long" way ... use the arc length of your > curved surface (radius & angle) to calculate the offset of the slot. > > https://www.mathopenref.com/arclength.html > > If you have a complex curve that can't be calculated easily, export to > inkscape and use the "Measure path" tool and go from there.... > > > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > [hidden email] > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by okobloko
okobloko wrote
> In OpenSCAD I’d like to “roll the curved surface” - see where the next > part intersects it… then compute the difference of the rolled surface > (i.e. with a slot where the other part cuts it)… then “roll” the rolled > part “flat” so that I know exactly what to laser cut, so that when I > physically roll it back into shape the slot will be in just the right spot > for the other part? Congratulation, this is a quite ambitious project - especially for somebody who started with OpenSCAD only a week ago. Despite all its merits, OpenSCAD also has its drawbacks that pop up in the moment you want to do really fancy stuff. One is, that it doesn't allow you to query an object. Therefore you don't get hands on the vertex coordinates of an object. Being able to access these coordinates you could think about defining a reverse transformation function that unrolls the object ... Another one is that you can't define and apply non-affine transformations on objects. Rolling and unrolling would be such a transformation. rotate_extrude() is an operator that maps from 2D into 3D. You are looking for an operator that maps from 3D to 2D. The only one OpenSCAD offers is again affine: projection() However, there is a technique that rolls a 3D object along a plane, cuts slices by means of intersection() and unions the result. But this is an exhausting and slow process with an unsatisfactory result. <http://forum.openscad.org/file/t887/CWCCW.png> See the following code: r=40; // radius a=4; // height b=50; // width resolution = 8; i=180*$t; // to animate select view/Animate and set FPS=10, Steps=40 animate(); unroll(i); // module animate() { rad = i/180*PI*r; rotate([0,90,0]) translate([-r-5,rad,0]) rotate([0,0,-i]) piece(); # translate([0,rad,0]) window(resolution); } module unroll(j) { for(i=[0:resolution:j]) { rad = i/180*PI*r; intersection() { rotate([0,90,0]) translate([-r-a,rad,0]) rotate([0,0,-i]) piece(); translate([0,rad,0]) window(resolution); } } } module window(width) { translate([0, -width/2, 0])cube([b, width, 2*a]); } module piece() { difference() { rotate_extrude(angle=180) translate([r, 0]) square([a, b]); rotate([-60, 0, -45])cylinder(r=5, h=100); } } -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
A repost of the image, because nabble seems to crossref uploads using the
same filename. <http://forum.openscad.org/file/t887/unroll.png> -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by Parkinbot
:-) I actually love this approach. Unfortunately it won’t produce results that will work well for a laser cutter I suspect… but it’s still great :-)
Do you think non-affine transformations might be on the cards for OpenSCAD at some point? I didn’t do anything clever (ten hours work from first opening OpenSCAD, and it shows :-/ ) but to give a clearer idea of the situation if you’re interested: here’s the file I was working on without rounded edges https://cloud.eyeskills.org/s/CbcqJH4eisoqRfa > On 22. Jan 2019, at 15:12, Parkinbot <[hidden email]> wrote: > > okobloko wrote >> In OpenSCAD I’d like to “roll the curved surface” - see where the next >> part intersects it… then compute the difference of the rolled surface >> (i.e. with a slot where the other part cuts it)… then “roll” the rolled >> part “flat” so that I know exactly what to laser cut, so that when I >> physically roll it back into shape the slot will be in just the right spot >> for the other part? > > Congratulation, this is a quite ambitious project - especially for somebody > who started with OpenSCAD only a week ago. > > Despite all its merits, OpenSCAD also has its drawbacks that pop up in the > moment you want to do really fancy stuff. One is, that it doesn't allow you > to query an object. Therefore you don't get hands on the vertex coordinates > of an object. Being able to access these coordinates you could think about > defining a reverse transformation function that unrolls the object ... > Another one is that you can't define and apply non-affine transformations on > objects. Rolling and unrolling would be such a transformation. > rotate_extrude() is an operator that maps from 2D into 3D. You are looking > for an operator that maps from 3D to 2D. The only one OpenSCAD offers is > again affine: projection() > > However, there is a technique that rolls a 3D object along a plane, cuts > slices by means of intersection() and unions the result. But this is an > exhausting and slow process with an unsatisfactory result. > > <http://forum.openscad.org/file/t887/CWCCW.png> > > See the following code: > > r=40; // radius > a=4; // height > b=50; // width > resolution = 8; > > i=180*$t; // to animate select view/Animate and set FPS=10, Steps=40 > animate(); > unroll(i); // > > > module animate() > { > rad = i/180*PI*r; > rotate([0,90,0]) > translate([-r-5,rad,0]) > rotate([0,0,-i]) > piece(); > # translate([0,rad,0]) window(resolution); > } > > module unroll(j) > { > for(i=[0:resolution:j]) > { > rad = i/180*PI*r; > intersection() > { > rotate([0,90,0]) > translate([-r-a,rad,0]) > rotate([0,0,-i]) > piece(); > > translate([0,rad,0]) window(resolution); > } > } > } > > module window(width) > { > translate([0, -width/2, 0])cube([b, width, 2*a]); > } > > > module piece() > { > difference() > { > rotate_extrude(angle=180) translate([r, 0]) square([a, b]); > rotate([-60, 0, -45])cylinder(r=5, h=100); > } > } > > > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > [hidden email] > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
> Do you think non-affine transformations might be on the cards for
> OpenSCAD at some point? It's a lot of work to implement properly. First, non-affine transformations can introduce self-intersections, and make the mesh non-manifold. So we would need automatic mesh repair to fix a transformed mesh before a boolean operation could be applied to it. Second, consider twisting or bending a cube or a cuboid. You would need to subdivide the existing faces into smaller faces, add more vertices, before applying the transformation. So we'd need a mesh subdivision operation. Third, non-affine transformations like bend can cause vertices to get farther apart in some regions, and closer together in other regions. If you have first subdivided the mesh finely enough to handle the worst case regions of the shape, then after the transformation, you may need to simplify the mesh in the areas where there are more vertices than necessary. So automatic mesh simplification is another operation that would be useful to have. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by okobloko
okobloko wrote
> Unfortunately it won’t produce results that will work well for a laser > cutter I suspect… but it’s still great :-) As I wrote, it is not fast, but it will work with a laser cutter if you project it down and and export it as DXF or SVG. Of course the rounded face at least needs a form that can be mathematically explicitly expressed and unrolled. Use my code and try projection() unroll(180); okobloko wrote > Do you think non-affine transformations might be on the cards for OpenSCAD > at some point? We've had discussions about this years ago, when I was starting with OpenSCAD. Meanwhile I've lost hope to see solutions for both of the mentioned drawbacks. If you have another language, you can use it to parse an STL, apply any non-affine transformation you like, write it out and reimport it to OpenSCAD. However, as Doug already mentioned, the task is not trivial as it can involve a lot of additional considerations and work and it requires you to know exactly what you do. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by doug.moen
This is very interesting. Is this still novel enough (or could it be cast in such a way) that a computer graphics research group might be interested in taking on that challenge?
Two decades ago (!) I implemented the world’s first/second (it’s not quite clear) beam tracer (tracing ray cross-sections rather than ray paths) and thought that was quite clever, but I can see that this is another order of magnitude more difficult than that little project. Perhaps it might actually, given the nature of the language, be an interesting research problem for a mathematician to explore? I’ll re-post this in our community just in case anybody has any ideas or leads! > On 22. Jan 2019, at 23:32, Doug Moen <[hidden email]> wrote: > >> Do you think non-affine transformations might be on the cards for >> OpenSCAD at some point? > > It's a lot of work to implement properly. > > First, non-affine transformations can introduce self-intersections, and make the mesh non-manifold. So we would need automatic mesh repair to fix a transformed mesh before a boolean operation could be applied to it. > > Second, consider twisting or bending a cube or a cuboid. You would need to subdivide the existing faces into smaller faces, add more vertices, before applying the transformation. So we'd need a mesh subdivision operation. > > Third, non-affine transformations like bend can cause vertices to get farther apart in some regions, and closer together in other regions. If you have first subdivided the mesh finely enough to handle the worst case regions of the shape, then after the transformation, you may need to simplify the mesh in the areas where there are more vertices than necessary. So automatic mesh simplification is another operation that would be useful to have. > > _______________________________________________ > OpenSCAD mailing list > [hidden email] > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Let me go a bit further : I have spoken (enthused) to the prototypefund.de about OpenSCAD and they are interested in funding somebody doing open source work on it. They would give a six month grant (47k EUR) to a person or a team which live in Germany.
It’s very very little bureaucracy, and I can help where necessary in answering any questions. Is there anybody who could actually do the work? B > On 23. Jan 2019, at 09:40, Ben Senior <[hidden email]> wrote: > > This is very interesting. Is this still novel enough (or could it be cast in such a way) that a computer graphics research group might be interested in taking on that challenge? > > Two decades ago (!) I implemented the world’s first/second (it’s not quite clear) beam tracer (tracing ray cross-sections rather than ray paths) and thought that was quite clever, but I can see that this is another order of magnitude more difficult than that little project. Perhaps it might actually, given the nature of the language, be an interesting research problem for a mathematician to explore? > > I’ll re-post this in our community just in case anybody has any ideas or leads! > >> On 22. Jan 2019, at 23:32, Doug Moen <[hidden email]> wrote: >> >>> Do you think non-affine transformations might be on the cards for >>> OpenSCAD at some point? >> >> It's a lot of work to implement properly. >> >> First, non-affine transformations can introduce self-intersections, and make the mesh non-manifold. So we would need automatic mesh repair to fix a transformed mesh before a boolean operation could be applied to it. >> >> Second, consider twisting or bending a cube or a cuboid. You would need to subdivide the existing faces into smaller faces, add more vertices, before applying the transformation. So we'd need a mesh subdivision operation. >> >> Third, non-affine transformations like bend can cause vertices to get farther apart in some regions, and closer together in other regions. If you have first subdivided the mesh finely enough to handle the worst case regions of the shape, then after the transformation, you may need to simplify the mesh in the areas where there are more vertices than necessary. So automatic mesh simplification is another operation that would be useful to have. >> >> _______________________________________________ >> OpenSCAD mailing list >> [hidden email] >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > [hidden email] > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by okobloko
On Wed, Jan 23, 2019, at 12:40 AM, Ben Senior wrote:
> This is very interesting. Is this still novel enough (or could it be > cast in such a way) that a computer graphics research group might be > interested in taking on that challenge? Hi Ben. I'm already leading my own little research project to create an OpenSCAD-like modelling language that supports non-affine transformations. At this point, we can build a shape from geometric primitives, apply non-affine transformations, and export to STL. We have a "customizer" GUI that lets you connect the angle of twist in the "twist" operator to a slider and animate parameter changes in real time. But to achieve this, we use a different representation for shapes: function representation and signed distance fields. This gives us an exact mathematical representation for primitive shapes, and for the output of non-affine transformations. If you use meshes as an intermediate representation, then you incur a lot of computational expense, and you accumulate approximation errors at each stage in a non-affine transformation pipeline. So my solution is to delay converting the CSG tree to a mesh until the last possible moment. The language is called Curv, and the source code is https://github.com/curv3d/curv. It's a volunteer based open source project. We don't have university affiliation or funding. Also, this project is very much a work in progress. If you want to try it out, be prepared to build it from source, and check the GPU requirements at the bottom of the README. Also, there is no Windows port yet (still waiting for a volunteer for that). > Two decades ago (!) I implemented the world’s first/second (it’s not > quite clear) beam tracer Ben: Thank you for inventing beam tracing. A lot of my work for 2019 will be focused on compiling Curv programs into optimized GPU code, and beam tracing is one of the optimizations I plan to use. Doug Moen. On Wed, Jan 23, 2019, at 12:40 AM, Ben Senior wrote: > This is very interesting. Is this still novel enough (or could it be > cast in such a way) that a computer graphics research group might be > interested in taking on that challenge? > > Two decades ago (!) I implemented the world’s first/second (it’s not > quite clear) beam tracer (tracing ray cross-sections rather than ray > paths) and thought that was quite clever, but I can see that this is > another order of magnitude more difficult than that little project. > Perhaps it might actually, given the nature of the language, be an > interesting research problem for a mathematician to explore? > > I’ll re-post this in our community just in case anybody has any ideas or leads! > > > On 22. Jan 2019, at 23:32, Doug Moen <[hidden email]> wrote: > > > >> Do you think non-affine transformations might be on the cards for > >> OpenSCAD at some point? > > > > It's a lot of work to implement properly. > > > > First, non-affine transformations can introduce self-intersections, and make the mesh non-manifold. So we would need automatic mesh repair to fix a transformed mesh before a boolean operation could be applied to it. > > > > Second, consider twisting or bending a cube or a cuboid. You would need to subdivide the existing faces into smaller faces, add more vertices, before applying the transformation. So we'd need a mesh subdivision operation. > > > > Third, non-affine transformations like bend can cause vertices to get farther apart in some regions, and closer together in other regions. If you have first subdivided the mesh finely enough to handle the worst case regions of the shape, then after the transformation, you may need to simplify the mesh in the areas where there are more vertices than necessary. So automatic mesh simplification is another operation that would be useful to have. > > > > _______________________________________________ > > OpenSCAD mailing list > > [hidden email] > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > [hidden email] > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by doug.moen
doug.moen wrote
>> Do you think non-affine transformations might be on the cards for >> OpenSCAD at some point? > > It's a lot of work to implement properly. > > First, non-affine transformations can introduce self-intersections, and > make the mesh non-manifold. So we would need automatic mesh repair to fix > a transformed mesh before a boolean operation could be applied to it. > > Second, consider twisting or bending a cube or a cuboid. You would need to > subdivide the existing faces into smaller faces, add more vertices, before > applying the transformation. So we'd need a mesh subdivision operation. > > Third, non-affine transformations like bend can cause vertices to get > farther apart in some regions, and closer together in other regions. If > you have first subdivided the mesh finely enough to handle the worst case > regions of the shape, then after the transformation, you may need to > simplify the mesh in the areas where there are more vertices than > necessary. So automatic mesh simplification is another operation that > would be useful to have. I've already written a sweep line face triangulator in OpenSCAD, and I could probably implement the other things, but the inability to get vertex data from the geometry engine basically makes it silly since eventually we'd be stuck re-implementing all of constructive solid geometry to get something useful. The curve for doing heavy modification of OpenSCAD itself to make that possible looked to steep for me, but it seemed like writing an OpenSCAD interpreter for Blender in python should be feasible. Alas, I'm pretty lazy so I ran out of initiative before I got somewhere. -- Sent from: http://forum.openscad.org/ _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |