Geometry Verification and Validation GUI in Qt · Google Summer of Code

Hey @Kanchan Borole This is the channel we will use to track your GSoC progress and discussions

Divyanshu Garg (May 01 2026 at 08:20):

Kanchan Borole (May 01 2026 at 08:42):

Divyanshu Garg (May 01 2026 at 09:17):

Awesome, since we are in the community bonding period, we can take it as an opportunity to get more familiar with what we are working with.
Here are our goals for the next 20 days:-

Divyanshu Garg (May 01 2026 at 09:33):

Divyanshu Garg (May 01 2026 at 09:37):

With that, I am Divyanshu, and we will be working together for the next few months to deal with the problem statements proposed. Excited about the good things we are gonna be achieving by the end of it.

Kanchan Borole (May 01 2026 at 10:16):

Thank you for the detailed overview! I will keep all of this in mind. I will start with setting up the development environment and going through the repository and documentation over the next few days. I will keep you updated on my progress regularly.

Kanchan Borole (May 02 2026 at 05:17):

Hi @Divyanshu Garg , I wanted to clarify my understanding before I proceed further.
My goal is to take the V&V features from the old isaacy13/arbalest fork (https://github.com/isaacy13/arbalest) and bring them into the latest official BRL-CAD/arbalest codebase. The old fork has the V&V functionality but uses Qt5. The latest arbalest uses Qt6 so my plan is to work on the latest BRL-CAD/arbalest and port the V&V features there using Qt6.
To set this up I need help with two things:

Divyanshu Garg (May 02 2026 at 07:25):

Divyanshu Garg (May 02 2026 at 07:31):

Wait a second, my bad, i misread it, If the latest is in QT6 ofcourse we do that one, Based on the last update i see it mentions Qt6.4.2

Divyanshu Garg (May 02 2026 at 07:32):

Divyanshu Garg (May 02 2026 at 07:36):

Kanchan Borole (May 02 2026 at 07:39):

Divyanshu Garg (May 02 2026 at 07:51):

Setting up BRLCAD MOOSE shouldn't be different since it follows standard/similar procedures we have in textbook C++ projects. One of the easiest ways to do that is to search and learn how we usually run similar apps on windows and it should be following the same procedure.

But, also noticed that you mentioned BRLCAD_MOOSE not BRLCAD/MOOSE a variable which is mentioned in the arbalest repository cmakelist. In that particular query
it should work with something like this cmake .. -DBRLCAD_MOOSE_DIR=C:\moose-install, basically resolving the directory as required.

Kanchan Borole (May 03 2026 at 05:01):

Hi @Divyanshu Garg , Update on my environment setup progress:
Successfully done:
Qt 6.11.0 installed
BRL-CAD 7.32.2 installed
Latest BRL-CAD/arbalest cloned
Issue I am facing:
I ran cmake on latest arbalest with this command:

cmake .. -DBRLCAD_BASE_DIR="C:\brlcad\BRL-CAD 7.32.2" -DQt6_DIR="C:\Qt\6.11.0\msvc2022_64\lib\cmake\Qt6" -DCMAKE_POLICY_VERSION_MINIMUM=3.5

Getting this error: CMake Error in CMakeLists.txt:
Found relative path while evaluating include directories of "ZERO_CHECK":
"BRLCAD_MOOSE_INCLUDE_DIR-NOTFOUND"

I also tried your suggestion of using -DBRLCAD_MOOSE_DIR flag but there is no MOOSE directory in my BRL-CAD 7.32.2 installation. I also tried building BRL-CAD from source earlier but was getting png/asm compilation errors and the build failed.
Could you please tell me which BRL-CAD version includes MOOSE or where I can get it for Windows?

Divyanshu Garg (May 03 2026 at 07:30):

Divyanshu Garg (May 03 2026 at 07:51):

Kanchan Borole (May 03 2026 at 15:08):

Following your suggestion, I cloned MOOSE from https://github.com/BRL-CAD/MOOSE and tried building it with installed BRL-CAD 7.32.2 but got this error:
Could not find BRL-CAD
So I tried building BRL-CAD from source again. Disabled GDAL and iwidgets as they were failing but still getting:
Unable to successfully build bext dependency repository
I am on Windows. Should I use WSL to build BRL-CAD from source? Please guide me on the best approach to move forward.

Daniel Rossberg (May 03 2026 at 16:20):

@Kanchan Borole, version 7.32.2 is 5 years old and not suited as base for actual development. You need to compile the libraries and programs from source, to be able to include their latest changes in your development.

In general, MS Visual Studio is the recommended build environment for Windows, i.e. it should work. Most of the development was however done with MSVS 2022, and there are apparently some issues with MSVS 2026. I.e., you could try Visual Studio 2022.

Kanchan Borole (May 04 2026 at 08:52):

Thank you @Daniel Rossberg for the detailed guidance and the compilation guide! I will follow the steps at https://drossberg.github.io/BRL-CAD/compiling.html and try again building BRL-CAD from source using Visual Studio 2022. Will update you on the progress!

Divyanshu Garg (May 04 2026 at 16:36):

Himanshu (May 04 2026 at 19:25):

Hi @Kanchan Borole , going forward I will also be part of this project in terms of mentoring. I am little bit late to join :sweat_smile:.

Kanchan Borole (May 05 2026 at 09:08):

Hi, Progress update on the environment setup: I tried setting up on Windows but kept facing dependency build errors and could not complete the build successfully. Anyhow I then arranged a Linux system (Ubuntu 24.04.3) and happy to share that I have successfully built BRL-CAD 7.43.0 from source and installed it! Now proceeding to build MOOSE and will update on the progress soon.

Kanchan Borole (May 05 2026 at 09:08):

Hi @Himanshu , looking forward to working with you and learning from you throughout this project!

Divyanshu Garg (May 05 2026 at 09:30):

That sounds amazing @Kanchan Borole,
Things are mostly much easier to deal with on Linux compared to Windows

Divyanshu Garg (May 05 2026 at 09:30):

Daniel Rossberg (May 05 2026 at 10:33):

@Kanchan Borole, in the MOOSE CMake configuration, you should set BRLCAD_STATIC_LINK to OFF and MODULE_COMMANDPROMPT to ON. This is necessary to build and run arbalaest later on.

Kanchan Borole (May 05 2026 at 13:58):

Sean (May 05 2026 at 16:50):

the V&V gui while started with arbalest, it kind of ended up like an application fork. part of this effort is not just updating to the latest arbalest/moose code, but then also separating the domain-specific V&V logic that was coded up. the app logic should probably be a plugin or set of plugins or some sort of overlay that works with and/or extends arbalest/moose's api with it's app-specific behavior.

Kanchan Borole (May 06 2026 at 09:55):

Hi, I was able to successfully built MOOSE (all tests passed). However, I’m currently facing an issue while building Arbalest.
The build reaches 100%, but it fails at the linking stage with multiple undefined reference errors related to BRL-CAD functions (like bu_malloc, rt_shootray, etc.) and also BRLCAD::CommandString. There is also a warning about librt.so.20 not being found, which seems to be coming from /usr/local/lib/libbrlcad.so.

My current setup is:
BRL-CAD installed at: /usr/brlcad/dev-7.43.0
MOOSE installed at: /usr/local

And I configured Arbalest using:
cmake .. -DBRLCAD_BASE_DIR=/usr/brlcad/dev-7.43.0 -DBRLCAD_MOOSE_DIR=/usr/local
It looks like there might be a linking mismatch or conflicting BRL-CAD libraries being picked up.
Could you please guide me on how to resolve this linking issue?

Divyanshu Garg (May 06 2026 at 09:56):

Kanchan Borole (May 06 2026 at 10:03):

Hi @Sean , Thanks for the clarification — that helps a lot.
I’ll keep this in mind and focus on how to modularize the existing V&V logic accordingly.

Divyanshu Garg (May 06 2026 at 10:09):

@Kanchan Borole can you please check if you have an older installations?
I just checked the codebase the 2 methods you mentioned are there in version 7.43.0

Kanchan Borole (May 06 2026 at 10:24):

Thanks — that makes sense. I wasn’t able to see any older installation in /usr/local on my side, but I may be missing something. I’ll do a clean rebuild and double-check the linking to ensure it’s using the correct BRL-CAD version.

Daniel Rossberg (May 06 2026 at 10:31):

BRLCAD_MOOSE_DIR has to point to the directory, where you installed MOOSE. I.e., what's your directory layout?

Kanchan Borole (May 06 2026 at 10:35):

Here is my current setup:
BRL-CAD source dir: ~/gsoc/src/brlcad
BRL-CAD install dir: /usr/brlcad/dev-7.43.0
MOOSE source dir: ~/gsoc/src/moose
MOOSE install dir: /usr/local
Please let me know if this looks correct or if I should change anything.

Daniel Rossberg (May 06 2026 at 10:48):

OK, first, I recommend to install the stuff somewhere at ~/gsoc, because you do not need to become root for installation then. E.g., ~/gsoc/inst/brlcad and ~/gsoc/inst/moose.

You can change the installation paths by changing CMAKE_INSTALL_PREFIX with the CMake gui, for example.

Daniel Rossberg (May 06 2026 at 10:52):

Then, cmake ~/gsoc/src/arbalest -DCMAKE_BUILD_TYPE=Debug -DBRLCAD_MOOSE_DIR=~/gsoc/inst/moose should create you a working build set-up for arbalest.

starseeker (May 06 2026 at 11:29):

Probably Arbalest will need some updates to build against latest main - I have a branch with work like that for MOOSE, but I haven't checked Arbalest yet (juggling a lot of balls right now)

Daniel Rossberg (May 06 2026 at 12:12):

There were no changes to arbalest neccessary. The MOOSE API is unchanged :grinning_face_with_smiling_eyes:

Divyanshu Garg (May 06 2026 at 15:28):

Hey @Kanchan Borole
I went ahead and started messing around the installation, and here is
ISSUE.md
a MD file which might help you with the issues you are facing

Daniel Rossberg (May 06 2026 at 19:20):

Hmm, setting BRLCAD_VERSION shouldn't be necessary on Linux. It should be set by calling brlcad-config. Unfortunately, this script doesn't work on Windows.

In general, when configuring the MOOSE or arbalest build, read the output carefully. The error messages should contain a hint how to resolve them.

In addition, the brlcad installation binary directory should be included in the PATH environment variable of your command shell. This makes it easier to call the BRL-CAD programs (mged, archer, and some more of the 300+(?) command line tools).

starseeker (May 07 2026 at 00:10):

I'm trying to work on a modern find_package Config.cmake solution that will make things a little easier, fwiw. It's not done yet - I'm still trying to figure out shared vs. static issues properly - but if I can get it right we can hopefully reduce brlcad-config to a small program that provides the correct inputs so a CMake build will find our Config.cmake file and take it from there (and make it work on Windows while we're at it)

