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
Last updated: Jan 26 2026 at 01:05 UTC