Sean (Nov 04 2022 at 05:06): Sean (Nov 04 2022 at 05:06):@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.
Sean (Nov 04 2022 at 05:07):What are your thoughts on either keeping it separate or integrating it back?
Sean (Nov 04 2022 at 05:10):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.
Daniel Rossberg (Nov 04 2022 at 08:59):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.
Sean (Nov 11 2022 at 18:34):@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).
Sean (Nov 11 2022 at 18:35):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
Sean (Nov 11 2022 at 18:37):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.
Sean (Nov 11 2022 at 18:38):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).
Sean (Nov 11 2022 at 18:38):It can also be compiled from their fork of the arbalest repo.
Daniel Rossberg (Nov 14 2022 at 18:25):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.
Sean (Nov 15 2022 at 06:01):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
Sean (Nov 15 2022 at 06:09):A binary is available at https://brlcad.org/~sean/tmp/GeometryV&V.zip (570MB)
Sean (Nov 15 2022 at 06:15):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.
Daniel Rossberg (Nov 15 2022 at 18:47):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.
Daniel Rossberg (Nov 15 2022 at 18:56):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.
Sean (Nov 16 2022 at 23:08):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 ?
Sean (Nov 16 2022 at 23:10):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.
Daniel Rossberg (Nov 17 2022 at 19:05):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.
Daniel Rossberg (Nov 20 2022 at 13:29):Dependency Walker is like ldd.
Daniel Rossberg (Nov 20 2022 at 16:08):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.
Sean (Nov 21 2022 at 20:22):@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.
Sean (Nov 21 2022 at 20:23):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.
Sean (Nov 21 2022 at 20:24):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).
Sean (Nov 21 2022 at 20:33):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.
Sean (Nov 21 2022 at 20:37):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.
starseeker (Nov 21 2022 at 20:38):A naive question about Arbalest's intent longer term - is it intended to eventually replace MGED?
starseeker (Nov 21 2022 at 20:39):The talk about "Documents" sounded rather awkward for things like command line scripted processing, but that may just be my own limited understanding.
Sean (Nov 21 2022 at 20:42):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.
Sean (Nov 21 2022 at 20:44):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.
starseeker (Nov 21 2022 at 20:46):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.
Sean (Nov 21 2022 at 20:55):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.
starseeker (Nov 21 2022 at 20:56):I've put a fair bit of effort into developing a Qt-style model for the .g file state - has Arbalest done that?
Sean (Nov 21 2022 at 20:57):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.
Sean (Nov 21 2022 at 21:09):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.
Sean (Nov 21 2022 at 21:11):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.
starseeker (Nov 21 2022 at 21:12):So if the command line adds or removes comb tree elements, the Arbalest tree is automatically updated?
Sean (Nov 21 2022 at 21:15):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.
starseeker (Nov 21 2022 at 21:21):<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.
starseeker (Nov 21 2022 at 21:23):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.
Sean (Nov 21 2022 at 21:30):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.
Sean (Nov 21 2022 at 21:31):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.
Sean (Nov 21 2022 at 21:33):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.
Sean (Nov 21 2022 at 21:34):That conversation literally doesn't exist in arbalest's main (or any of the other classes for that matter). The learning curve is flat.
Sean (Nov 21 2022 at 21:36):That's also why the capstone team was able to run with it. I had them look at both.
Sean (Nov 21 2022 at 21:38):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.
Sean (Nov 21 2022 at 21:39):They're definitely not OO, but it might not be terribly difficult to bridge what they use down through the same classes.
starseeker (Nov 21 2022 at 21:41):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
Sean (Nov 21 2022 at 21:47):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.
Sean (Nov 21 2022 at 21:49):What did select collapse and select expand do?
starseeker (Nov 21 2022 at 21:50):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.
starseeker (Nov 21 2022 at 21:51):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.
starseeker (Nov 21 2022 at 21:52):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
Sean (Nov 21 2022 at 21:52):Why wouldn't you always want to collapse? Or always not collapse?
starseeker (Nov 21 2022 at 21:53):For editing purposes, you may specifically want your matrix applications to be at lower levels.
starseeker (Nov 21 2022 at 21:53):As a general design principle, you want to be able to select any instance at any level of the hierarchy, or sets of them.
starseeker (Nov 21 2022 at 21:54):With multiple applications of select and remove operations, you can zero in on comb instances graphically
starseeker (Nov 21 2022 at 21:55):Sorry, I'm acting as a distraction.
Sean (Nov 21 2022 at 21:55):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..
Sean (Nov 21 2022 at 21:57):btw, 'collapse' and 'expand' don't sound intuitive to me, maybe another verb describing the action
Sean (Nov 21 2022 at 21:59):maybe lift and lower ?
Sean (Nov 21 2022 at 22:00):or even maybe push/pull if that doesn't conflict
Sean (Nov 21 2022 at 22:04):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.
Daniel Rossberg (Nov 22 2022 at 09:22):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.
Daniel Rossberg (Nov 22 2022 at 09:35):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.
Daniel Rossberg (Nov 22 2022 at 09:50):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.
Daniel Rossberg (Nov 22 2022 at 10:12):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.
Daniel Rossberg (Nov 22 2022 at 10:19):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".
Daniel Rossberg (Nov 22 2022 at 10:29):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: Oct 09 2024 at 00:44 UTC