@Daniel Rossberg There's been a team of students working on a V&V interface for geometry that is built on top of Arbalest. From a user's perspective, they've added a "compile" button next to the rendering button that presents the user with a suite of tests that can be run (e.g., are there overlaps; is there a title set; are there any region ID, los, aircode mismatches; are there regions within regions; etc). Results display in a table view similar to how warnings are displayed in MSVC.
What are your thoughts on either keeping it separate or integrating it back?
I'd like to integrate it back so it continues to benefit from the improvements you and @Himanshu Sekhar Nayak have been making, and would likely be a tool that will continue to receive attention as this is intended to become a new production capability that can audit, report on, help visualize, and (later) potentially fix geometry issues.
I like the idea of integrating it back. What is this V&V compilation based on? Before, you said libged. This would however have the touch of a bad hack (based on what was available to them). Not a show stopper, but doing it right would need some additional work.
In addition, a plugin like architecture for including such extensions in arbalest would be desirable. Hacking is easy, but hard to maintain.
@Daniel Rossberg Yes, it's still based on calls into libged, specifically just ged_exec(), calling commands for which there is no other API or mechanism available to do the testing it's doing (e.g., running "lc -m" to detect mismatches or sifting through gqa output to see if objects are unhittable or testing conversion via facetize, etc). The calls are encapsulated through a single call site -- essentially calls ged_exec() and parses what a given test needs out of the results, which varies from command to command and is expected to change (and get expanded to other tests+parsings).
Here's a few screenshots of the current progress:
Screen-Shot-2022-11-10-at-8.37.05-PM.png Screen-Shot-2022-11-10-at-8.39.54-PM.png Screen-Shot-2022-11-10-at-8.41.00-PM.png
There's a new button next to the render button that kicks off the test. The menu option still needs to go away / get hidden under a settings section.
I have a binary build ready for testing if you or anyone else wants to try it out. They would love to have feedback (scope is fixed, but they have a couple weeks remaining to make changes).
It can also be compiled from their fork of the arbalest repo.
It would be interesting to see how it was done, even if the code is not suited to be integrated back. Himanshu wants to port arbalest to MOOSE after his GSoC project. This would make CommandString
available there.
I would actually hope it's suitable to be integrated back or get a list of issues preventing integration. I have a binary for Windows that can be tested and the code is at http://github.com/isaacy13/arbalest
A binary is available at https://brlcad.org/~sean/tmp/GeometryV&V.zip (570MB)
On a related note -- any idea why the OpenGL context wouldn't be working once deployed/copied to another system? I tried QT_OPENGL=desktop, angle, and software to no avail. Tried setting QT_OPENGL_DLL too. It raytraces to a window (and displays that image just fine), so it's something specific to the context I presume.
Sean said:
I would actually hope it's suitable to be integrated back or get a list of issues preventing integration. I have a binary for Windows that can be tested and the code is at http://github.com/isaacy13/arbalest
I'll have a look at it.
Sean said:
On a related note -- any idea why the OpenGL context wouldn't be working once deployed/copied to another system? I tried QT_OPENGL=desktop, angle, and software to no avail. Tried setting QT_OPENGL_DLL too. It raytraces to a window (and displays that image just fine), so it's something specific to the context I presume.
Do you have dynamical run-time-library linkage? The are probably more DLLs needed than just the C-runtime. You could try to install the Visual C++ Redistributable at the target systems. Or is a Qt-plugin needed? Have you checked it wit a dependency walker?
I prefer however the static linkage of the Visual Studio and Qt libraries. I had no issues with OpenGL with it so far.
Unless something was missed, the zip includes the c++ redistributable dll's -- and since it's a debug mode compile, it throws up a dialog for dll's that are missing. They're using arbalest's existing build files and just added their new files, so whatever linkage it was doing is what it should still be doing. I think the only library added in addition to Qt was sqlite, which is used as a results storage mechanism.
I'm not familiar with any dependency walkers on Windows. What's the equivalent of ldd or otool ?
Daniel Rossberg said:
I'll have a look at it.
If you can provide feedback before Tuesday, that would be awesome. App or source code feedback. They'd really appreciate it.
If you can provide feedback before Tuesday, that would be awesome. App or source code feedback. They'd really appreciate it.
I'm away these days, but I'll see what I can do. Maybe next weekend.
Dependency Walker is like ldd.
There are at least two showstoppers for a direct integration back:
I think that it would make more sense to integrate these V&V routines in qged. As far as I understood, this is a (kind of a) port of Arbalest to BRL-CAD's basic C API. There, the standard BRL-CAD installation will always be around and you have access to the internal database handles, e.g. rt_wdb. In the original Arbalest the routines feel out of place.
@Daniel Rossberg I certainly understand the first bullet, though I think the scope could probably be limited to libged and the libged plugins that it calls into. I think there are some libbu directory management routines (e.g., where's the system cache) it's calling that could potentially be integrated under the C++ api.
At least originally, my thinking was that the V&V modifications would be plugin extension(s), using arbalest as an app platform so it can leverage from the GUI infrastructure, display/selection features, and the Qt facilities.
I'm not sure I understand the second bullet about not working on the Arbalest document though -- can you elaborate? The V&V checks are performed read-only. The only thing written out should be a corresponding sqlite database that is stored in the cache folder (so when you return to that .g later, it can keep track of any changes made).
Daniel Rossberg said:
I think that it would make more sense to integrate these V&V routines in qged. As far as I understood, this is a (kind of a) port of Arbalest to BRL-CAD's basic C API. There, the standard BRL-CAD installation will always be around and you have access to the internal database handles, e.g. rt_wdb. In the original Arbalest the routines feel out of place.
Personally, I'm not happy with there being two Qt efforts as they're highly duplicitous. I really don't think it's helpful to split up development capacity like that.. I'd like to move towards the architecture plan I'd shared a while back where there's a new (Qt) GUI built on top of the C++ API but is also able to access ged commands. Basically, the merge of qged+arbalest. qged has a fantastic CLI and 3D display, but not as good on the overall appearance, usability, and cleanliness of the document management and underlying architecture encapsulation. We have talked a bit about what it'd take to merge them, leverage the best of both. I think there's real potential there.
If I'm alone in that, c'est la vie I suppose... but I feel compelled to try! I really do think we finally have all the underlying pieces needed to replace mged in a big way, and they're currently spread across arbalest, rt^3/coreInterface, qged, libged, librt, and ospray.
A naive question about Arbalest's intent longer term - is it intended to eventually replace MGED?
The talk about "Documents" sounded rather awkward for things like command line scripted processing, but that may just be my own limited understanding.
In this context, document refers to the MDI model that arbalest is leveraging in Qt. It's a standard app model for discretely managing separately open contexts.
Basically "document" is an open .g file. Has nothing to do with the type of the file and doesn't imply documentation or a text file and such.
When we have more time I guess we should do an in-depth discussion about the details of the various interfaces' design features of qged and Arbalest.
The two biggest differences, in my view, is that arbalest has clean classes (clean code) and encapsulation. There's no data being accessed without going through an object that is responsible for or represents that data. That is, clean object-oriented definitions.
That makes it super easy to follow from a CS perspective. No side effects, no gotchas. It's almost text-book.
I've put a fair bit of effort into developing a Qt-style model for the .g file state - has Arbalest done that?
qged is much more procedural in design. There are classes by necessity where interfacing with Qt, but data is not encapsulated as much, and definitely not in a classical OO paradigm.
starseeker said:
I've put a fair bit of effort into developing a Qt-style model for the .g file state - has Arbalest done that?
I'm not sure what you mean by that. I think the answer is a strict yes -- that's fully encapsulated in the aforementioned C++ api (rt^3/coreInterface) and a class representing that object.
I mean you can see some stark differences of the clean oo vs procedural that I'm referring to simply by looking at main() in both. It extends throughout the code base, in general.
So if the command line adds or removes comb tree elements, the Arbalest tree is automatically updated?
For example, in arbalest, the window is all encapsulated within a MainWindow class. Main is short and sweet, and would be not much changed even if we introduced a CLI-only mode or made it support settings/options/etc.
In qged, there's a BRLCAD_MainWindow (and CADapp, both expected) also. But most of the rest is de-encapsulation. There's procedural handling of console (instead of having a Console and GUI app classes that inherit from a base), procedural option handling (which should be handled by the app), some hard-insertion of settings for QOpenGLWidget that doesn't belong there, some theming stuff (that probably belonged in the window class), settings ... and more, but you get the idea (hopefully?).
It's not a critique, it's simply very different technical approach and has different coding practices.
<nod> I think I do. I guess I gravitate towards that approach at this stage because I'm still figuring out what the necessary pieces of the puzzle are, and it's easier (at least for me) to be able to adjust and tweak the procedural flows in a few pieces rather than having to unpack (and potentially re-design) the encapsulations during the design iterations. Probably says more about my own limitations than anything else... it may be that qged simply ends up informing another design, in the end.
That said, there are some very specific things that qged can currently do in a technical sense, that from my perspective would absolutely have to be present and working at scale in an alternative solution before it I could regard it as a viable alternative.
The issue from a coding perspective is that style of procedural is very much like having a messy desk and saying "I know where everything is" ... that only works for one person.
It's also still procedural and that does not translate to good OO.
Moreover, if there wasn't perceived value keeping it neat and tidy in the first place, that's demonstrably not likely to change and is still an issue for anyone else regardless. When that's done across dozens of files, the learning curve becomes increasingly difficult with every de-encapsulated chunk of code.
Just looking at qged's main, we could probably talk for hours to transfer understanding for everything going on in there, why it's in there, where it possibly belonged if it were done properly, etc., and that's all on top of whatever effort that would be and hoping there's no side-effects for data tangled or implied.
That conversation literally doesn't exist in arbalest's main (or any of the other classes for that matter). The learning curve is flat.
That's also why the capstone team was able to run with it. I had them look at both.
starseeker said:
That said, there are some very specific things that qged can currently do in a technical sense, that from my perspective would absolutely have to be present and working at scale in an alternative solution before it I could regard it as a viable alternative.
I definitely agree with you there as well. The command line and graphics displaying is superior from an end-user functionality perspective. The hierarchy view might have a leg up too, but I've not looked as closely. That is part why I was asking a few weeks ago how encapsulated/encapsulatable they are those.
They're definitely not OO, but it might not be terribly difficult to bridge what they use down through the same classes.
Here's a quick example of the draw_rework ability to integrate selection behavior from command line and GUI with drawing highlighting and tree highlighting: qged_select.gif
I don't understand everything going on there, but I like the rect and point select. Those would be good to have as default shift key bindings instead of having GUI widgetery.
What did select collapse and select expand do?
Change what particular level of selection was active in the tree paths. A graphical selection always selects the full path - i.e. /a/b/c.s This is the case even if every solid under b is selected.
So if we have /a/b/c.s and a/b/d.s both selected, but don't have /a/e selected, a collapse can shift the selection "up" the tree to /a/b since all of b's components are active.
If the full definition of /a is /a/b and /a/e, and all of /a/b and /a/e 's child solids are selected, we can collapse the selection to /a
Why wouldn't you always want to collapse? Or always not collapse?
For editing purposes, you may specifically want your matrix applications to be at lower levels.
As a general design principle, you want to be able to select any instance at any level of the hierarchy, or sets of them.
With multiple applications of select and remove operations, you can zero in on comb instances graphically
Sorry, I'm acting as a distraction.
I can see that I guess, it's just the usability seems awkward. It's a degree of freedom that seems like will have many edge cases .. especially assuming you allow expanding down to primitives..
btw, 'collapse' and 'expand' don't sound intuitive to me, maybe another verb describing the action
maybe lift and lower ?
or even maybe push/pull if that doesn't conflict
when in selection mouse mode, could make shift+mouse do select and shift+drag do band select, both adding to the selection set. creo does that and uses shift+double-click to deselect. select nothing or hit esc to deselect all.
Phew, that's a long thread. I want however start with this one:
starseeker said:
A naive question about Arbalest's intent longer term - is it intended to eventually replace MGED?
From my perspective, Arbalest is a test case for an application build on top of the C++ interface. I don't have the time to build an mged replacement. Instead, I'm interested in perfecting this API. It works well for my day job, but there may be others who would want to use it too, if it provides the functionality they need. Regarding this aspect, this V&V effort was unfortunately a failure.
For an alternative way of doing this V&V stuff, look at CommandString in MOOSE.
Some additional words about "perfecting" the interface: There is of course the API side: Headers, classes, ... But, I consider the system architecture (is this the right word?) too. I.e., the files necessary to provide the functionality. For example, it shall be possible to provide Debian libbrlcad and libbrlcad-dev packages which are doing just this: Providing a shared object and the header files to use it.
Document orientation: Arbalest shall show a behavior like people familiar with an office suite would expect: They can open a file, view its content, change it, save the changes or discard them. Most other programs behave the same way. vi doesn't write the file after each key press but after the !w command. To achieve this, Archer works on in-memory databases.
I.e., I see Arbalest more as a technology demonstrator. In this spirit, the MouseAction class was introduced too. It implements a design pattern which allows you to manage the different kinds of interactions you can have with the geometry: Changing the view (zooming, shifting, rotating, ...), changing the geometry (resizing, moving, create and delete something, ...), selecting, ...
This doesn't however mean that nobody else can have bigger intentions with Arbalest. As long as they don't collide with my goals, I'll support them. If they collide - well, it's open source.
My and/or Himanshu's next steps will be to integrate the open pull requests in Arbalest (nothing is forgotten there, just short in time) and to port the program to MOOSE then. I see MOOSE as the attempt to make an own "product" from rt-cubed's coreIntercace "prototype".
Sean said:
I'm not sure I understand the second bullet about not working on the Arbalest document though -- can you elaborate? The V&V checks are performed read-only. The only thing written out should be a corresponding sqlite database that is stored in the cache folder (so when you return to that .g later, it can keep track of any changes made).
See lines 570ff in isaacy13's MainWindow.cpp. Arbalest works with in-memory databases, but the V&V tool want's to use ged_open with a file path.
Last updated: Jan 09 2025 at 00:46 UTC