Daniel Rossberg (May 07 2026 at 14:35):

What came into my mind too: As developers, we should set -DCMAKE_BUILD_TYPE=Debug. We may need to debug our stuff :wink:

Kanchan Borole (May 08 2026 at 12:09):

Hi, I have successfully built and run Arbalest. Really grateful for all the guidance and support.
I have also set up a tracking repository where I am maintaining my architecture understanding, daily logs, and setup notes: https://github.com/KanchanBorole/gsoc-2026-brlcad-vv
Next I am planning to:

Divyanshu Garg (May 08 2026 at 12:12):

That sounds amazing. It's great that you are also documenting the progress and your efforts.
On that note, you can also add this documentation information to the official repositories and send a PR, so that someone working in the future can set up the builds more easily.

Kanchan Borole (May 08 2026 at 12:18):

Thank you! That makes sense — I’ll clean up the setup notes properly and plan to contribute them back to the official repositories through PRs so the setup process becomes easier for future contributors as well.
And yes, I do use AI tools occasionally during development, mainly for: understanding unfamiliar codebases, debugging build/configuration issues, exploring documentation faster, improving development workflow and learning. But I make sure to understand the changes and debugging process myself while working through the project.

Divyanshu Garg (May 08 2026 at 12:24):

Sweet, before we do the dev work. We support the usage of AI, but that must happen responsibly. AI-based code is acceptable as long as the contributor knows exactly what it does and ensures its quality and standards meet the existing code standards. In Short, avoid sending whatever AI implements. I am pretty certain that you already know and understand this, but still mentioning it anyway. Thanks for understanding. :grinning_face_with_smiling_eyes:

Himanshu (May 09 2026 at 14:18):

Himanshu (May 09 2026 at 14:19):

starseeker (May 09 2026 at 19:25):

Kanchan Borole (May 11 2026 at 09:06):

Hi, I have been going through the isaacy13 fork codebase to understand the V&V implementation. I noticed that the V&V logic is spread across a few files — VerificationValidationWidget, VerificationValidation, and VerificationValidationParser.
To understand how to separate it, I tried creating a plugins/vv folder structure inside the latest arbalest src and include directories and started configuring it. While trying to get it working, I ran into several API mismatches — functions like getDocuments(), setStatusBarMessage(), popup() and others that exist in the old fork but not in the latest arbalest.
As the V&V logic should be a plugin or overlay that extends Arbalest/MOOSE API. What would be the recommended way to port the existing V&V code from the old fork into the latest arbalest as a plugin — keeping the existing V&V logic but adapting it to work with the latest APIs? Also how should the plugin connect and integrate with the main Arbalest application?

Sean (May 12 2026 at 20:34):

Those are tough questions @Kanchan Borole ... I can tell you how I'd likely approach it, but there are lots of possible ways to proceed.

You could check out a copy of arbalest from before the v&v changes, for example, so you can diff that against the latest arbalest, to understand what all has changed. That kind of analysis would be great for AI to do for you since it's more about understanding. Then you'd hopefully have a better sense how to re-apply the changes on the latest code.

