Sean (May 04 2019 at 02:25): Sean (May 04 2019 at 02:25):This has been shared with a few developers already, but opening the discussion to a broader community for input, feedback, awareness. It's a work-in-progress diagram showing a near-term path for BRL-CAD's major architecture, particularly as it relates to major libraries and a push towards a single graphical application framework. BRL-CAD-Architecture-Prospectus.pdf
Sean (May 04 2019 at 02:43):The main implications of this are in line with the massive consolidation and reduction efforts announced over a year ago (to get command-line apps down below 10 and ged commands below 100), namely that a lot of the complexity that currently exists in command-line form is getting grouped together with related features or eliminated where out of scope, immature, and/or undeveloped.
It indicates we're planning to drop a few major dependencies (like Tcl/Tk for GUI) and adopt a few major dependencies that we've already proofed in some form (like Qt and OSPray for GUI) along with TBB and C++11 for our core runtime, the latter of which is already under way.
Some aspects are heavily dependent on how quickly GUI development matures and whether we can secure dedicated development support, but other work hinted at include integration of 3rd party framework like OSG for scene management, appleseed for advanced rendering, and possible consolidation of BU+BN+BG into a LIBBPR.
Not depicted but intended with this rearchitecting is a change to how BRL-CAD has been historically packaged and deployed. Instead of hundreds of binaries with adhoc conflict with system facilities, adopting modern packaging standards for Mac, Linux, and Windows where there is a singular entry point into our ecosystem that can be made to comply with LSB, iOS, Windows 10, and other common standards.
Sean (Jan 23 2020 at 18:32):Hi All, it's been a year of reflection, so I've updated the architecture diagram. This is in response to code discoveries, development, discussions, and more. Feedback and discussion is of course always welcome, particularly from any of you new guys from GCI seeing things for the first time, and core devs of course.
Sean (Jan 23 2020 at 18:33):BRL-CAD-Architecture-Prospectus.png
Sean (Jan 23 2020 at 18:35):Just a note, but the spacings in the GUI app denote where we currently have code "air gapped" in separate repos. The biggest change is making MOOSE be the main engine and interface through which the GUI represents and interacts with geometry.
Daniel Rossberg (Jan 23 2020 at 18:47):I like the libcad :smiley:
Sean (May 12 2022 at 17:26):@Himanshu Sekhar Nayak diagram is maybe useful context? This isn't the current state, but a proposed direction (at least that I'm slowly working towards)
Himanshu (May 12 2022 at 17:47):Wow so many libraries that I have never seen and heard about it. In my free time, I will look into it. What I understand that MOOSE will be the main kernel where it will take requests from the GUI side and will send to the libraries. It is similar to what I know about OS kernel :sweat_smile:.
Himanshu (May 12 2022 at 17:49):There will be one GUI for total number of command line applications or for each command line application there will be each gui?
Sean (May 12 2022 at 18:02):That's the hope/goal (for me at least) that there will be one primary GUI application environment built on top of MOOSE. There will also be other CLI applications where needed (e.g., for rendering, image and data conversion, scripting needs, etc).
Last updated: Oct 09 2024 at 00:44 UTC