Ronan Coutinho (Feb 21 2024 at 18:19): Ronan Coutinho (Feb 21 2024 at 18:19):Hi, I'm Ronan Coutinho, a second year student pursuing BTech in Computer Science Engineering from BITS Pilani, India. I came across your GSOC 2024 Project Idea based on implementing bindings for the BRL-CAD functionality to Python language. I have a strong foundation of Python language as I have used it in previous projects. I am new to open source contributions but am eager to learn. Please guide me as to how I should get started and be able to contribute to this project.
Daniel Rossberg (Feb 22 2024 at 08:38):An important point of the Python binding topic is the design of the API. You should learn about the currently available APIs (basic C API, TCL script, object oriented MOOSE), how they give the user access to BRL-CAD's features, and develop a concept for a Python interface.
Sean (Feb 22 2024 at 17:52):@Ronan Coutinho welcome! There is a lot to learn on the python bindings topic, but you're welcome to propose whatever you think sounds like a great project idea, tailored to your knowledge. Do know that there has been some work in the past on python bindings for BRL-CAD that might be worth looking into. You don't have to use them, or you can build off what they did and take things further -- you propose what you want to do. Here's some links to related efforts:
https://medium.com/@Mr_Jaypee/brl-cads-python-procedural-geometry-990e3c286a63
https://brlcad.org/wiki/User:Schindler97/GSoC18/Project
https://brlcad.org/wiki/User:Schindler97/GSoC18/Log
https://brlcad.org/wiki/User:Krajkreddy/GSOC14/proposal
https://brlcad.org/wiki/User:Krajkreddy/GSOC14/summary
https://github.com/kanzure/python-brlcad
Ronan Coutinho (Feb 22 2024 at 19:25):Thank you @Sean @Daniel Rossberg for giving me a direction to start my work. I will look into all related efforts in this project and will discuss with y'all about the feasibility of my ideas once I get a good understanding.
Ronan Coutinho (Feb 24 2024 at 09:49):I'm following the setup instructions mentioned in https://github.com/kanzure/python-brlcad/blob/master/README_WIN.md for windows. I have python 2.7, pip, setuptools and mingw installed. When I run C:\Python27\Scripts\pip.exe install --upgrade brlcad I face this error. Could you'll please help me out.
image.png
Ronan Coutinho (Feb 25 2024 at 16:54):@Sean @Daniel Rossberg I now tried using these commands git clone git@github.com:kanzure/python-brlcad.git
cd python-brlcad/
export BRLCAD_PATH=/usr/brlcad
python setup.py install and am getting the following error. What should the path be here? I tried putting the path of the folder where BRLCAD is installed but it gives me the below error. Please help me out.
image.png
Himanshu (Feb 25 2024 at 17:07):Ronan Coutinho said:
Sean Daniel Rossberg I now tried using these commands git clone git@github.com:kanzure/python-brlcad.git
cd python-brlcad/
export BRLCAD_PATH=/usr/brlcad
python setup.py install and am getting the following error. What should the path be here? I tried putting the path of the folder where BRLCAD is installed but it gives me the below error. Please help me out.
image.png
It should be brlcad\Debug\ if you are in windows.
Daniel Rossberg (Feb 26 2024 at 10:50):Hmm, you are on Windows, therefore the path should probably start with C:\. Where is your BRL-CAD installation? In addition, I'm in doubt that the python-brlcad will work with a current BRL-CAD version.
Sean (Feb 27 2024 at 18:57):Glad to hear it @Ronan Coutinho feel free to ask follow-up questions as you learn. I certainly have my biases of what I'd like to see and am happy to share those thoughts with you sometime, but any proposal should be meaningful to you first.
It will help to compile BRL-CAD from source, and do one of the simple tutorials just so you get some familiarity.
Sean (Feb 27 2024 at 18:59):As for the errors, I'm guessing the setup.py is out-of-date referencing ctypesgen-dev ... is that even still a thing?
Sean (Feb 27 2024 at 19:01):That said, what daniel and himanshu said seem to be that last error -- you haven't specified where it can find BRL-CAD.
Ronan Coutinho (Mar 02 2024 at 17:29):@Sean @Daniel Rossberg I tried to do the setup multiple times on windows trying all possibilities. I now dual booted my laptop assuming that setting up the development environment would be easier on linux. On linux terminal i created a python environment and then ran pip install -U brlcad. Please help me fix errors shown in the screenshot.
Screenshot-from-2024-03-03-04-28-07.png
Sean (Mar 02 2024 at 18:23):@Ronan Coutinho as I mentioned, that previous work was developed several years ago now so the scripts are going to be out of date. Per the error message, it's saying "ctypesgen-dev" doesn't exist, which is not hard to imagine given how much time has passed. It's possible it's just renamed, maybe "ctypesgen" or something similar, or it's possible that entire code path was replaced with a different mechanism. A quick search indicates ctypesgen is still around, so probably just a matter of finding the right name. That said, there are going to be changes needed to get the previous walkthrough working. That's part of the effort for that project -- to figure that all out.. ;)
Sean (Mar 02 2024 at 18:23):Do you have BRL-CAD installed from source and running?
Ronan Coutinho (Mar 02 2024 at 18:31):@Sean Yes I have installed BRLCAD v 7.38.0 from https://github.com/BRL-CAD/brlcad/releases for windows
Ronan Coutinho (Mar 16 2024 at 05:54):Hi @Sean @Daniel Rossberg @Himanshu Sekhar Nayak Firstly I apologize for being inactive as I had my semester exams going on.
I had a few suggestions for my project proposal.
1.Looking at the previous work done in this project most of the primitives have been wrapped in python-brlcad. I will complete the remaining, which are rcc, tec, trc, ellg 1, part, ars, spline , binunif. With tests and examples.
2.Apart from this I also want to update the install scripts for python brlcad and bring it upto date. A problem which I'm facing myself :)
3.Current version depends on Python 2.7x. I could extend support to python 3
Himanshu (Mar 17 2024 at 09:04):Ronan Coutinho said:
Hi Sean Daniel Rossberg Himanshu Sekhar Nayak Firstly I apologize for being inactive as I had my semester exams going on.
I had a few suggestions for my project proposal.
1.Looking at the previous work done in this project most of the primitives have been wrapped in python-brlcad. I will complete the remaining, which are rcc, tec, trc, ellg 1, part, ars, spline , binunif. With tests and examples.
2.Apart from this I also want to update the install scripts for python brlcad and bring it upto date. A problem which I'm facing myself :smile:
3.Current version depends on Python 2.7x. I could extend support to python 3
- Creation of primitives based on feedback from community.
These are the deliverables in my mind as of now. Please share your feedback and anything else you'd like to see in this project.
Sounds good to me. What do you mean in your 4th point? I didn't understand.
Ronan Coutinho (Mar 17 2024 at 20:15):Himanshu Sekhar Nayak said:
Ronan Coutinho said:
Hi Sean Daniel Rossberg Himanshu Sekhar Nayak Firstly I apologize for being inactive as I had my semester exams going on.
I had a few suggestions for my project proposal.
1.Looking at the previous work done in this project most of the primitives have been wrapped in python-brlcad. I will complete the remaining, which are rcc, tec, trc, ellg 1, part, ars, spline , binunif. With tests and examples.
2.Apart from this I also want to update the install scripts for python brlcad and bring it upto date. A problem which I'm facing myself :)
3.Current version depends on Python 2.7x. I could extend support to python 3
- Creation of primitives based on feedback from community.
These are the deliverables in my mind as of now. Please share your feedback and anything else you'd like to see in this project.Sounds good to me. What do you mean in your 4th point? I didn't understand.
I meant if any new primitive is being developed right now I could work on wrapping that as well. Or are the current primitives the only ones that would exist.
Sean (Mar 23 2024 at 22:18):Ronan Coutinho said:
1.Looking at the previous work done in this project most of the primitives have been wrapped in python-brlcad. I will complete the remaining, which are rcc, tec, trc, ellg 1, part, ars, spline , binunif. With tests and examples.
2.Apart from this I also want to update the install scripts for python brlcad and bring it upto date. A problem which I'm facing myself :)
3.Current version depends on Python 2.7x. I could extend support to python 3
- Creation of primitives based on feedback from community.
These are the deliverables in my mind as of now. Please share your feedback and anything else you'd like to see in this project.
Depending on how the schedule works out, I think the importance here would be making it really simple with examples, well documented, as easy as absolutely possible to use on all platforms (mac, linux, windows), and proving that it works somehow -- perhaps by way of test cases (CI/CD).
Daniel Rossberg (Apr 04 2024 at 14:25):Hi @Sakthi N, to make your proposal to be taken into consideration, you would have to be more active here, discuss your project with the potential mentors - and provide at least one patch.
Sakthi N (Apr 05 2024 at 03:45):Hi @Daniel Rossberg , I shall be active in this chat in the upcoming days. I already have Python and MinGW. I shall install BRL CAD, go through other documentation on the github page, and get started.
Daniel Rossberg (Apr 05 2024 at 11:41)::+1: I'm expecting your comments.
Waleed Ahmed (Feb 23 2026 at 16:09):Hello @Daniel Rossberg
I’m interested in contributing to the Python Bindings project for BRL-CAD in GSoC.
I have already built BRL-CAD from source on Ubuntu and submitted a small pull request (I fixed a font saving issue in .mgedrc) , so I’m becoming familiar with the codebase and workflow.
For this project, I plan to first study the existing efforts (like the one referenced in the project details), understand the current database interfaces, and then design a clean and minimal Python API for reading and modifying BRL-CAD databases.
I would appreciate any guidance on preferred architectural direction or good starting points in the codebase.
Thank you!
Sean (Feb 23 2026 at 19:08):@Waleed Ahmed glad to see you already have a PR in! I'll leave opinion on preferred architectural direction to Daniel, but just note that bindings have been worked twice previously so would be great if your proposal/plan describe active effort to either mitigate risks of being incomplete and/or has some means for tracking completeness status or very specifically defined unambiguous scope, etc.
Sean (Feb 23 2026 at 19:17):It will help for you to be at least minimally familiar with the existing libraries involved, which will likely be LIBRT (main geometry library, huge), LIBWDB (library for writing/creating geometry, small), and the underlying helper libraries it exposes (LIBBU for basic utilities, LIBBN for basic numerics, LIBBG for some basic geometry helper routines). Be sure to look at the prior efforts by kanzure and nmz787 to see how they approached it!
At a much higher level just for awareness is LIBGED which is a command library that has all 350 or so commands exposed to users (it's a scripting argc/argv-style string API). There's also a prior effort to expose Python as a 1st-class procedural primitive, so you could create and raytrace geometry dynamically, on the fly, by creating a new entity type that runs code that generates and evaluates geometry on the fly. Involving either would be a project in themselves, but helps to understand the contexts and prior work.
Waleed Ahmed (Feb 23 2026 at 19:18):Thank you for the clarification, @Sean .
Given that previous binding efforts struggled with completion, I plan to begin by studying those implementations to understand where they stalled (scope expansion, build integration complexity).
For my proposal, I would define a strictly bounded Phase 1 scope. For example:
Select a small, high-value subset of functionality (10–15 clearly defined functions from a specific library component).
Explicitly document the target function list before implementation.
Track completeness via:
A checklist of wrapped functions
Unit tests for each exposed binding
Example usage scripts
Ensure Phase 1 produces a stable, independently usable Python module.
Subsequent phases would expand the API surface incrementally, using the same measurable structure. This way, even if development stops at any point, the completed phases remain stable, documented, and extendable.
Waleed Ahmed (Feb 23 2026 at 19:21):Sean said:
It will help for you to be at least minimally familiar with the existing libraries involved, which will likely be LIBRT (main geometry library, huge), LIBWDB (library for writing/creating geometry, small), and the underlying helper libraries it exposes (LIBBU for basic utilities, LIBBN for basic numerics, LIBBG for some basic geometry helper routines). Be sure to look at the prior efforts by kanzure and nmz787 to see how they approached it!
At a much higher level just for awareness is LIBGED which is a command library that has all 350 or so commands exposed to users (it's a scripting argc/argv-style string API). There's also a prior effort to expose Python as a 1st-class procedural primitive, so you could create and raytrace geometry dynamically, on the fly, by creating a new entity type that runs code that generates and evaluates geometry on the fly. Involving either would be a project in themselves, but helps to understand the contexts and prior work.
Thank you I would start doing that as soon as possible and will be getting guidance if I find myself stuck somewhere
Sean (Feb 23 2026 at 19:25):Kanzure's original effort was outstanding and showed much promise but the initial implementation was centered around ctypes which went through waves of being difficult to maintain/compile/keep working. The examples showed pretty good mirroring of our C/C++ code examples, for example: https://github.com/kanzure/python-brlcad/blob/master/examples/ctypes/wdb_example.py
and then a python-module improved version later: https://github.com/kanzure/python-brlcad/blob/master/examples/wdb_example.py
Waleed Ahmed (Feb 23 2026 at 19:29):Sean said:
Kanzure's original effort was outstanding and showed much promise but the initial implementation was centered around ctypes which went through waves of being difficult to maintain/compile/keep working. The examples showed pretty good mirroring of our C/C++ code examples, for example: https://github.com/kanzure/python-brlcad/blob/master/examples/ctypes/wdb_example.py
and then a python-module improved version later: https://github.com/kanzure/python-brlcad/blob/master/examples/wdb_example.py
Thank you for the additional context.
For the bindings approach, I’m currently considering avoiding a ctypes-based implementation due to long-term maintainability concerns, and instead exploring a C-extension strategy.
Before going further, I wanted to ask whether introducing a small C++ bridge layer would be acceptable for this effort. If so, a pybind11-based approach could potentially provide stronger type safety and easier long-term maintenance. If a pure C interface is preferred, I would instead plan around the CPython C API directly.
I will also review kanzure’s and nmz787’s prior efforts carefully to better understand their architectural decisions and where complexity arose, so I can factor that into a more concrete proposal.
I’d like to make sure whatever approach I take is sustainable and aligned with the project’s long-term direction.
Sean (Feb 23 2026 at 19:29):nmz787 on the other hand took quite a different approach, which you can see in these couple examples:
https://github.com/nmz787/python-brlcad-tcl/blob/master/examples/multi_part_example.py
https://github.com/nmz787/python-brlcad-tcl/blob/master/examples/mems_hello_world.py
and this approach basically was python that output tcl/mged/libged scripts that would be then consumed by existing tools to actually make geometry.
Waleed Ahmed (Feb 23 2026 at 19:32):Sean said:
nmz787 on the other hand took quite a different approach, which you can see in these couple examples:
https://github.com/nmz787/python-brlcad-tcl/blob/master/examples/multi_part_example.py
https://github.com/nmz787/python-brlcad-tcl/blob/master/examples/mems_hello_world.pyand this approach basically was python that output tcl/mged/libged scripts that would be then consumed by existing tools to actually make geometry.
From what I understand, kanzure’s approach went deeper into actual library bindings, while nmz787’s approach used Python to generate TCL/MGED/LIBGED scripts that existing tools would execute.
The second approach seems simpler and more stable long-term, but also more indirect since it works at the command-string level instead of exposing structured APIs.
I’ll take some time to properly review both implementations so I can better understand the tradeoffs before deciding on a directio
Sean (Feb 23 2026 at 19:33):Both of them are primarily documented by way of examples so it's hard to tell how complete/incomplete they are, but kanzure's does have a nice article writeup that someone else did afterwards: https://medium.com/@Mr_Jaypee/brl-cads-python-procedural-geometry-990e3c286a63
Sean (Feb 23 2026 at 19:35):Second approach is definitely simpler, but arguably NOT stable long-term as the CLI is constantly undergoing change and it's architecturally not python bindings, but just python code writing out scripts.
Waleed Ahmed (Feb 23 2026 at 19:37):Sean said:
Second approach is definitely simpler, but arguably NOT stable long-term as the CLI is constantly undergoing change and it's architecturally not python bindings, but just python code writing out scripts.
Thank you for correcting me there.
I apologize for not diving deep enough yet to understand how actively the CLI evolves and how that affects long-term stability. I’ll take more time to study the architecture and prior efforts more carefully so I can better evaluate the tradeoffs before proposing a direction.
Sean (Feb 23 2026 at 19:40):Ah, the article is refreshing my memory -- the version of ctypesgen that kanzure used (back circa 2013) had some issues which caused headaches, which Jaipal worked on in https://github.com/Killthebug/python-brlcad
Sean (Feb 23 2026 at 19:40):that's still ctypes-based
Sean (Feb 23 2026 at 19:40):(which is fine, just noting the method)
Waleed Ahmed (Feb 23 2026 at 19:45):Really thankful for all the feedback you gave.
I'll certainly reach you back on this matter soon when I'm stuck at some place.
Waleed Ahmed (Feb 24 2026 at 09:09):Hi @Sean
I’ve been going through kanzure’s ctypes-based approach and nmz787’s script-generation approach, and it’s been useful to see how they handled things differently and where the challenges came from. It made me think more carefully about scope and long-term maintainability.
Right now, I’m leaning toward a more direct library-based approach rather than relying on CLI/script generation, with a tightly defined and incremental scope so the project stays measurable and complete at each stage.
Before I go further with the proposal draft, I just wanted to make sure this general direction feels aligned with what BRL-CAD would prefer.
Last updated: Feb 26 2026 at 01:10 UTC