Alternatively if the old commits are nice and concise, you could simply replay each one in order, adapting code as you go in a smaller local context to achieve a similar end result. That approach would be more about learning the current arbalest interface and making decisions as you go on an appropriate path forward, whether to extend arbalest to get the same result or moose, or some other approach.

You could also go "cold-turkey" and just compile up the old V&V fork, itemize all the end-user features you see in great detail, then (re-)implement them in the latest arbalest cleanly without much regard to how they were implemented originally. The code becomes a last resort consult, an assumption that it's easier to write new with clean design in mind than it is to read old and port. Merits to both.

Personally, I'd compile the old up and get it working. That's critical to understanding the code. Then, compile the new, and seeing on a file-by-file basis what is needed to get that functionality working. Might even try refactoring the old simultaneously while refactoring the new, until it can just work in both.

Daniel Rossberg (May 13 2026 at 07:18):

Hi @Kanchan Borole, it looks like you found almost all relevant files with the V&V logic. Some hints:

Kanchan Borole (May 13 2026 at 12:10):

Hi @Sean and @Daniel Rossberg , thanks a lot for the guidance and suggestions. I’ve been trying to understand both the old V&V fork and the latest Arbalest structure based on your advice.

As an experiment, I tried integrating the VV-related code into the latest Arbalest through a separate modular plugins/vv style structure instead of directly mixing things into the core application. For now, I exposed it through a dockable VV panel just to test the integration approach with the latest Arbalest/Qt6 setup.

I mainly wanted to ask whether this kind of direction is roughly what you had in mind, and also whether the VV functionality should eventually live primarily as a dock widget, a dedicated menu/toolbar integration, or some other extension mechanism inside Arbalest.

Daniel Rossberg (May 14 2026 at 13:47):

Your prototype looks good to me. However, I'm not an expert for the V&V stuff. I keep mainly an eye on a clean implementation. E.g. that no new dependencies are introduced. I try to answer the question "How to do it with MOOSE?"

Sean (May 14 2026 at 20:29):

@Kanchan Borole integrating as a separate modular plugin is absolutely in the right direction. The difficulty is going to be whether adaptations to arbalest are needed to achieve the same end results as the old GUI. The old GUI changed several aspects of the GUI such as overriding the menu with some changes/additions, overriding the button bar to add at least one "compile/stop" button, and adding a new Qt widget to the bottom with a list view that interacted seamlessly (e.g., selecting a warning, the geometry involved was indicated). I believe there was also a window you could open on warnings/issues that gave even more info in a new window.

So I'd say tackle those features one at a time and see where you get. You clearly added a plugin that added a Qt widget context. Maybe try to make it automatically display across the bottom with a list view inside it -- not something the user has to do. Don't know if that'd require arbalest changes to even do that sort of GUI mod on plugin load, but it's a start. Then maybe try to do the same to mod the menu and add a button.

Kanchan Borole (May 17 2026 at 09:12):

I’ve continued working on reconstructing the old VV workflow/features on top of the latest Arbalest codebase while trying to keep the implementation modular and lightweight for now.

I’ve attached a short demo video of the current state. Before moving deeper into the actual geometry validation/overlap logic and MOOSE/MGED-style validation integration, I wanted to check whether this direction and level of Arbalest-side integration aligns with migration/reconstruction work.
Verification&Validation1.webm

Sean (May 18 2026 at 15:08):

@Kanchan Borole have you successfully compiled and run the old v&v gui? If not, you definitely should get it working just so you have baseline comparison on hand for UI/UX. there as a lot of time, thought, and effort put into what it did and how it presented it that would not be efficient to discard.

Kanchan Borole (May 20 2026 at 11:22):

I’ve made progress on rebuilding the VV UI/workflow in the latest Arbalest codebase and wanted to check whether the current direction/workflow looks aligned with the expected VV behavior from the older implementation, or if there are areas that should be improved/refined before I continue further.
I’d appreciate guidance on the recommended next steps from here.
Verification & Validation 2.webm

Kanchan Borole (May 24 2026 at 10:53):

Hi, just following up - I wanted to ask what the recommended next focus area should be from here, and whether there are any areas in the current workflow/UI that should be adjusted or improved before moving further.
Also, would it be appropriate to start preparing/opening an initial PR for the current UI integration and workflow progress, or should I continue refining locally first?

Divyanshu Garg (May 24 2026 at 11:10):

Hey @Kanchan Borole do you feel that the work done as of now is ready for the first draft? If yes, you may send a PR
Also, have you added the issues on GitHub? That would help everyone to track what part of the GSoC project is done, and also find the linked code

Kanchan Borole (May 24 2026 at 11:39):

Thanks! I’ll start preparing the first draft PR.
Regarding the GitHub issues — should I create them directly in the official arbalest repository for tracking the different V&V tasks/features (UI integration, grouped workflow, exports, backend/result handling, etc.), or were you referring to a separate project board/tracking setup?

Divyanshu Garg (May 24 2026 at 11:40):

Kanchan Borole (May 25 2026 at 05:27):

Before preparing the PR, I wanted to confirm whether my current implementation direction is aligned with the intended architecture.
I added the V&V UI components under src/plugins/vv/ui/ (VVWidget, VVDockWidget, VVIssueDialog, VVTestSelectionDialog), updated the relevant CMakeLists.txt, and integrated them through MainWindow.

In MainWindow.h I added vvDockable, vvWidget, vvTimer, vvValidationQueue, vvRunning, vvCurrentIndex, vvTests, vvSuites, and the methods startVVValidation(), processVVValidation(), and stopVVValidation().

In MainWindow.cpp I added the V&V menu (Run Validation, Create/Remove Test, Create/Remove Suite, TXT/CSV/JSON export), toolbar actions (Run V&V, Stop), dock widget registration in prepareDockables(), validation workflow logic, report export functionality, and signal/slot connections for geometry selection and issue navigation.

Is this integration approach acceptable, or would prefer these menu registrations, toolbar actions, dock widget setup, and validation workflow to be moved into a dedicated plugin structure under src/plugins/vv/ instead? Also, is src/plugins/vv/ the appropriate location for this functionality, or would you recommend a different folder structure?

Himanshu (May 25 2026 at 17:40):

You can always draft the PR when it's in dev state. So no issues sending a PR. It can always be improved with newer commits.

Btw if I pick an example: vvDockableso this inherits Dockable that exist in Dockable.h or you did class vvDockable: public QDockWidget?

Himanshu (May 25 2026 at 17:42):

Kanchan Borole (May 26 2026 at 06:03):

Thanks! I’ve now opened the draft PR for early architecture/workflow review:
https://github.com/BRL-CAD/arbalest/pull/76
Currently VVDockWidget is implemented as class VVDockWidget : public QDockWidget, and the current V&V UI components are organized under src/plugins/vv/ui/. I’ll continue refining the structure further based on review feedback.

Kanchan Borole (May 28 2026 at 05:11):

