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.
Sean (Feb 28 2026 at 04:23):@Waleed Ahmed I don't have a strong preference, but if I had to choose myself, I would choose the direction you're suggesting. Direct library bindings are the way to go. The only question I'd have is whether to try and take advantage of something like ctypesgen to ease the burden or simply define an interface as needed and accepting the (likely) greater maintenance cost.
Waleed Ahmed (Feb 28 2026 at 04:50):@Sean I’m a bit hesitant to rely heavily on something like ctypesgen given the maintenance issues earlier efforts ran into.
Right now I’m leaning more toward defining a curated interface and keeping the exposed surface intentionally small, possibly with a thin adapter layer to reduce tight coupling to internal changes. That way we get stronger compile-time guarantees and a more stable API, even if it means a bit more upfront work.
I think that gives a better long-term balance between maintainability and stability, but I’ll experiment a bit more before finalizing the approach.
Daniel Rossberg (Mar 06 2026 at 21:57):@Waleed Ahmed, I have a bit different view on this topic than Sean. The previous attempts to create a Python binding failed. You should rather learn from than imitate them.
To convince me, you should design the Python API a way that attracts Python programmers. How would a Python programmer find it easy to write software for a CAD kernel? If the API is awesome, there will be a way to implement it.
In addition, I'm not a fan of an additional adapter for BRL-CAD's core, which has to be maintained. Maybe, it's necessary, but I wouldn't welcome it. At least, if necessary, it shouldn't need much maintenance.
However, this are only my opinions.
Waleed Ahmed (Mar 06 2026 at 22:10):@Daniel Rossberg My intention is to keep the adapter layer extremely small and stable, mainly acting as a thin bridge between the Python C extension and the existing BRL-CAD functions. Ideally it should require minimal maintenance and only wrap a small subset of the core APIs.
I’ve started thinking more about how the interface would feel for Python users rather than simply mirroring the existing C APIs. My goal is to design something that feels natural for Python scripting, especially for tasks like procedural geometry generation.
Based on your suggestion, do you think it would be better to first design a more Pythonic high-level API (for example object-oriented geometry creation or scripting workflows) and then implement the bindings underneath it? Or would you recommend starting from a minimal low-level binding and evolving the Python API from there?
Daniel Rossberg (Mar 07 2026 at 15:28):Definitely!
My goal is to design something that feels natural for Python scripting, especially for tasks like procedural geometry generation.
That's it. Of course, it must reflect BRL-CAD's methodology of geometry handling, but in a way, which attracts Python programmers.
For the back-end, you could consider MOOSE. It has an object-oriented design already.
Waleed Ahmed (Mar 07 2026 at 15:39):Daniel Rossberg said:
Definitely!
My goal is to design something that feels natural for Python scripting, especially for tasks like procedural geometry generation.
That's it. Of course, it must reflect BRL-CAD's methodology of geometry handling, but in a way, which attracts Python programmers.
For the back-end, you could consider MOOSE. It has an object-oriented design already.
Thanks, that’s very helpful.
Using MOOSE as the backend sounds interesting since it already provides a more object-oriented design. Do you think it would be a good foundation for Python bindings, or is it still evolving?
I’m trying to understand whether building on top of MOOSE would help reduce the need for an additional adapter layer.
Daniel Rossberg (Mar 07 2026 at 16:11):The design of MOOSE is based on the C++ core interface in rt^3, which goes back to 2008. It is well tested and very stable. It may still get new features, but it is designed as a stable foundation for programs using it. And, I'm thinking about adding a build option for dynamical linking with the core libraries. This would solve an issue with CommandString.
The drawback is something else: It has a C++ API and the C++ byte code is compiler specific. I.e., binding MOOSE to Python would require a layer which translates C++ to plain C.
Waleed Ahmed (Mar 07 2026 at 18:05):Daniel Rossberg said:
The design of MOOSE is based on the C++ core interface in rt^3, which goes back to 2008. It is well tested and very stable. It may still get new features, but it is designed as a stable foundation for programs using it. And, I'm thinking about adding a build option for dynamical linking with the core libraries. This would solve an issue with CommandString.
The drawback is something else: It has a C++ API and the C++ byte code is compiler specific. I.e., binding MOOSE to Python would require a layer which translates C++ to plain C.
I’ve been thinking more about the Python integration design and would like your opinion on a possible architecture.
The idea is to focus on a Pythonic high-level API (a small modeling DSL / scene-graph style interface) where users build geometry using objects and boolean operations in Python. Internally, this would translate to a minimal, stable bridge layer that communicates with MOOSE/BRL-CAD. The goal would be to keep the low-level binding surface small and maintainable, while making the Python API feel natural for procedural CAD workflows.
From a maintenance perspective, the intention is to avoid exposing large portions of the internal API directly and instead map only core concepts (primitives, combinations, transforms). This should allow the project to expand gradually without requiring extensive per-function bindings.
Do you think this direction aligns better with BRL-CAD’s methodology and long-term maintainability goals? I would really appreciate your feedback on whether this structure makes sense for the proposal.
Daniel Rossberg (Mar 07 2026 at 19:58):I thought that I wrote that I'm in favour of starting with the Python API design. Therefore yes, this looks good.
You should include the following features of BRL-CAD databases in your design considerations:
For the primitives' design, start with the simple ones (e.g. sphere), then do the more complex ones (e.g. arb8), and at last do the ones with complex substructure (e.g. bag of triangles). You don't need to come with a complete design for all primitives. Sketching the designs for 3 representatives is enough.
Waleed Ahmed (Mar 07 2026 at 20:05):Thanks, Daniel! I’ll begin drafting the proposal.
Sean (Mar 09 2026 at 04:10):@Waleed Ahmed can you elaborate on what exactly you mean by the capsule approach you mentioned in the other thread?
Sean (Mar 09 2026 at 04:17):MOOSE is definitely an excellent approach if you're going to go the OO-route since it's already had a lot of thought on clean design and mapping to the underlying geometry concepts.
Your hesitation to rely on something like ctypesgen given the earlier efforts is reasonable as they obviously did not grab attention. Now that could have been due to a lack of promotion/docs/advocacy or unappealing design concerns or simply lack of relatable / documented use cases. Also relevant to keep in mind the maintainability aspects were over 10 years ago, so they may or may not be relevant today. That's enough time that unless something has stagnated the entire time, it could warrant reconsideration.
Waleed Ahmed (Mar 09 2026 at 13:52):@Sean by capsule-based design i meant that i used PyCapsule to wrap native BRL-CAD handles returned by the C extension so python objects could store it safely.
Like when the database was opened, the C layer returns a handle that PyCapsule safely stores inside a python database object. Then functions like create_sphere would extract the pointer with get_pointer functions.
Waleed Ahmed (Mar 09 2026 at 13:54):Sean said:
MOOSE is definitely an excellent approach if you're going to go the OO-route since it's already had a lot of thought on clean design and mapping to the underlying geometry concepts.
Your hesitation to rely on something like ctypesgen given the earlier efforts is reasonable as they obviously did not grab attention. Now that could have been due to a lack of promotion/docs/advocacy or unappealing design concerns or simply lack of relatable / documented use cases. Also relevant to keep in mind the maintainability aspects were over 10 years ago, so they may or may not be relevant today. That's enough time that unless something has stagnated the entire time, it could warrant reconsideration.
I'll revisit the ctypesgen approach and see if it could help generate lower-level bindings or prototypes.
Daniel Rossberg (Mar 14 2026 at 20:14):Hi @Rohit S, lets move to the stream/topic, where we discuss the Python bindings for GSoC.
To answer your questions:
Rohit S (Mar 15 2026 at 09:34):Hi @Daniel Rossberg , thanks for the detailed reply and for pointing me to this topic.
Based on your suggestion, I'll focus on designing a C-level binding first and then exposing that to Python, rather than wrapping the C++ side directly. I agree that a thin exposure of the core functions wouldn't make for a good Python API, so in my proposal, I'll aim for a higher-level, Pythonic interface, for example, abstractions like Database, Shape, and Region objects with clean methods rather than raw function calls.
I'm currently working on compiling BRL-CAD from source on my machine. Once that's done, I'll put together a minimal prototype, a small C wrapper + Python call to open a .g file and list its contents, and build my milestone plan around that approach in the draft proposal.
Rohit S (Mar 17 2026 at 15:32):Hi @Daniel Rossberg @Sean ,
Following your feedback, I've been working on the pre-proposal groundwork. Here's a summary of what I've done so far:
Submitted a procedural geometry generator (random_csg.c) to src/proc-db which generates random BRL-CAD primitives combined with boolean operations and writes them to a .g database via libwdb.
PR: https://github.com/BRL-CAD/brlcad/pull/224
Python Bindings Prototype
Repo: https://github.com/rohits1450/python-brlcad, explained clearly in its README
Built a two-layer architecture:
Binding approach decision:
I'm planning to go with a C binding via CFFI rather than MOOSE, for ABI stability across MSVC/GCC/Clang. The public API will be Pythonic, users interact with Python classes, never raw C functions.
Before I draft the formal proposal, I'd love your feedback on this work.
Any specific functionality you'd like to see covered in the proposal scope?
Thank you for your time and guidance!
— Rohit S
Sean (Mar 18 2026 at 05:42):@Rohit S very impressive breadth of efforts, but that's also a relatively big dump of works all at once that becomes tedious to review and discuss when there are issues or questions.
For #1, I reviewed and responded to PR224 with several points of feedback/changes requested.
For #2, I would like to see more of your discussion on the architecture and design, not swaths of generated code already running in a particular direction. If anything, maybe show examples of the final end-goal, which you kind of show with the readme, test_open, and rhombicuboctahedron examples, all of which look to be in a good direction but with glaring issues (imho) and suboptimal design. Moreover, I'm guessing you used a coding agent to get you this far which is fine, but should be disclosed, and all the more reason to indicate just what direction and end state would be the goal if this is your coding pace for .. months.
I'd like to see what wdb_example looks like in your final python end-state. Not functional, but how it "should" look like if it were a TDD test prior to implementation.
For #3, it's the most unappealing of the lot to me. The end result gets there, but that code looks horrible. It unnecessarily tries a generic convex hull wrap on the points first and if that fails it resorts to manual... ??? Also, deduplicating points that it just created seems nuts. I would characterize that as AI garbage. A better approach from a procedural standpoint would have been to demonstrate how the python might look to create the R24 using plates (arb8's and arb6's). That demo really only showcases one useful thing from a design perspective (i.e., brlcad_create_bot()).
Sean (Mar 18 2026 at 05:48):back to discussing design, I think it is reasonable (and now quite well demonstrated) the efficacy of going to CFFI. It'll be interesting to see how well that extends to all entity types, though you did already show a couple simple types and one advanced (bot). In your design consideration, did you look at all at pybind11? Curious how that option path would measure up in comparison with CFFI seeing how it's a simple header-only binding layer (that could work with the C libs or MOOSE).
Again, would also like to see a more developed concrete example of what the design will look like (architecturally and code example non-functionally) at the end of GSoC. How easy/easier is might be to do something like your random_csg.c proc-db in python instead of C as creating the prims, adding wmembers, and writing out combs is definitely error-prone and a somewhat complicated design in C. I'd like to see how you'd support composability, transformations, set attributes, rename things, handle errors, etc.
Waleed Ahmed (Mar 18 2026 at 20:40):@Sean @Daniel Rossberg Hey there guys
so i was experimenting with the python bindings and was making a prototype past few days. I have designed a layered python API for BRL-CAD that separates high level scene construction from the backend C interface. At the top, users interact with chainable, composable Shape objects and CSG operations entirely in Python, allowing in-memory manipulation of attributes like color and shader. This is then exported through a controlled CFFI wrapper that communicates with a small C adapter, which handles creation, selection, and updates of BRL-CAD primitives and combinations in the .g database.
I made this whole project in multiple stages so i tested all stages in detail with python codes for each stage and also attached the test codes in my github repo https://github.com/AWaleed-Ahmed/python-bindings-prototype
heres how my api usage is
and also here is the pipeline of this prototype
Can you tell me if this seems like a good approach for the proposal, Ofcourse i do intend to add further functionality in the proposal and in the actual project
Waleed Ahmed (Mar 18 2026 at 20:47):This prototype supports dynamic in-memory updates of object attributes, allowing changes to colors, shaders, and transformations without recreating the scene, and is designed with maintainability and composability in mind for long-term extensibility.
Daniel Rossberg (Mar 19 2026 at 20:57):Hi @Waleed Ahmed, this is a really nice prototype, suitable for discussing the design. At many places, it's a bit wired, but I suppose that you used AI writing it? That's totally okay, but be aware, that we may question every line of your final code: "Why did you it that way?" :wink:
Some thoughts which came into my mind after a first look:
s1.create(db), but this is in fact db.add(s1). Waleed Ahmed (Mar 19 2026 at 22:13):Daniel Rossberg said:
Hi Waleed Ahmed, this is a really nice prototype, suitable for discussing the design. At many places, it's a bit wired, but I suppose that you used AI writing it? That's totally okay, but be aware, that we may question every line of your final code: "Why did you it that way?" :wink:
Some thoughts which came into my mind after a first look:
- The primitives are not transformable per se. Rather, transformations can be added to the combinations.
- In create_sphere.py you write
s1.create(db), but this is in factdb.add(s1).
Yes I did use AI for a few code snippets and also to generate a few tests but i personally spent time on the whole implementation logic and design.
In transformations, I forgot to fully implement that section. I didn't finish the exporter logic to apply transformations at the combination level, even though I designed the API to save them.
I also realized that transformations should be applied to the combination links while primitives should stay at the origin. I'll clean up the low-level API appropriately and rewrite the exporter to create the matrices from the stored transforms and pass them when adding members to combinations.
I'm sorry about the s1.create(db) it was a slight naming issue I can change it in the project and also write detailed documentation about the naming i use in the future.
Last updated: Mar 20 2026 at 01:12 UTC