Daniel Rossberg (Mar 08 2023 at 17:23): Daniel Rossberg (Mar 08 2023 at 17:23):Hi @Anirban Sikdar
Anirban Sikdar said:
- What are the basic functionalities this package is going to build in detail?
What do you propose?
It should be possible to load and save BRL-CAD databases (.g files), to explore and change them. There are at least two approaches to get this:
Personally, I would like to see an API, which is easy to use for people familiar with Python. I.e., it should not look exotic. However, at the end, it would be on you to write the proposal.
Anirban Sikdar (Mar 13 2023 at 17:25):Sorry for a late reply and I'm thankful for your response...but can you help me with getting started?
Daniel Rossberg (Mar 13 2023 at 18:05):https://brlcad.zulipchat.com/#narrow/stream/111975-Google-Summer-of-Code/topic/general/near/339394535 is for starting.
Anirban Sikdar (Mar 14 2023 at 16:49):Daniel Rossberg said:
https://brlcad.zulipchat.com/#narrow/stream/111975-Google-Summer-of-Code/topic/general/near/339394535 is for starting.
I meant for the python binding project in specific if you can
Daniel Rossberg (Mar 15 2023 at 16:36):For a general statement, see my first message here in this topic.
To be more specific, you should explore the different methods to work with BRL-CAD databases. E.g., do the mged tutorial. This teaches you the TCL shell way of working with geometries.
Then, you should compile and install MOOSE. Use the example provided there as starting point for a C++ way of working with geometries.
Then maybe, you can provide us with an idea about a Python way. How do you think a Python API should look like?
Sean (Mar 16 2023 at 04:27):I'd love to resurrect the idea of having procedural geometry objects that have code, and that code would be run through a specified interpreter (e.g., tcl or python or lua or whatever binds easily to libged). with that the object would provide code for each of the primary callbacks like prep and shot and describe and so on that would be called during ft_prep, ft_shot, etc via the interpreter. that'd give the ability to describe and change essentially any parametric definition on the fly, fully procedurally.
Sean (Mar 16 2023 at 04:28):now that ged_exec() works fully dynamically, I think it's doable. the issue before was that it was going to create a hard cyclic compile-time dependency with librt -> libged -> librt. dynamically loaded, though, that's not as much of an issue and opens up a lot of possibilities..
Rohit S (Mar 15 2026 at 07:16):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.
Last updated: Mar 20 2026 at 01:12 UTC