While waiting for further UI/workflow review, I was planning to continue with the V&V result/report handling side (result structures, report generation/export organization, validation result management) since those seem relatively independent from the final UI/plugin arrangement.
Does that sound like a reasonable next step to proceed with meanwhile, or would you recommend a different next direction at this stage?

Divyanshu Garg (May 28 2026 at 15:08):

Kanchan Borole (May 28 2026 at 15:27):

Himanshu (May 29 2026 at 12:46):

I will review this weekend. Just yesterday only, I built arbalest. :sweat_smile:

Himanshu (May 31 2026 at 07:33):

@Kanchan Borole I tried to apply your patch but got errors while building arbalest. One example from your patch is:

bool maybeSave(int documentId, bool *cancelvoid prepareUi();
                   void loadTheme();
                   void setIcons();
                   void prepareDockables();
                   = nullptr);

Himanshu (May 31 2026 at 07:34):

Himanshu (May 31 2026 at 07:35):

Kanchan Borole (May 31 2026 at 08:28):

@Himanshu Thanks for checking. I found the issue in MainWindow.h, fixed it, rebuilt Arbalest locally, and updated the PR.

Himanshu (May 31 2026 at 21:02):

Himanshu (May 31 2026 at 21:05):

I saw timer-based validation is added for current checks. May be unnecessary for the current checks?? I am not sure on this. Maybe @Daniel Rossberg can help here.

Himanshu (May 31 2026 at 21:06):

Running one validation per second introduces unnecessary delay and complexity, I think. The current validations are lightweight string checks (empty names, duplicate names, spaces, temporary names) as for now I think no issues unless future validation steps are expected to be computationally expensive, consider processing the entire validation queue immediately or documenting the reason for the timer-based approach.

Kanchan Borole (Jun 03 2026 at 05:58):

I originally kept the timer because I was thinking ahead to future validations such as overlap/volume related checks, which may be more expensive than the current string-based checks. I would be interested to know whether an incremental approach still makes sense for the longer-term V&V direction.

Himanshu (Jun 03 2026 at 19:22):

Kanchan Borole (Jun 04 2026 at 05:49):

@Himanshu I have tried to fix these bugs. Could you please check if the changes look correct?

Daniel Rossberg (Jun 04 2026 at 15:05):

I didn't follow the discussion here. Was this a requirement? Well, I'm not against it. Have it as an option?

Daniel Rossberg (Jun 04 2026 at 15:34):

I think that PR #76 should be prepared for merging. I.e., bugs and missing features from Isaac's version should be ignored for now. Generally, the PR looks good. @Kanchan Borole, you should check line by line that the merge doesn't revert any change made in main arbalest meanwhile. Looking at https://github.com/BRL-CAD/arbalest/pull/76/changes I see a lot of such changes, mainly stylistic. It's bad habit to ignore changes made by others. I.e., to repeat it, check line by line for unintended reverts and remove them from your PR.

Kanchan Borole (Jun 05 2026 at 08:46):

Thanks for pointing this out. Some of the formatting changes were introduced unintentionally while I was working on it. I've tried to revert those changes and will keep this in mind going forward. Could you please check if the remaining changes look correct now?

Himanshu (Jun 06 2026 at 05:18):

I will look into the PR on Monday. Currently I'm outside and laptop isn't with me to review PR.

Daniel Rossberg (Jun 06 2026 at 14:58):

@Kanchan Borole, in https://github.com/BRL-CAD/arbalest/pull/76/changes, some files have a :no_entry: sign at their end. This means that they don't end with a newline. You should add it as this is considered as better style.

Daniel Rossberg (Jun 06 2026 at 15:09):

@Himanshu, if you agree, I can merge the pull requests (maybe, after the newlines were added). It may be not perfect, but it would be good to create a savepoint here.

Himanshu (Jun 08 2026 at 14:32):

Daniel Rossberg (Jun 08 2026 at 17:45):

Kanchan Borole (Jun 09 2026 at 05:33):

I was looking through the earlier discussion about the V&V logic, especially the part where the MGED-based execution would eventually need to be replaced using MOOSE/CommandString.
Before I start working on the next task, could you recommend what would be the best area to focus on next? I was considering the result/report handling side, but I wasn't sure whether it would be better to work on the execution/MOOSE side first or if there are other higher-priority V&V tasks that I should focus on at this stage.

Himanshu (Jun 10 2026 at 20:23):

I think to start with geometry verfication and validation logic and adding it in arbalest. Is it by using MOOSE/CommandString? Then go ahead.

Kanchan Borole (Jun 11 2026 at 14:11):

Currently I am investigating how to implement the actual verification and validation logic. I reviewed the existing Arbalest codebase, including the object tree traversal and BRL-CAD combination handling, to understand how geometry hierarchies are represented.

For the VV checks (such as Duplicate ID Check, No Nested Regions, and Overlap detection), I am trying to determine the intended approach. Should these checks be implemented primarily through MOOSE/CommandString functionality, or should they operate directly on the BRL-CAD database structures exposed within Arbalest?

I would also appreciate any guidance on whether there are existing GQA/VV workflows, commands, or MOOSE capabilities that I should build upon rather than implementing everything from scratch.

Daniel Rossberg (Jun 11 2026 at 18:53):

Kanchan Borole (Jun 14 2026 at 12:12):

I have tried to implement the MOOSE CommandString integration for the V&V plugin and raised a draft PR for review. I am not sure if the approach is correct, could you please review it. The gqa based tests cause arbalest to freeze during execution so I have skipped them for now.
PR Link - https://github.com/BRL-CAD/arbalest/pull/77

Daniel Rossberg (Jun 14 2026 at 17:35):

Daniel Rossberg (Jun 14 2026 at 17:38):

The issue with gqa could be caused by the different working directory or path to the executable, i.e., by arbalest not being in the brlcad bin directory.

Kanchan Borole (Jun 15 2026 at 08:45):

I have verified that the tests are being triggered correctly and I am seeing the expected output format in the console. However, due to the architecture migration, I am not entirely sure whether the behavior and results fully match with the previous implementation. It would be really helpful if you could check on your end and let me know if I'm missing anything in the logic, I'll make changes accordingly.

I tried setting the absolute path to the gqa executable to ensure it's found correctly, but Arbalest still becomes unresponsive during the test execution. I think this is because the execution is blocking the main UI thread. What do you think? Could you please guide me on the best approach to handle these long-running commands in Arbalest?

Daniel Rossberg (Jun 15 2026 at 17:52):

Kanchan Borole (Jun 16 2026 at 11:06):

I've curated a few geometries to test. These files contain specific issues like missing nested regions, material/LOS properties, and solids outside of regions. I have attached these files here. Additionally, I’ve been testing the plugin against existing BRL-CAD datasets like shipping_container.g and havoc.g. To be honest, I am currently unsure if the errors being flagged in these files are expected behavior or actual bugs.

Daniel Rossberg (Jun 17 2026 at 08:23):

Daniel Rossberg (Jun 17 2026 at 17:38):

Which are the gqa based tests? I run all tests on havoc.g. These are the results:

