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 <doug@moens.org> 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 > Discuss@lists.openscad.org > 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 <ben@autonomic.net> 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 <doug@moens.org> 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 >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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 <doug@moens.org> 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 > > Discuss@lists.openscad.org > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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/