claymonkey (May 18 2025 at 13:21): claymonkey (May 18 2025 at 13:21):import IGES or STEP
error！！！
Sean (May 19 2025 at 04:07):@claymonkey iges import is tricky as you have to know and specify the type, and even then it can have problems if the data is not clean -- there are lots of iges exporters that export junk.
with step import, the most common cause is trying to import something that is not ap203e1 -- that's all that's presently supported. some like ap214 or e2 are also common.
claymonkey (May 27 2025 at 13:43):I tried to use the reading method of OpenCaseCAD to parse IGEs. However, it was very troublesome to convert all faces into NURBSface+NURBScurve logic. Especially when I wanted to translate the type into other BREPS models, the speed was very unsatisfactory. This reminded me of the BREPS structure in the current software, but errors frequently occurred when I tried to import it.
Sean (May 30 2025 at 18:25):@claymonkey what is your use case, end goal?
claymonkey (Jun 01 2025 at 02:17):(deleted)
claymonkey (Jun 01 2025 at 02:17):Try to parse the CAD file by yourself and convert it into a creatable BREP type.
Sean (Jun 01 2025 at 04:22):@claymonkey so just for the technical challenge? or some other purpose? parsing and converting from iges/step to some brep in-memory structure is not exactly an end-use case..
If you're working with BRL-CAD, the 3dm-g is by far the best brep import method that imports faithfully & natively using OpenNURBS. Next best is step-g if it's an ap203e1 file. The iges-g importer hasn't been tested or used in production use for nearly a decade, but it has extensive code for multiple import methods and encoding types (including automatic re-encoding of bspline to NURBS) but also less reliable if there are any errors in the geometry.
claymonkey (Jun 01 2025 at 08:35):Because I found that the Brep type of openNurbs is quite similar to that of opencascad, when some programs do not support certain operations, I thought of using the underlying feedback information to create corresponding ones, hoping that other open-source methods can handle them more precisely.
Sean (Jun 01 2025 at 13:58):It is indeed similar, but not 1-1 identical if memory serves.
Sean (Jun 01 2025 at 13:59):so are you looking to bridge geometry from some application built on opencascade into brl-cad, to some operation that brl-cad handles better, and then convert it back?
claymonkey (Jun 01 2025 at 14:03):Yes, if multiple software functions are combined, then only common cad types can be used for conversion. After all, brep will not be exactly the same
Sean (Jun 01 2025 at 14:04):that would certainly be feasible for brep and/or polygonal types I'd think
Sean (Jun 01 2025 at 14:07):problematic encodings are typically: implicits, csg booleans, volumetric/voxel data, level sets, subdivision surfaces, t-splines, medial axis, signed distance fields, and parametric ops like sweep/loft/extrude
Sean (Jun 01 2025 at 14:09):brep is more amenable, includes triangles, polygons, bezier patches, b-spline patches, and nurbs surfaces
claymonkey (Jun 01 2025 at 14:12):Perhaps FACE can be parsed as a combination of the basic NurbsSurface and CurvesToTrimed
. Then perhaps in any logic, there will be corresponding creation methods.
starseeker (Jun 01 2025 at 23:54):There was some work done a while back on opennurbs -> opencascade, IIRC - I think it was this? https://www.cnblogs.com/opencascade/p/opennurbs2opencascade.html
starseeker (Jun 01 2025 at 23:55):I recall hunting around a while back because going to/from opennurbs and opencascade data types would be a keystone of a converter of .g geometry to/from FreeCAD
starseeker (Jun 01 2025 at 23:56):It would be really awesome if we had two way communication with FreeCAD, but my recollection is that the problem is fairly involved - NURBS BRep objects have a LOT of subtypes, and there are subtleties that need to be taken into account.
Sean (Aug 15 2025 at 16:37):@Daniel Rossberg do you work much with BoT models? curious to hear if you or users you work with see noticeable change
Daniel Rossberg (Aug 15 2025 at 16:56):The model creation is usually done with a commercial CAD, and then transferred via STL. Therefore, I would say yes. We'll keep an eye on it.
Sean (Aug 15 2025 at 17:51):Yeah, that should definitely be impacted.... in a pretty big way. Curious to know how much for you.
Sean (Aug 15 2025 at 17:51):I have crunched a lot of numbers that I'll share here publicly soon, probably this upcoming week as I'm documenting them in even more detail.
Sean (Aug 15 2025 at 17:54):seeing anywhere from 2x-20x on most models, some even going 200-2000x but atypical. if you were using adrt, the main difference is that really long prep time is now gone. if you weren't using adrt, prep is about same (ie. fast) but ray tracing is going to be 100+ times faster on most models.
Sean (Aug 15 2025 at 17:54):Generic BRL-CAD article in the news: https://www.3dnatives.com/en/brl-cad-the-design-software-created-for-defense-140520256/
Kanchan Borole (Nov 16 2025 at 14:11):Hi everyone,
I’m currently working on setting up the Arbalest V&V GUI project and wanted to ask for some guidance regarding build issues.
What I’ve done so far
Forked and cloned the Arbalest repository
Installed Qt, CMake, and all required dependencies
Tried building Arbalest following the available instructions
Issues I’m facing
The code in Arbalest does not seem to match the structure of the latest BRL-CAD version. Several BRL-CAD libraries appear to be renamed or missing in the latest release I could not find a BRL-CAD version where the file structure matches the Arbalest source Specifically, the db folder expected by Arbalest seems to be missing in recent BRL-CAD builds, causing additional errors. Some libraries referenced in the code seem outdated or changed, and I cannot locate their new equivalents
What I need help with
Could anyone please tell me which BRL-CAD version Arbalest was originally developed/tested with, so I can download the matching version and build successfully?
Kanchan Borole (Nov 30 2025 at 14:03):Hi everyone,
I’m setting up the Geometric Verification & Validation GUI in Qt project on Windows using CMake + MinGW + Qt 6.10.0, and I’ve followed these steps:
BRL-CAD_DIR in CMakeRan CMake in a build folder:
cmake .. -G "MinGW Makefiles" -DCMAKE_PREFIX_PATH="C:\Qt\6.10.0\mingw_64" -DQt6_DIR="C:\Qt\6.10.0\mingw_64\lib\cmake\Qt6"
Ran mingw32-make – moc files generate successfully, but compilation fails at MainWindow.cpp with:
C:/PROGRA~1/BRL-CA~1.2/include/brlcad/rt/comb.h:30:12: fatal error: opennurbs.h: No such file or directory
30 | # include "opennurbs.h"
also there is an error of NOMINMAX
I understand that opennurbs.h is part of OpenNURBS, which may not be included in the BRL-CAD binary. I’m not sure if I need to:
Daniel Rossberg (Nov 30 2025 at 18:48):I don't know much about the V&V version of arbalest, but opennurbs.h should still be in the include folder of your BRL-CAD installation. Maybe, in the OpenNURBS directory?
Kanchan Borole (Dec 15 2025 at 13:21):Thanks for the clarification!
I checked my BRL-CAD installation and found the openNURBS directory under the include folder, and I can see the header files there. There is some header name issues.
To avoid version mismatches, I’m currently rebuilding BRL-CAD from source locally and configuring Arbalest against that build. I’ll update once I get past the current build issues.
Shayan Ghosh (Dec 18 2025 at 18:03):Hey everyone,
I’m Shayan. I’m a working professional with experience in Node.js, React, and Three.js, and I’m very interested in getting started with open-source contributions.
I recently came across BRL-CAD and noticed an issue related to the OGV project, which was mentioned as part of GSoC 2025 ideas. From what I understand, OGV is an older project that could benefit from significant updates and the addition of new features, and I’d be really excited to contribute to its development.
Although I’ve noticed that there hasn’t been much recent activity on this project, I’m quite curious to work on it. I wanted to ask whether contributions to OGV are still welcome, and if there is any recommended way to get started or specific areas that need attention.
I also had a quick question regarding the future of this project. Is OGV expected to be proposed again for GSoC 2026?
Sean (Dec 31 2025 at 21:09):@Kanchan Borole any progress getting it to build? feel free to share build issues you're stuck on.
@Shayan Ghosh welcome! there has been recent activity -- it was a gsoc project just this past summer where it was prototyped as a pastebin-style webapp for geometry sharing.
Kanchan Borole (Jan 02 2026 at 12:26):@Sean Hi, I wanted to share a brief update and ask for some guidance.
I’ve been working on building BRL-CAD from source on Windows. I was able to clone the repository and set up the toolchain, and initially tried the Visual Studio generator. Due to long configure times and generator issues, I switched to using Ninja, which has been more stable so far.
At the moment, I’m running into problems during the bext external dependency build step, and I’ve been trying clean rebuilds and different configuration options to understand it better. I wanted to check whether this is the right approach on Windows, or if there’s a recommended setup or workflow you’d suggest for this stage.
Thanks — I’d appreciate any pointers.
Daniel Rossberg (Jan 02 2026 at 16:55):The long configuration time for brlcad is expected, because it includes the build of the external dependencies in bext. You can try to build bext separately instead:
cmake <path to the bext sources> -DCMAKE_BUILD_TYPE=Debug -DENABLE_ALL=ON at the end of the cmake commandcmake <path to the brlcad sources> -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=<path to a directory, where you can install the program without administrator rights> -DBRLCAD_EXT_DIR=<path to the bext build directory from the step before> Sean (Jan 04 2026 at 07:42):Everything Daniel said @Kanchan Borole
Ninja is definitely the faster path though I more often test the default non-ninja generator path myself. Configure will take a long time because it downloads and compiles all external deps like Daniel mentioned. Both should work though -- if they don't please share the first couple error.
Note that by default the cmake build of the "brlcad" repo automatically obtains and compiles the "bext" repo. If you clone and compile "bext" yourself, you do want to set that BRLCAD_EXT_DIR variable. I do not usually open the solution myself unless I'm building a release, instead just relying on the default visual studio cmake configuration and compilation of everything. Others here do regularly open the solution as their preferred approach which has way more options.
Kanchan Borole (Jan 04 2026 at 09:41):Thanks @Daniel Rossberg and @Sean for the guidance.
I followed the suggested workflow and tried building bext separately using Ninja in a clean build directory. The CMake configuration completed successfully, but the build consistently fails during External Project steps (notably PROJ / GDAL / GEOGRAM), with errors related to missing PROJ libraries and dependency build failures.
I then tried the alternative approach of opening the brlcad repository directly in Visual Studio and relying on the default CMake configuration to build bext automatically, but it still ends with -
CMake Error at misc/CMake/BRLCAD_Util.cmake:102 (_message):
Unable to successfully build bext dependency repository
At this stage, I wanted to ask what the recommended next step would be on Windows — whether there’s a preferred workaround (partial build, disabling certain deps, prebuilt deps).
Daniel Rossberg (Jan 04 2026 at 16:20):From your description, it looks like the PROJ build fails. Why? What's the CMake output regarding the compilation error there? What's in the logfiles?
(Currently, I've no Visual Studio at hand.)
Kanchan Borole (Jan 06 2026 at 13:07):Earlier, I was building using Command Prompt with Ninja(Bext Separately), and in that attempt the build failed while compiling the PROJ external dependency (GDAL/PROJ-related errors).
After that, I cleaned everything and opened the brlcad folder directly in Visual Studio to let CMake handle bext automatically. In this fresh Visual Studio configuration, the build now stops earlier in the dependency chain at GEOGRAM, so PROJ is not reached or downloaded in this run, which is why PROJ logs are not present now.
The current failure in Visual Studio is:
[CMake] Building Custom Rule .../bext/gdal/CMakeLists.txt
[CMake] Completed 'TKTABLE_BLD'
[CMake] Completed 'GDAL_BLD'
[CMake] CMake Error at misc/CMake/BRLCAD_Util.cmake:102 (message):
[CMake] Unable to successfully build bext dependency repository
[CMake] Call Stack (most recent call first):
[CMake] misc/CMake/BRLCAD_EXT_Setup.cmake:442 (message)
[CMake] misc/CMake/BRLCAD_ExternalDeps.cmake:529 (brlcad_ext_setup)
[CMake] CMakeLists.txt:2114 (brlcad_bext_process)
I’m attaching a Word file with the relevant CMake output and logs (screenshots attaching aren’t working on my system currently). Please let me know whether you’d like me to rerun specifically to reproduce the PROJ failure again, or if debugging GEOGRAM first is the correct next step on Windows.
Word File Link - https://docs.google.com/document/d/1kQzoFzuWVjckSlX53hVw0G1QuUAm3Aig/edit?usp=drive_link&ouid=117474697357203901480&rtpof=true&sd=true
Erik (Jan 07 2026 at 00:04):downloading and compiling external deps during the cmake phase is lame, especially for systems with lots of CPUs available. Can they be cloned and folded in during the ninja/make phase?
Erik (Jan 07 2026 at 00:06):I'm all in on ninja, regressing to make when ninja is available is a loss, though the capability should be maintained. CMake is pretty good about this in general
Daniel Rossberg (Jan 07 2026 at 16:27):@Kanchan Borole, should I have mentioned that you have to call cmake in a Visual Studio shell? I've just tested the bext build with Visual Studio 2019 and it worked with the formerly posted CMake command followed by cmake --build . I haven't fully analysed the your Word file, but the first lines suggest that you haven't used a Visual Studio shell.
Kanchan Borole (Jan 08 2026 at 13:37):@Daniel Rossberg , thanks for pointing that out and for testing it on your side. I did rerun the entire bext build from the Visual Studio Shell after your guidance. With that, all dependencies completed successfully — only GEOGRAM fails.
The Error is -
C:/Users/DELL/Documents/brlcad-work/build-bext/geogram/GEOGRAM_BLD-prefix/src/GEOGRAM_BLD-stamp/GEOGRAM_BLD-build-*.log
-- stdout --
MSBuild version 18.0.5+e22287bf1 for .NET Framework
poisson_geogram.cpp
C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.50.35717\include\xmemory(1525,23): error C2440:
'static_cast': cannot convert from 'const _Alloc' to 'GEO::Memory::aligned_allocator<U,64>'
C:\Users\DELL\Documents\brlcad-work\build-bext\geogram\GEOGRAM_BLD-prefix\src\GEOGRAM_BLD\src\lib\geogram\basic\memory.h(624,1):
no matching constructor; failed conversion for std::vector<T, GEO::Memory::aligned_allocator<T,64>>
-- stderr --
MSBuild\Microsoft\VC\v180\Microsoft.CppCommon.targets(254,5): error MSB8066:
Custom build for GEOGRAM_BLD exited with code 1
Daniel Rossberg (Jan 08 2026 at 17:32):This could be caused by your new compiler (Visual Studio 2026). Maybe the current geogram (https://github.com/BrunoLevy/geogram) can be build with VS2026. Maybe applying https://github.com/BrunoLevy/geogram/commit/5c18dc89209189ab7b507ad230b50ef2952cae49 to your code (cloned repository) helps. Hard to say, I'm still using VS2019.
Kanchan Borole (Jan 12 2026 at 14:06):Thanks, Using Visual Studio 2019, GEOGRAM now builds successfully and the bext build completes without errors. I’m now proceeding with the BRL-CAD build as the next step and will update once that finishes.
starseeker (Jan 13 2026 at 04:27):Erik said:
downloading and compiling external deps during the cmake phase is lame, especially for systems with lots of CPUs available. Can they be cloned and folded in during the ninja/make phase?
@Erik Unfortunately, the answer to that is a hard no. It has to do with how and when CMake's find_package needs to make information about dependencies available. Our previous generation build system actually did do that in the build phase (the only large scale project I am aware of to actually make that function correctly) but the necessary custom machinery was too extensive to be generally maintainable. Qt, in particular, cannot be successfully managed as a dependency the way we were doing it in the previous iteration (although it's not the only problem child.
starseeker (Jan 13 2026 at 04:28):That's why the recommended approach for serious development is to build bext yourself separately, and then point the BRL-CAD CMake to the prepared bext outputs. It avoids more than the minimum copy and prep work during configure.
Kanchan Borole (Jan 14 2026 at 14:09):I rebuilt bext from scratch with VS2019 using
cmake ..\src\bext -G "Visual Studio 16 2019" -A x64 -DBRLCAD_ENABLE_RLE=ON
followed by cmake --build . --config Debug.
The build completes successfully, but no UTAHRLE artifacts are produced —
dir . /s | findstr utahrle returns nothing.
When configuring BRL-CAD, CMake fails with
Could NOT find UTAHRLE (UTAHRLE_LIBRARY, UTAHRLE_INCLUDE_DIR).
Could you advise whether UTAHRLE is expected to build on Windows, or if it should be disabled / handled differently in the Windows toolchain?
Daniel Rossberg (Jan 14 2026 at 15:08):UTAHRLE was removed from bext: https://github.com/BRL-CAD/bext/commit/cfdef3de771c38a7da7a4edea2b61541c029ae6a
See also https://github.com/BRL-CAD/brlcad/commit/446c9604feaecf9a90c58213e65f06f6a0aa65cf (however, github shows a warning for this commit)
If
doesn't solve the problem, you should ask @starseeker for help.
Kanchan Borole (Jan 21 2026 at 16:24):After updating BRL-CAD and rerunning CMake, BRL-CAD builds successfully on Windows (mged/rt working). While building with VS 2019, I fixed an MSVC-specific issue in bot.c related to _Thread_local.
While configuring Arbalest, CMake fails to find Qt6 with VS 2019:
Could not find Qt6Config.cmake
It appears current Qt 6 Windows installers no longer provide MSVC 2019 builds, so I moved to VS 2022 + Qt 6 (MSVC 2022). With VS 2022, BRL-CAD configuration proceeds, but I am currently resolving an ASM-related issue during bext (PNG) builds (No CMAKE_ASM_COMPILER could be found) This persists despite NASM/ML64 being installed and available in PATH. At this point I may be missing a BRL-CAD–specific or Windows-specific configuration detail — could you advise the correct approach here, or whether ASM should be explicitly disabled for this dependency?. I am actively debugging this and continuing the rebuild cleanly.
Please let me know if this direction looks correct.
Daniel Rossberg (Jan 21 2026 at 18:04):Indeed, there was a discussion regarding the _Thread_local issue last year:
Regarding Arbalest and Qt6: You could build brlcad and MOOSE with MSVS 2019 and arbalest with MSVS 202x. This should work. Arbalest (at least the version on GitHub) has the MOOSE library as only BRL-CAD dependency.
Kanchan Borole (Jan 23 2026 at 14:09):Following advice - building BRL-CAD + MOOSE with MSVC 2019 and Arbalest with MSVC 202x.
Earlier, BRL-CAD built successfully with VS 2019 (including mged). During the Qt/Arbalest investigation, I switched to VS 2022, did a clean rebuild, and later reverted back to VS 2019 as suggested. After the clean rebuild and switching back to VS 2019, I am now consistently hitting an ASM/PNG issue during bext, which I did not encounter earlier with the same toolchain:
CMake Error at CMakeLists.txt:28 (project): No CMAKE_ASM_COMPILER could be found.
This occurs during the PNG step in bext, even when configuring from the VS 2019. I’m currently debugging this, but wanted to confirm whether this is a known bext/PNG edge case on Windows or if there’s a recommended way to bypass/handle ASM for PNG in this setup.
Daniel Rossberg (Jan 23 2026 at 20:28):I haven't seen it before, but googling for "No CMAKE_ASM_COMPILER could be found" gives e.g. https://gitlab.kitware.com/cmake/cmake/-/issues/17532
Parag Debnath (Feb 01 2026 at 17:02):hey @Daniel Rossberg is this issue https://github.com/opencax/GSoC/issues/52
still open ,or it has been completed as it was proposed way back in 2022
Daniel Rossberg (Feb 02 2026 at 08:56):Hi @Parag Debnath, the Python bindings are still open. No work was done regarding this issue last year. I can however not promise that BRL-CAD will apply for GSoC 2026.
Shorya Singhal (Feb 12 2026 at 18:59):I’m trying to build BRL-CAD on Windows using Visual Studio, but I’m encountering an issue related to the bext dependency repository.
Environment,
cmake .. -DBRLCAD_ENABLE_STRICT=NO -DBRLCAD_BUNDLED_LIBS=ON -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 16 2019"
Error Encountered
CMake Error at misc/CMake/BRLCAD_Util.cmake:102 (_message):
Unable to successfully build bext dependency repository, Call Stack (most recent call first):, misc/CMake/BRLCAD_EXT_Setup.cmake:442 (message), misc/CMake/BRLCAD_ExternalDeps.cmake:529 (brlcad_ext_setup), CMakeLists.txt:2114 (brlcad_bext_process)
Hi, I’ve been working with BRL-CAD locally using the binary installation, and MGED is running correctly on my system. I also cloned Arbalest and have been reviewing the Qt structure to understand how the main window and widgets are organized. I attempted building BRL-CAD from source but encountered a compiler/ASM issue, so for now I’m continuing exploration using the binary setup.
I’d like to begin contributing on the GUI side. Since the Geometry Validation & Verification project focuses on developing a validation interface, would it be aligned with the current direction if I start by adding a modular “Geometry Validation” dock/panel skeleton (for example, an issues table and summary UI) that can later integrate validation results?
I want to make sure I’m contributing in the correct architectural direction before proceeding further.
Sean (Feb 23 2026 at 18:43):Hi @Kanchan Borole did you check out the prior geometry V&V GUI work-in-progress code? It should be linked on the idea page but ping me if it's not there.
Basically, you are on the right track, but there has been some work on the V&V GUI. My thoughts on priorities would be 1) to update to the latest Arbalest codebase as previous effort was a couple years ago as a fork and it hasn't been kept up-to-date in sync and 2) to vastly improve the visualization and workflow aspects. The latter is open-ended but hard to discuss without you first seeing what was done previously.
Kanchan Borole (Feb 24 2026 at 13:15):Thanks, @Sean — I’d definitely like to review the prior V&V GUI work. The link on the idea page doesn’t seem to be working on my end. Could you share the repository or fork reference? I want to see the previous implementation and evaluate what would be needed to bring it in sync with the latest Arbalest codebase.
Sean (Mar 01 2026 at 22:36):@Kanchan Borole certainly it can be shared but I’ll check in the link too. It’s repo was transferred so we may need to do something administratively.
Kanchan Borole (Mar 09 2026 at 12:15):Hi @Sean , just checking in regarding the repository link you mentioned earlier. I’m currently working on the design and documentation exploration for the project, so reviewing that code would really help. Please let me know whenever the link becomes available. Thanks!
Володимир (Mar 10 2026 at 06:27):please help me install brlcad on arch linux
Aaditya Saraf (Mar 10 2026 at 20:50):Hi @Sean @Daniel Rossberg .
I am Aaditya, a fourth year undergraduate currently.
I am fairly new to C++ programming, most of my experience with it is rooted in solving leetcode problems, although I am very interested in learning how real-world applications are built using it.
I am currently leaning towards working on NURBS editing support in BRL-CAD, mainly because I have some background in it's theory from a course I took.
Could you let me know what the next steps should be? Is there a beginner-friendly guide or something? I'd appreciate any guidance on how to start out. Thanks!
Sean (Mar 11 2026 at 20:08):Kanchan Borole said:
Hi Sean , just checking in regarding the repository link you mentioned earlier. I’m currently working on the design and documentation exploration for the project, so reviewing that code would really help. Please let me know whenever the link becomes available. Thanks!
Thank you for the reminder! Apologies on the delay… juggling lots of things at the moment
Sean (Mar 11 2026 at 20:09):@starseeker nice bsd fix… I presume Claude caught it?
Sean (Mar 11 2026 at 20:15):Володимир said:
please help me install brlcad on arch linux
Can you be more specific in what you want? There are build instructions— have you followed them ?
Sean (Mar 11 2026 at 20:17):@Aaditya Saraf that sounds awesome, but definitely an advanced topic that really depends just how much you know.
Sean (Mar 11 2026 at 20:19):Several nurbs relayed proposal possibilities from nurbs editing to Boolean eval to conversion and visualization/ray tracing.
Aaditya Saraf (Mar 11 2026 at 20:34):@Sean Tbh I don't really know much of anything other than NURBS theory and mathematical implementation from a CFD related course I took earlier, but I am willing to learn and catch up on whatever is relevant to this project
Sean (Mar 12 2026 at 02:51):@Kanchan Borole Here is a link to that V&V variant of the arbalest code: https://github.com/isaacy13/arbalest/
The code was really a new effort that was implemented in a manner that doesn't really fit with the scope and design of the main arbalest repo, and the intent wasn't to merge it back in (not that it can or cannot be made mergeable, just wasn't the point). However being a fork has an added benefit that if you can get that version to work as-is, then it could conceivably pull all the upstream improvements there have been to arbalest since that effort.
Kanchan Borole (Mar 12 2026 at 10:42):@Sean Thanks for sharing the repository. I’ve started reviewing the code and will try to get that version working locally so I can better understand the previous V&V GUI implementation and how it relates to the current Arbalest codebase.
starseeker (Mar 13 2026 at 01:28):@Sean Yes - long ago I managed to catch a backtrace of the failure on BSD, but I wasn't able to interpret it properly. Copilot (not sure which engine it chose) spotted it quickly.
Rohit S (Mar 14 2026 at 10:29):Hi @Sean @Daniel Rossberg ,
I'm Rohit S, a CS student. I'm interested in working on the BRL-CAD Python Bindings project for GSoC 2026.
The idea of making BRL-CAD's geometry database properly accessible to Python developers genuinely excites me. I've looked at the existing efforts by kanzure and nmz787 and can see clear gaps in completeness that this project could address well. I'd love to take that forward.
A few questions to get started:
Should the binding layer target pybind11, ctypes, or is that open for the proposal to justify?
Which libwdb/librt functions are the priority to expose first?
Any good-first-issues to get familiar with the build system?
Looking forward to contributing!
Sean (Mar 16 2026 at 03:44):@Rohit S Welcome and glad to hear the excitement! As to your questions, the binding layer is open to your proposal. We do not have a prescribed solution in mind at all, so just be sure to describe and justify what/why you think that way will be best.
As for which functions, that's a little trickier to describe. You could pick a specific function, e.g., creating geometry or converting geometry or something similar. You could also make a choice between using the low-level libwdb/librt APIs or using a higher-level API like MOOSE (cleaner C++ OO lib).
For a good first issue, I'd suggest creating a procedural geometry generator using whichever API you intend to align with (e.g., src/proc-db if libwdb/librt or perhaps a unit test in moose). It can be just about anything interesting. For example, could make a tool that randomly combines primitives using boolean operations to make random shapes (for testing). Could make something that parses .shp file buildings into geometry. Could make a rhombicuboctahedron..
More Niharika Mahesh (B24CS1045) (Mar 16 2026 at 11:54):Hi @Sean ! I am interested for working on Appleseed rendering issues and i had texted on discord in February (i didnt see this zulip link)
I am a second year CSE student from IIT Jodhpur and i love coding in C++. I am also familiar with C.
Kanchan Borole (Mar 23 2026 at 13:45):Hi @Sean , I prepared a draft proposal based on updating the earlier V&V prototype fork you shared and improving its compatibility with the current Arbalest codebase. My approach focuses on extending the prototype by improving the validation workflow visualization, structuring compiler-style warnings and error reporting, and enabling navigation between detected geometry issues through Qt interface panels while using existing BRL-CAD validation routines as the backend.
I tried to keep the design focused on extending the existing prototype rather than introducing a new architecture. Could you please let me know if this direction matches for the project? If you have time to take a quick look at the scope and objectives, I would really appreciate any feedback.
Here is my proposal draft:
https://drive.google.com/file/d/1GYLDoGHwAPVzMLfL6pokSHgGZ8wSlkqm/view?usp=drive_link
Your earlier guidance about updating the prototype and improving workflow visualization helped shape the objectives, so I wanted to confirm that I’m moving in the right direction.
Sean (Mar 24 2026 at 02:59):More Niharika Mahesh (B24CS1045) said:
Hi Sean ! I am interested for working on Appleseed rendering issues and i had texted on discord in February (i didnt see this zulip link)
I am a second year CSE student from IIT Jodhpur and i love coding in C++. I am also familiar with C.
welcome @More Niharika Mahesh (B24CS1045) and glad to hear about the appleseed interest. It's the foundation for advanced rendering in BRL-CAD, but currently stagnated. You'll want to familiarize yourself with the current status, and ask questions.
The dependency stack is pretty big and increasingly out of date. Updating them is not terribly hard, but there is some issue once everything is updated. Likely an OSL change introduced different behavior and appleseed needs to be adapted. But could also be a straight up memory issue (crashes observed on Windows but not Linux).
Sean (Mar 24 2026 at 03:18):Kanchan Borole said:
I tried to keep the design focused on extending the existing prototype rather than introducing a new architecture. Could you please let me know if this direction matches for the project? If you have time to take a quick look at the scope and objectives, I would really appreciate any feedback.
@Kanchan Borole you definitely sound like you're going in the right direction. Your proposal is detailed but if anything is too detailed (repetitively so) without describing substantive goals. It smells of AI generalities, without really saying what you're proposing to do beyond "making it better". In several places, including the timeline, you describe a task you're going to do and it's something that the GUI already does (which the AI wouldn't know).
You really need to run the V&V GUI yourself and see what you think you can improve. Mock up what improvement you'd like to target. You identified "Better layout and UI structure" for example, well you could show that even if it's a pencil sketch or GUI wireframe of what you mean by that. Compare what's there and what you plan to change. You call out "Interactive visualization of detected geometry issues" but have absolutely no plan for how to achieve that yet expect it to take just 2 weeks according to you schedule... unlikely. I could go on, but that's all to say you need more than generalities.
Be specific, give a mocked example, say and show what you're thinking to achieve. And be more reasonable with the timeline. You're not going to redo the visualization and workflows and create an output V&V report and improve the GUI and the dozen other items you mentioned in the short timeframe of GSoC. I want to hear your thoughts and ideas more than you pasting this into AI and you posting the result. You're welcome to use it as a consultant, but you have to own the product, process, goals, and ideas.
Kanchan Borole (Mar 24 2026 at 08:54):@Sean Thank you for the detailed feedback. I’ll run the V&V GUI and look more closely at the current implementation so I can identify specific gaps before refining my proposal. I’ll also prepare simple mockup to better illustrate the UI and workflow improvements I’m proposing. I understand your point about making the proposal more specific and grounded in the current prototype rather than describing general improvements, and I will adjust the scope and timeline to make them more realistic with clearer implementation details.
Sulav (Mar 24 2026 at 14:01):Hi @Sean !
I'm Sulav, a final year undergrad with experience in Next.js, Express.js and exposure of Nest.js. I really like the issue #26(OGV) as you mentioned there you're moving to Next.js and Nest.js with focus on backend. I'd really love to contribute on on that but I find 3D things little bit complex for me. But there's mentioned that it's optional. Should I go for it or look for other issues?
Any recommendations would be great.
Sean (Mar 27 2026 at 05:03):Hi @sulav, and welcome. Your skillset definitely sounds attuned to OGV. I think you should lean to your strengths, whatever they may be. There's a lot of things you could propose to do with OGV that don't require deep understanding of 3D, but you'll have to explore and run the code to probably get an idea what those possibilities might be for you.
Last updated: Mar 31 2026 at 01:22 UTC