[INFO] Starting validation...
[PASSED] No mis-matched duplicate IDs
[ERROR] Duplicate ID check: sun/R
[PASSED] No matrices
[ERROR] Valid title: BRL-GSI Paris Air Show Soviet HAVOC Helicopter
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[PASSED] No nested regions
[PASSED] No empty combos
[PASSED] No solids outside of regions
[PASSED] All BoTs are volume mode (should return nothing)
[PASSED] No BoTs are left hand orientation
[PASSED] All regions have material
[PASSED] All regions have LOS
Checked object: sun
[PASSED] No mis-matched duplicate IDs
[ERROR] Duplicate ID check: havoc/
[PASSED] No matrices
[ERROR] Valid title: BRL-GSI Paris Air Show Soviet HAVOC Helicopter
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[PASSED] No nested regions
[PASSED] No empty combos
[PASSED] No solids outside of regions
[PASSED] All BoTs are volume mode (should return nothing)
[PASSED] No BoTs are left hand orientation
[PASSED] All regions have material
[PASSED] All regions have LOS
Checked object: havoc
[SKIP] No mis-matched duplicate IDs
[SKIP] Duplicate ID check
[SKIP] No matrices
[SKIP] Valid title
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[SKIP] No nested regions
[SKIP] No empty combos
[SKIP] No solids outside of regions
[SKIP] All BoTs are volume mode (should return nothing)
[SKIP] No BoTs are left hand orientation
[SKIP] All regions have material
[SKIP] All regions have LOS
Checked object: _GLOBAL
[PASSED] No mis-matched duplicate IDs
[ERROR] Duplicate ID check: BRL-GSI_EFFORT/
[PASSED] No matrices
[ERROR] Valid title: BRL-GSI Paris Air Show Soviet HAVOC Helicopter
[SKIP] Duplicate Geometry Names
[SKIP] No null region
[SKIP] Overlaps cleared to gridsize with tolerance
[PASSED] No nested regions
[PASSED] No empty combos
[PASSED] No solids outside of regions
[PASSED] All BoTs are volume mode (should return nothing)
[PASSED] No BoTs are left hand orientation
[PASSED] All regions have material
[PASSED] All regions have LOS
Checked object: BRL-GSI_EFFORT
[INFO] Validation Completed Successfully.

Daniel Rossberg (Jun 17 2026 at 17:39):

Daniel Rossberg (Jun 17 2026 at 17:41):

Kanchan Borole (Jun 18 2026 at 11:39):

Thanks for the feedback @Daniel Rossberg
Regarding the skipped tests, the GQA-based ones (overlaps and null regions) were causing the plugin to freeze, so I've commented them out in VVBackendTest.cpp and skipped them for now. The duplicate geometry name check is also still in progress, which is why it is currently skipped.
As for the errors in havoc.g, I am currently unsure if these are expected behaviors or actual bugs.

Daniel Rossberg (Jun 18 2026 at 19:23):

Okay, the good news first: gqa seems to work correctly. The small grid size of 4mm can just lead to long runtimes.

Daniel Rossberg (Jun 18 2026 at 19:30):

You should check, why some tests fail, which shouldn't. E.g., the "Valid title" for havoc.g. This works.

Daniel Rossberg (Jun 18 2026 at 19:32):

BTW, Isaac distinguishes between ObjectName and ObjectPath. It looks like you do not.

Kanchan Borole (Jun 19 2026 at 12:58):

Thanks for the feedback. I'll investigate the failing tests and the ObjectName/ObjectPath distinction. I'm away from my laptop this weekend due to some urgent work, but I'll keep an eye on the chat and continue working on this as soon as I'm back.

Kanchan Borole (Jun 23 2026 at 11:52):

I have revisited the logic to ensure a clear distinction between ObjectName and ObjectPath by passing the full path (resolvedPath) to all backend commands. I’ve tested this with havoc.g, and the logs now show the validator explicitly checking the full paths (e.g., [CHECKING] /havoc/...). Could you please take a look at the commit when you have a moment? I would like to confirm whether my understanding and implementation of ObjectPath is correct.

Daniel Rossberg (Jun 24 2026 at 17:55):

Looking at Isaac's version, I see "$OBJECT" with Arg::Type::ObjectName and "/$OBJECT" with Arg::Type::ObjectPath. In your version, there is resolvedPath only. Why? (Maybe, there is a good reason.)

Daniel Rossberg (Jun 24 2026 at 17:56):

Kanchan Borole (Jun 25 2026 at 08:23):

I initially used resolvedPath to verify the overall logic and ensure that the assembly could be loaded correctly. It was mainly a quick way to validate the workflow. I understand that keeping the distinction between Arg::Type::ObjectName and Arg::Type::ObjectPath is the proper approach, and I am prepared to refactor the code accordingly.

Regarding the command change, I tested both lc and ls using the Arbalest command window. Initially, I thought ls would be useful because it displays all database contents, but after testing, I found that it produces much more output than necessary, whereas lc is more suitable for inspecting specific parts. Therefore, I plan to use lc in the final implementation.

Could you please let me know whether the overall logic seems reasonable, and whether I should proceed with refactoring the implementation to match Isaac's approach?

Daniel Rossberg (Jun 25 2026 at 17:34):

Well, your general approach looks reasonable. I just wonder why you changed things.

Kanchan Borole (Jun 26 2026 at 05:56):

To be honest, I was experimenting with different approaches to understand how the system behaves and to get the logic working during the initial phase. My main goal at that stage was to verify the workflow. Should I revert these changes and refactor the code to match Isaac’s approach, or would you prefer that I keep this experimental structure for now?

Kanchan Borole (Jun 29 2026 at 12:37):

While investigating the path/string handling, I noticed that there might be some issues in my current implementation. As a side experiment, I tried the ObjectName/ObjectPath approach from Isaac's implementation and tested it on the havoc.g geometry.
These are the results I obtained.
PastedText.txt
Perhaps I am still missing something, so I wanted to ask whether these results look reasonable, or if there is something incorrect in my implementation.

Daniel Rossberg (Jun 29 2026 at 17:23):

Kanchan Borole (Jun 30 2026 at 08:18):

Thanks for checking the results and for the explanation.
One more question: before I prepare the commit, would you recommend that I refactor the implementation to follow Isaac's ObjectName/ObjectPath approach, or should I keep my current implementation?

Daniel Rossberg (Jun 30 2026 at 11:22):

What do you prefer? At the end, everything should work, that's sure. But, which way do you prefer.

Kanchan Borole (Jun 30 2026 at 13:23):

I think I'd prefer the ObjectName/ObjectPath approach. It seems cleaner and more consistent for handling the commands, so I'll refactor the implementation accordingly.

Kanchan Borole (Jun 30 2026 at 15:39):

I have committed the changes. Could you please review them? Let me know if any improvements are needed.

Daniel Rossberg (Jun 30 2026 at 17:10):

Divyanshu Garg (Jun 30 2026 at 19:04):

