Python bindings · Google Summer of Code

Stream: Google Summer of Code

Topic: Python bindings

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:

Interfacing the command line interpreter of the mged shell (libged)
An object oriented, functional approach, maybe MOOSE based

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?

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..

Last updated: Oct 09 2024 at 00:44 UTC