Renderer Independent Design
Opened this issue · 4 comments
This paper is relevant to designing a "unified" modeling system with different rendering back ends as your project Descartes proposes (sorry about the horrid formatting of the PDF):
http://papers.cumincad.org/data/works/att/acadia11_196.content.pdf
Not to discourage you (I like difficult challenges myself), but I think it is going to be hard in general to create a unified modeling language for all the various techniques like filleting, sweeping, etc. found in mechanical design.
Thanks for sharing! That is a very interesting paper I will have to study further.
I agree the "unified" platform is difficult, but this is a research project and failure is always a valid experimental outcome. :)
To be honest, I am less concerned right now with the unification of geometry, and I may want to re-word the readme. I've worked on GeometryTypes.jl, and it is exceedingly difficult to have a one-size fits all system for the FEM, GIS, Visuals, etc. groups. However, I do think the system in place here is pretty flexible and unique in the sense that the geometric representation is compiled to machine code without any intermediate AST.
Conversely, that is the lock-in and lack of portability the authors are lamenting.
Right now I am working on FEA integration and feature-parity with OpenSCAD. My research focus is more heading towards mesh-free analysis methods and topology optimization. Within the next few months I will have parametric studies using traditional FEA tools link into this platform.
Let me rephrase that, "Please continue working on this interesting project." :)
You know, it can't be a failure because it seems I already learned that (correct me if I'm wrong) R-functions are still useful in areas where you need C1+ continuity. I have only been studying the design part of F-rep, and not the analysis like FEM.
A while back, I did my own analysis of the feature set SolidWorks (CATIA). I would like to have our system achieve some degree of parity with that product--the design part anyway.
That sounds awesome, and it is really nice you got to talk to Vadim Shapiro. It looks as though you are in RTP. There is definitely a big 3D printing community there, and I am sure there should be some good partnerships with companies (if your company already isn't in 3D printing of course). Functional representation is most likely the optimal for additive manufacturing technologies.
Going back to the rosetta paper, I think in the future there might be some sort of runtime associated with a solid model. From what I understand Rosetta proposed a description format that can target several different modelling tools. Whereas, I think the inverse problem is more salient. There needs to be an output that captures the richness of the design tool but is also portable. Technologies such as webassembly should make it possible to ship the geometry in an executable that can be queried by a display or manufacturing device. In this way, it is not a static representation, but can generate output and parse inputs as required. For example, glTF is a good step in this direction, but does not allow for input: https://www.khronos.org/gltf/
Section 1.1 of this paper has a good discussion of (user) shape representation criteria:
https://thesis.library.caltech.edu/2865/1/Snyder_jm_1991.pdf