Divyanshu Garg (Jun 30 2026 at 21:06):

Hi @Kanchan Borole, reviewed the PR — builds and runs well, and moving the V&V checks onto real libged commands is a great step. One blocking issue to flag:

Both "No null region" and "Overlaps cleared to gridsize with tolerance" run the same gqa command (gqa -Ao -g 32mm,4mm -t 0.3mm <path>), then decide pass/fail by looking for a word in the output that gqa never actually prints. Because that word is never there, each check always lands on the same result no matter what the model looks like:

Kanchan Borole (Jul 01 2026 at 06:29):

Hi @Divyanshu Garg , Thanks for the review and the feedback!
I updated the parsing logic to separate the two checks and tested it with havoc.g. The results are now:
PastedText.txt

 else if (testName == "No null region")
    {
        result = executeCommand(db, {Arg("gqa"), Arg("-Ao"), Arg("-g", ArgType::None), Arg("32mm,4mm", ArgType::None), Arg("-t", ArgType::None), Arg("0.3mm", ArgType::None), Arg("$OBJECT", ArgType::ObjectPath)}, fullPath);
        QStringList lines = result.split('\n');
        QStringList nullRegions;

        for (const QString &line : lines)
        {
            if (line.contains("was not hit", Qt::CaseInsensitive))
            {
                nullRegions << line.trimmed();
            }
        }

        if (!nullRegions.isEmpty())
        {
            return "Error: Null regions detected:\n" + nullRegions.join("\n");
        }

        return "No issues found (PASSED)";
    }
    else if (testName == "Overlaps cleared to gridsize with tolerance")
    {
        result = executeCommand(db, {Arg("gqa"), Arg("-Ao"), Arg("-g", ArgType::None), Arg("32mm,4mm", ArgType::None), Arg("-t", ArgType::None), Arg("0.3mm", ArgType::None), Arg("$OBJECT", ArgType::ObjectPath)}, fullPath);
        QStringList lines = result.split('\n');

        bool startParsing = false;
        QStringList overlaps;

        for (const QString &line : lines)
        {
            QString trimmed = line.trimmed();

            if (trimmed.startsWith("list Overlaps", Qt::CaseInsensitive))
            {
                startParsing = true;
                continue;
            }

            if (!startParsing)
                continue;

            if (trimmed.isEmpty())
                continue;

            if (trimmed.contains("was not hit", Qt::CaseInsensitive))
                break;

            overlaps << trimmed;
        }

        if (!overlaps.isEmpty())
        {
            return "Error: Overlaps detected:\n" + overlaps.join("\n");
        }

        return "No issues found (PASSED)";
    }

Does this approach look correct, or would you recommend any further improvements before I prepare the commit?

Divyanshu Garg (Jul 01 2026 at 15:51):

@Kanchan Borole This fix looks good, you may push the code, we can do a final review and work on next things

Kanchan Borole (Jul 01 2026 at 16:30):

Divyanshu Garg (Jul 01 2026 at 16:48):

@Kanchan Borole The changes look legit, one good practice is to fix the issues and respond on the comments made on the PR, this helps to track if the issues marked were addressed or not, Ill approve the PR and kindly respond to the comments that has been fixed. We can merge the PR once we have one more approval

Divyanshu Garg (Jul 01 2026 at 16:49):

Daniel Rossberg (Jul 01 2026 at 17:40):

Kanchan Borole (Jul 02 2026 at 06:47):

Thank you for the review and the feedback! I'll keep that in mind.
For the next task, would you recommend that I start with the Report Generator, or is there another task you'd like me to prioritize first?

Daniel Rossberg (Jul 02 2026 at 07:33):

Kanchan Borole (Jul 02 2026 at 10:34):

Does this approach align with what you had in mind, or is there any specific implementation style you would prefer?

Sean (Jul 02 2026 at 17:03):

@Kanchan Borole those three bullets sound fine, but the first two are not really high priority issues. the goal is really getting the V&V gui 1) updated 2) fixed and 3) polished for at least the main validation case (i.e., all checks). 1 is mostly done I think? 2 is in progress, 3 is not started.

your third bullet touches on #3 (polish), but you should confirm all behaviors are fixed and working before going down that road.

Divyanshu Garg (Jul 02 2026 at 17:05):

Hey @Kanchan Borole, we are hosting a call tomorrow for this project at 9:00PM IST (9 PM might sound late, and apologies for that, it's just we are dealing with 3 timezones here EST, CEST, and IST). Would you be able to join it?
As soon as everyone confirms ill send out invites on Google Calendar, will also share a link here in the chat

Sean (Jul 02 2026 at 17:07):

at the end of the day, I want to be able to open something like the shipping_container.g model (which is in our installed db directory), have it give an in-app compile-style listing of all the warnings/errors/issues the model has -- with enough detail and/or features to help with fixing them, and otherwise ready for an end-user in that narrow use case. If it can generate an actual report, even better, but that gets to the polish phase for sure.

Daniel Rossberg (Jul 02 2026 at 17:20):

Regarding the hardcoded values, especially the gqa grid size: I consider it as an important feature to have them editable. It's only a small step from fast, but useless results to insane run-times. Its always a model specific optimization process to find the best parameters for me.

In future versions, this could be done automatically (maybe), but for now, I imagine something like input fields in the test selection dialog.

Daniel Rossberg (Jul 02 2026 at 17:25):

Regarding the results table: There would be still the full output in the console window.

Kanchan Borole (Jul 03 2026 at 03:59):

Hi @Divyanshu Garg, yes, I am able to join the call at 9:00PM IST. Looking forward to it!

Divyanshu Garg (Jul 03 2026 at 11:59):

GSoC BRL-CAD: Geometry V&V GUI in Qt
Friday, Jul 3 · 9–9:30 PM
Google Meet joining info
Video call link: https://meet.google.com/qrn-bnhn-oqq

Daniel Rossberg (Jul 03 2026 at 15:50):

Sean (Jul 03 2026 at 16:07):

Divyanshu Garg (Jul 03 2026 at 16:12):

Sean (Jul 03 2026 at 17:14):

If I can get it to post, here's the baseline video -- shows at the 1:10 mark the detailed panel when you right-click the description column. Shows the ged command side-window. Also shows right-click visualizing geometry about 15 seconds after.

Sean (Jul 04 2026 at 19:28):

Daniel Rossberg (Jul 04 2026 at 19:38):

Kanchan Borole (Jul 05 2026 at 10:16):

Kanchan Borole (Jul 05 2026 at 10:21):

I have a follow-up question regarding the results table improvement. I was looking at the screenshot you shared earlier, and I wanted to make sure I understand the structure correctly. From my understanding, each issue (such as an error or warning) would appear as its own row in the results table. For filtering, we could have options to show only errors or only warnings, while keeping the complete list available as it is now. Could you please confirm if this is the right approach?

Daniel Rossberg (Jul 05 2026 at 17:55):

Kanchan Borole (Jul 06 2026 at 12:31):

I’ve updated the results table. Here’s a quick demo of the changes:
VV Results Table.webm

Please let me know if you'd like me to improve or change anything. For the Duplicate ID section, I kept it as a single block. I thought that if I split every entry into separate rows, it might increase the error count and also separate the related information (ID, MAT, and Region association), which could make it harder to read.
I'm not sure if this is the right approach, so I wanted to get your opinion. Should I keep it as a single list, or should I format it the same way as the other errors?

Divyanshu Garg (Jul 06 2026 at 16:31):

Divyanshu Garg (Jul 06 2026 at 16:32):

Divyanshu Garg (Jul 06 2026 at 16:33):

I do have one UI/UX suggestion for this one, i see that you used 4 buttons for applying the filters, how about we use a dropdown for selecting the filter, this will also reduce the space taken by the buttons and actively show which filter is active.
This might also make it future proof since we can add as much options we want in the dropdown but for the button style it can get crowdy

Kanchan Borole (Jul 07 2026 at 08:09):

Hi @Divyanshu Garg, yes, exactly. That's the parent object. I grouped the validation issues under it as child rows so that issues related to the same object stay together.

I have also implemented the filtering dropdown in the V&V widget to replace the previous button-based layout. Could you please take a look and let me know if this implementation looks correct, or if you'd like any changes?
VV_Filter_Dropdown_Demo.webm

Divyanshu Garg (Jul 07 2026 at 08:14):

Hey @Kanchan Borole this look much better, a great option would be if we put the dropdown on the right side where we have the text Warnings:50 | Errors: 50 | Passed: 50, rest seems fine, though i see the rows are thick but are much improved from the prev iteration

Kanchan Borole (Jul 07 2026 at 09:06):

I've moved the dropdown to the right side. Please check if this looks better now!

Divyanshu Garg (Jul 07 2026 at 09:07):

Divyanshu Garg (Jul 07 2026 at 12:09):

@Kanchan Borole i was going through the proposal
And seems like there were in total 8 objectives and you managed to complete 7 of them right?

Kanchan Borole (Jul 07 2026 at 13:03):

Honestly, the implementation order changed a bit as the project progressed, so I don't think I've completed all 7 objectives yet. I mainly focused on getting the core V&V workflow and the results table working first. Objectives 5, 6, and 7 are mostly related to the report generation part. The UI for that is already done, but I've kept the backend logic for the polish phase. So, I think those objectives are partially completed at this stage.

Divyanshu Garg (Jul 07 2026 at 18:56):

Okay, let's prioritize completing the previous objectives. One other thing except this is the Visual linking part right?

Kanchan Borole (Jul 08 2026 at 04:47):

Yes, other than the report generation part, the remaining objective is the visual linking feature.

Divyanshu Garg (Jul 08 2026 at 08:53):

Sean (Jul 10 2026 at 05:46):

Sorry about that -- try again now. There's something strange going on with the server, packets stalling out over ssh for some reason and it's been causing issues, consuming attention.

@Kanchan Borole see if you can reproduce everything in the video. if not, I think that's baseline functionality to keep working towards. from memory, it showed a progress bar updating, they showed right-clicking to get more detail on a given issue, and right click to visualize the objects affected.

Sean (Jul 10 2026 at 05:58):

I think it should not display the ID table in the Description column. It should just say a summary of the ID number, not the objects matching that ID like:
Duplicate region ID, 2 instances: 2014

And there should be an entry for every unique ID if we're following the compiler-warning pattern. Same with all the tests that return separate issues, like a row per empty region, a row for every nested comb, etc.

Kanchan Borole (Jul 10 2026 at 12:44):

Sean (Jul 10 2026 at 12:58):

I think that looks good Kanchan. Can you try Daniel's case? Run havoc.g -- it has a lot of them.

Kanchan Borole (Jul 10 2026 at 13:24):

Sean (Jul 10 2026 at 21:53):

awesome, that looks a lot better @Kanchan Borole ! What do you think about the message format? Feels like it could be a little better, maybe a bit more concise:

Sean (Jul 10 2026 at 21:54):

Kanchan Borole (Jul 11 2026 at 06:04):

And yes, I watched the video. I like those ideas, and I'll try to implement the remaining UI improvements, including the progress bar, enhanced Test Result Details, and visual linking.

Kanchan Borole (Jul 11 2026 at 06:09):

Thank you for the encouraging midterm feedback. I really appreciate it. I'll definitely keep working on the suggested improvements.

Sean (Jul 11 2026 at 17:21):

You shouldn't have to implement what's in the video from scratch hopefully -- that was the starting baseline. You have that code. It's a matter of figuring out how to do that in the latest arbalest, and whether it's something arbalest should be doing or something the app/plugin/whatever is registering.

How is the current table view implemented? Is that front-end code in the app, and how is it registered with Arbalest?

Kanchan Borole (Jul 12 2026 at 10:01):

The current table view is implemented in VVWidget, which is part of the application's front-end code and currently resides within the plugin structure. VVWidget is created from MainWindow . I'm not completely sure what you mean by "registered with Arbalest." Are you referring to some specific registration or integration mechanism between the application/plugin and Arbalest? If so, could you please explain it a bit? I'd like to make sure I'm looking at the right part of the code.

Kanchan Borole (Jul 14 2026 at 08:43):

Kanchan Borole (Jul 16 2026 at 14:45):

Hi @Sean , just following up on the table implementation. I'm still a bit unsure what you meant by "registered with Arbalest." Also, based on previous message, could you please clarify how you think this should be implemented in the latest Arbalest? I just want to make sure I'm following the right approach before continuing.

Sean (Jul 18 2026 at 03:36):

@Kanchan Borole I think you answered my question -- that the table widget is a new class and it's added to arbalest as a plugin. I was asking, not suggesting how.

the old V&V gui code you started with was essentially a fork of arbalest that was then heavily modified to become a different application. One of the goals for your project, at least as I understand it, is redoing the work so arbalest is only minimally altered and the V&V customizations happen more dynamically (e.g., via plugins).

Sean (Jul 18 2026 at 03:38):

the table view is one such customization, the more info window in the video demo is another.

so I was just trying to understand what the nature of the modification was in arbalest to get the table view working.

Sean (Jul 18 2026 at 03:39):

(like could you recreate the video doing everything they did using your version?)

Kanchan Borole (Jul 18 2026 at 13:38):

Thanks for the clarification! At the moment, here's the current status:
Completed: Validation Logic, Main UI Framework (Table View, Buttons & Controls), Results Table Integration
Remaining: Progress Bar (currently in progress), Report Generation, Test Result Details (More Info pop-up), Visual Linking
I'll continue working on the remaining parts and try to recreate those in the current version.

Kanchan Borole (Jul 18 2026 at 13:41):

I tried implementing the Progress Bar. This is the current prototype.
Screencast from 2026-07-18 18-37-02.webm
Please let me know if you have any suggestions for improving the UI/UX.

Sean (Jul 21 2026 at 05:52):

@Kanchan Borole that looks pretty good -- do you know if it has feature parity on what it did before? (specifically the progress bar). I seem to recall the status bar would even pick up where it left off if a job was aborted or the app crashed'

Kanchan Borole (Jul 22 2026 at 11:37):

I haven't implemented this behavior in the current version. I'm not sure whether the previous implementation supported resuming the progress bar after an aborted job or application crash. Could you clarify if this behavior is expected in the current implementation?

Sean (Jul 23 2026 at 07:39):

@Kanchan Borole that was more a curiosity -- it doesn't need to resume the progress bar. I didn't know if you could tell from the demo video. more important is the remaining two things demonstrated which is the more info window and the mouse binding on an issue and having it update the display.

Kanchan Borole (Jul 23 2026 at 07:58):

Thanks for clarifying about progress bar! I tried working on the visual linking feature and tested on shipping_container.g. I think it's working, but I'm not completely sure if this is the expected behavior. Here's a demo video:
Screencast from 2026-07-23 11-41-33.webm

However, when I tested it with havoc.g, clicking "Visualize Object" highlights the entire Havoc model instead of the specific sub-parts. I'm not sure if that's the expected behavior for Havoc or if I need to refine the logic. Here's the Havoc testing video for reference:
Screencast from 2026-07-23 11-39-01.webm
Please let me know if I'm on the right track or if any changes are needed.

Sean (Jul 23 2026 at 13:51):

Something isn't right for sure though. I see no difference between what you're doing in the first vs the second. Both list out paths that presumably should be what it draws, but clearly showing the subregion for the first and top-level for the second.

See if you can figure out what's wrong there -- it should (only) display the region(s) being reported. Maybe it's drawing the region but also drawing havoc or something.

Does it just draw when you click visualize or did you have to rotate/move the view?

Kanchan Borole (Jul 23 2026 at 16:13):

Thanks for the feedback! No, it doesn't draw automatically right away—I have to click or slightly rotate the view in the viewport for it to refresh and render the changes.

I updated the logic to filter out the root/parent containers so it only targets the specific sub-parts instead of the whole model. Here's the updated testing video for havoc.g:
Screencast from 2026-07-23 21-30-42.webm

Could you please confirm if the logic is correct, or if I'm still missing something?

Sean (Jul 23 2026 at 20:01):

You need the full paths, you can’t filter them off without manually tracking the full path matrix

Sean (Jul 23 2026 at 20:04):

Sean (Jul 23 2026 at 20:07):

Otherwise your video seems to be doing well. The test would be drawing some issue where the region has a matrix above its path in some parent comb

Stream: Google Summer of Code

Topic: Geometry Verification and Validation GUI in Qt

Divyanshu Garg (May 01 2026 at 08:20):

Divyanshu Garg (May 01 2026 at 08:20):

Kanchan Borole (May 01 2026 at 08:42):

Divyanshu Garg (May 01 2026 at 09:17):

Divyanshu Garg (May 01 2026 at 09:33):

Divyanshu Garg (May 01 2026 at 09:37):

Kanchan Borole (May 01 2026 at 10:16):

Kanchan Borole (May 02 2026 at 05:17):

Divyanshu Garg (May 02 2026 at 07:25):

Divyanshu Garg (May 02 2026 at 07:31):

Divyanshu Garg (May 02 2026 at 07:32):

Divyanshu Garg (May 02 2026 at 07:36):

Kanchan Borole (May 02 2026 at 07:39):

Divyanshu Garg (May 02 2026 at 07:51):

Kanchan Borole (May 03 2026 at 05:01):

Divyanshu Garg (May 03 2026 at 07:30):

Divyanshu Garg (May 03 2026 at 07:51):

Kanchan Borole (May 03 2026 at 15:08):

Daniel Rossberg (May 03 2026 at 16:20):

Kanchan Borole (May 04 2026 at 08:52):

Divyanshu Garg (May 04 2026 at 16:36):

Himanshu (May 04 2026 at 19:25):

Kanchan Borole (May 05 2026 at 09:08):

Kanchan Borole (May 05 2026 at 09:08):

Divyanshu Garg (May 05 2026 at 09:30):

Divyanshu Garg (May 05 2026 at 09:30):

Daniel Rossberg (May 05 2026 at 10:33):

Kanchan Borole (May 05 2026 at 13:58):

Sean (May 05 2026 at 16:50):

Kanchan Borole (May 06 2026 at 09:55):

Divyanshu Garg (May 06 2026 at 09:56):

Kanchan Borole (May 06 2026 at 10:03):

Divyanshu Garg (May 06 2026 at 10:09):

Kanchan Borole (May 06 2026 at 10:24):

Daniel Rossberg (May 06 2026 at 10:31):

Kanchan Borole (May 06 2026 at 10:35):

Daniel Rossberg (May 06 2026 at 10:48):

Daniel Rossberg (May 06 2026 at 10:52):

starseeker (May 06 2026 at 11:29):

Daniel Rossberg (May 06 2026 at 12:12):

Divyanshu Garg (May 06 2026 at 15:28):

Daniel Rossberg (May 06 2026 at 19:20):

starseeker (May 07 2026 at 00:10):

Daniel Rossberg (May 07 2026 at 14:35):

Kanchan Borole (May 08 2026 at 12:09):

Divyanshu Garg (May 08 2026 at 12:12):

Kanchan Borole (May 08 2026 at 12:18):

Divyanshu Garg (May 08 2026 at 12:24):

Himanshu (May 09 2026 at 14:18):

Himanshu (May 09 2026 at 14:19):

starseeker (May 09 2026 at 19:25):

Kanchan Borole (May 11 2026 at 09:06):

Sean (May 12 2026 at 20:34):

Daniel Rossberg (May 13 2026 at 07:18):

Kanchan Borole (May 13 2026 at 12:10):

Daniel Rossberg (May 14 2026 at 13:47):

Sean (May 14 2026 at 20:29):

Kanchan Borole (May 17 2026 at 09:12):

Sean (May 18 2026 at 15:08):

Kanchan Borole (May 20 2026 at 11:22):

Kanchan Borole (May 24 2026 at 10:53):

Divyanshu Garg (May 24 2026 at 11:10):

Kanchan Borole (May 24 2026 at 11:39):

Divyanshu Garg (May 24 2026 at 11:40):

Kanchan Borole (May 25 2026 at 05:27):

Himanshu (May 25 2026 at 17:40):

Himanshu (May 25 2026 at 17:42):

Kanchan Borole (May 26 2026 at 06:03):

Kanchan Borole (May 28 2026 at 05:11):

Divyanshu Garg (May 28 2026 at 15:08):

Kanchan Borole (May 28 2026 at 15:27):

Himanshu (May 29 2026 at 12:46):

Himanshu (May 31 2026 at 07:33):

Himanshu (May 31 2026 at 07:34):

Himanshu (May 31 2026 at 07:35):

Kanchan Borole (May 31 2026 at 08:28):

Himanshu (May 31 2026 at 21:02):

Himanshu (May 31 2026 at 21:05):