Daniel Rossberg (Nov 16 2024 at 15:15): Daniel Rossberg (Nov 16 2024 at 15:15):Hello @Hector Serrano, @Shreya Baid, @Indranil Saha, @Gufran Khan, and everybody else interested in contributing to BRL-CAD, whether GSoC related or not.
The first thing you should do is learning about BRL-CAD, what it is and how it works. I.e.
Install the main programs. You can find installation binaries for Windows among the releases https://github.com/BRL-CAD/brlcad/releases. If you don't want to start with Windows, you have to compile the programs by yourself first. For doing this, see next section.
The installation contains a huge amount of programs. Most of them are small command line tools. You should look at our old but still heavily used GUI mged and the more modern GUI archer.
With both, you can go through the tutorial https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf.
The next step would be compiling the programs from sources. This is, of course, necessary for contributing to the programs in our main repository. But, even if you are interested in web-programming, like our Online Geometry Viewer or writing a Python API (where you need an installed BRL-CAD only), without being able to compile it by yourself, you cannot benefit from latest improvements. Therefore
Links with ideas for small contributions:
Last, some remarks regarding GSoC:
Daniel Rossberg (Feb 22 2025 at 15:45):@siddharth said:
how to contribute
The first thing you should do is learning about BRL-CAD, what it is and how it works. I.e.
The next step is compiling the programs from sources. Therefore
At last, some links with ideas for small contributions:
Daniel Rossberg (Nov 30 2025 at 18:32):Hello @Pratyush Gaur , the first thing you should do is learning about BRL-CAD, what it is and how it works. I.e.
The installation contains a huge amount of programs. Most of them are small command line tools. You should look at our old but still heavily used GUI mged and the more modern GUI archer. With both, you can go through the tutorial https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf.
The next step would be compiling the programs from sources. This is, of course, necessary for contributing to the programs in our main repository. But, even if you are interested in web-programming, like our Online Geometry Viewer or writing a Python API (where you need an installed BRL-CAD only), without being able to compile it by yourself, you cannot benefit from latest improvements. Therefore, download the source code from https://github.com/BRL-CAD/brlcad and follow the instructions for building the executables on your platform.
Links with ideas for small contributions:
Daniel Rossberg (Dec 08 2025 at 15:14):Hi @Bhuwan Sharma, you may want to follow this topic.
Shoaib (Dec 13 2025 at 08:51):"Hi! I'm Shoaib, interested in contributing to BRL-CAD
for GSoC 2026. I'm proficient in C++. Where should I start
as a first-time contributor?"
"Are there any tasks or bugs I can work on?
The GitHub issues seem outdated."
Daniel Rossberg (Dec 13 2025 at 16:11):Hi @Shoaib, could you successfully compile everything, including MOOSE and arbalest?
Rishith Kumar Guntuka (Dec 14 2025 at 19:33):Hello everyone,
I’m Rishith, a B.Tech CSE student from India. I recently built brl cad 7.42.0 from source on Ubuntu (WSL2). I’m currently running mged directly from the build tree without doing a "make install", since I understand installation is not required for development. So far, it is compiling and running without any errors, and I’ve been using mged to create some basic geometry. I also have strong foundations in C and I’m interested in contributing.
I wanted to ask if brl cad is likely to participate in GSoC 2026. I know this may not be confirmed yet, but I wanted to check early so I can plan my learning and contributions properly. I also noticed that some docs pages on the website seem to be down, so I’m bit confused.
Could someone please guide me on what the next step should be for a new contributor? Should I focus more on learning mged, or start exploring specific parts of the codebase? Also, is a gui setup required at any point for development? Any guidance would be really helpful.
Thank you.
Screenshot 2025-12-15 005950.png
Rishith Kumar Guntuka (Dec 15 2025 at 16:18):@Daniel Rossberg Can I get an update on my previous message?
Daniel Rossberg (Dec 15 2025 at 17:53):Hi @Rishith Kumar Guntuka, no rush, some people here have a day job, family, etc. :wink:
Regarding make install: Installation is not required for many development tasks, but for some software build on top of it, because of the expected directory structure. You should not be afraid of installing brlcad, but set the CMAKE_INSTALL_PREFIX to a directory where you can write in, for example in your home directory.
GSoC 2026: I would say, that the current mood is to participate...
brlcad.org: The wiki is still down because of hardware issues, unfortunately.
Next steps: Learning mged is never wrong. You probably know our GSoC ideas list? It may be a bit outdated, but still shows the main development directions. What are you interested in? Working on the core? Qt GUI? Python? Java Script?
Rishith Kumar Guntuka (Dec 15 2025 at 18:23):@Daniel Rossberg Thank you for the clarification. Helps a lot.
Understood about the cmake install, will do a local install in my home directory.
Regarding direction, I'm most interested in working in the core. As I have good foundations in C. I'm open to work with python later. For now, I think core development is my main interest.
I'll go through the previous year GSOC ideas list. If you have any suggestions for a good starting area or small task to get familiar with the codebases, I'd really appreciate it.
While browsing the codebase, I noticed a couple of small FIXME comments in librt (for example a redundant cache permission check and a variable shadowing case). I was thinking of starting with one of these cleanup tasks if that sounds reasonable.
Daniel Rossberg (Dec 15 2025 at 18:47):Rishith Kumar Guntuka said:
Daniel Rossberg Thank you for the clarification. Helps a lot.
While browsing the codebase, I noticed a couple of small FIXME comments in librt (for example a redundant cache permission check and a variable shadowing case). I was thinking of starting with one of these cleanup tasks if that sounds reasonable.
:+1: Sounds good.
Shoaib (Dec 18 2025 at 08:03):Daniel Rossberg
yes i did it.
Daniel Rossberg (Dec 18 2025 at 14:04):Does the "select object" feature (button) work?
Aayush Sharma (Dec 22 2025 at 23:18):Hello
My name is Aayush, and I’m a first-year M.Sc. AI & ML student from India. I’m currently exploring BRL-CAD as a potential organization for Google Summer of Code 2026.
So far I have:
1.Installed BRL-CAD on Windows and worked through the MGED introduction (creating primitives, CSG operations, and raytracing)
2.Explored Archer and compared its workflow with MGED
3.Forked the BRL-CAD repository and successfully configured and built it from source on Windows using CMake + Visual Studio (ALL_BUILD completed successfully)
At the moment I’m using the system-installed BRL-CAD binaries for runtime while working from the source tree for development, since the INSTALL target is failing on Windows due to permission/toolchain issues.
I’d like to start with a small, useful contribution (documentation, cleanup, or a beginner-friendly bug) to get familiar with the codebase and contribution workflow.
Could you please suggest good starter areas or tasks to begin with?
Thanks!
Daniel Rossberg (Dec 25 2025 at 17:45):Hi @Aayush Sharma, welcome!
If you want to stay with core BRL-CAD, the NMG stuff (non-manifold geometry, src/libnmg, src/librt/primitives/nmg) hast still some annoying ... features. E.g. pl_ray() in src/librt/primitives/nmg/nmg.c. What's the point of that?
Aayush Sharma (Dec 25 2025 at 18:58):@Daniel Rossberg Thanks for pointing me to it , I took a closer look at pl_ray().
From reading the code in src/librt/primitives/nmg/nmg.c, pl_ray() appears to be a diagnostic plotting helper rather than part of the normal raytrace output path. It walks the rd_hit hitmiss list and writes a .plot3 file that visualizes the ray segments, color-coded by NMG ray state (INSIDE / ON / OUTSIDE), including state transitions and the ray continuation past the last hit.
So it looks mainly intended for debugging or visually inspecting NMG ray classification behavior, not for production raytracing. That would also explain the direct file output, hardcoded naming, and lack of documentation or runtime control, which makes it feel like legacy/debug cruft today.
A reasonable next step on my side would be to trace where pl_ray() is actually invoked (and under what conditions), and see whether it’s still exercised by any current debug paths, or whether it should be better documented, guarded, or potentially deprecated. Let me know if that aligns with what you had in mind, or if there’s historical context I should be aware of first.
Daniel Rossberg (Dec 26 2025 at 20:23):That's right, it's a debugging output. In my experience, it will be triggered whenever a NMG is ray-traced. Not for every ray, just for some. But this writes some or many files to my hard disk, I don't want to see there.
The better solution would be to eliminated the cause of the debug output, which is probable a failed ray-trace. Another solution is to write files only if a librt debug flag is set.
Aayush Sharma (Dec 27 2025 at 17:23):@Daniel Rossberg Thanks, that makes sense.
After tracing the call sites, I see two places where pl_ray() is triggered. One is inside nmg_ray_segs() under NMG_DEBUG_RT_SEGS, but the other is in unresolved(), where pl_ray(rd) is called unconditionally when a state transition cannot be fixed.
That unconditional call in unresolved() seems to explain why plot3 files get written even without explicit debug intent, and why it can spam the working directory when NMG ray issues occur.
As a first step, I think it would make sense to guard pl_ray() behind an appropriate librt debug flag (or possibly reuse an existing one) so that plot files are only generated when explicitly requested. That would avoid unexpected disk output while preserving the debugging capability.
If that sounds reasonable, I can work on identifying the most appropriate librt debug flag and prepare a small patch to gate pl_ray() accordingly.
Daniel Rossberg (Dec 28 2025 at 19:52):It sounds reasonable for me, but others have to approve it, namely @Sean and @starseeker.
Rishith Kumar Guntuka (Dec 29 2025 at 06:28):HI @Daniel Rossberg
While working on a cache writability redundant permission cleanup PR in src/librt/cache.c, Copilot pointed out something that I missed. The removed check in cache_try_store() was verifying writable and executable permission on cache->dir, whereas cache_init() currently checks for writability.
PR Link: https://github.com/BRL-CAD/brlcad/pull/210
Since execute permission on a directory is required to traverse into it, removing the check entirely may be incorrect unless that permission is checked before.
Going forward now, I see two possible solutions for this and I want to know which aligns better with the organization's expectations.
Please let me know which approach you would prefer and I will update my PR accordingly.
Thanks.
Daniel Rossberg (Dec 29 2025 at 17:00):@Rishith Kumar Guntuka: If simply removing the lines from cache_try_store() would be the solution, it would probably be done by the original author :wink:
Personally, I'm in favour of the first solution, but the authors spend a lot of work in designing and implementing the cache mechanism. You should ask them about the rationale behind their intentional imperfect code. (I'm none of them.)
Rishith Kumar Guntuka (Dec 29 2025 at 17:50):Hi @starseeker
I'm working on a small redundancy cleanup in src/librt/cache.c, and I have noticed that executable + writable check in cache_try_store() is marked [FIXME: Redundant].
Before moving the executable permission to cache_init() and removing it from cache_try_store(), I would like to understand what was your intent on that.
I'd really appreciate any guidance on that.
Aayush Sharma (Dec 31 2025 at 20:05):Hi @Daniel Rossberg,
Just a quick follow-up on the pl_ray() debug-guard discussion. I wanted to check whether I should go ahead and prepare a small patch (e.g., guarding it behind a librt debug flag) and let @Sean @starseeker review it when they have time,seems they are too busy :sweat_smile: or wait for explicit confirmation first.
I’m happy to proceed in whichever way you prefer.
Thanks!
Sean (Dec 31 2025 at 21:31):@Aayush Sharma end of year craziness, but on the surface what you're suggesting sounds reasonable. I do believe there is already a flag for plotting but will have to look it up. Note there are multiple sets of debug flags (for librt, libbn, libbu each).
Sean (Dec 31 2025 at 21:37):@Rishith Kumar Guntuka no comment yet on the correctness or intent of the existing code as it's had multiple revisions since I last worked on it, but there is undoubtedly room for improvements, consolidation, better testing, etc. One specific issue still unimplemented is making sure the cache system only uses a specifiable amount of disk space (e.g., 1GB) and doesn't fill up the hard drive regardless of caching -- auto-expiring the oldest cached items to keep things within usage limits.
As for permissions, keep in mind permissions might change between the time we initialize and the time a write is actually occurring or the cache store is being traversed. Shouldn't be inefficient, but should be resilient to the extent possible as actual I/O or syscalls are performed to ensure things are operating within expected parameters.
Sean (Dec 31 2025 at 21:38):again, i've not reviewed that code lately, but just food for thought :)
Aayush Sharma (Dec 31 2025 at 21:38):Thanks @Sean , that helps a lot.
I’ll look for existing plotting-related debug flags across librt (and libbn/libbu if applicable) to see whether one already fits this use case before proposing anything new.
Once I’ve identified the most appropriate flag (or confirmed there isn’t a suitable one), I’ll follow up with a concrete proposal for guarding pl_ray().
Sean (Dec 31 2025 at 21:40):sounds good. the flags are defined in the top-level include/ dir for each lib (I'd expected them in a globals.h or defines.h header)
Aayush Sharma (Jan 01 2026 at 07:55):@Sean Thanks, I completed a pass over the existing debug flag definitions across librt, libbn, and NMG.
Based on the semantics and existing usage patterns in nmg.c, NMG_DEBUG_PLOTEM (“make plots in debugged routines”) looks like the best fit for guarding pl_ray(). It already exists in include/nmg/debug.h, matches the purpose of pl_ray() precisely, and aligns with the existing nmg_debug & NMG_DEBUG_* pattern used elsewhere in the file.
If that sounds good, I can prepare a small patch that guards the pl_ray() calls (notably in unresolved()) behind NMG_DEBUG_PLOTEM.
Aayush Sharma (Jan 01 2026 at 16:54):@Daniel Rossberg @Sean
Thanks for the review and guidance so far.
I’ve opened the PR for the pl_ray() debug guard as discussed. While that’s under review, I’m happy to pick up another small task or investigate another issue if there’s something useful I can help with.
Sean (Jan 04 2026 at 07:35):Thanks @Aayush Sharma, that's a nice simple start.
Something really useful you could help with is a quality knob on the 'gist' command line tool (see src/gtools/gist). Right now it is cli with options for controlling output resolution (ppi is the main one, but alternatively width and height). However when gist runs it invokes several commands that have their own quality settings (e.g., see commits f5b9e8a7e5d4e941d9561e56771f6dd28394cc2b and 98eab98f6a2f5d9d1c86cd182619a5291ffbef12 for a couple examples) which typically has huge impact on runtimes..
We need some way for a user to say they want low vs high quality (aka draft/final or other characterizations) -- some quality knob or switch that then directs the underlying utilities to spend far less/more time accordingly. Alternatively could find some way to tie quality with the ppi setting, though I suppose it's conceivable to want low-resolution with high-quality rendering and high resolution with low-quality rendering -- but more common is definitely low-res + low quality OR high-res + high quality.
When someone is just starting to use the tool, you usually want a fast preview to make sure everything looks right. Once that preview is good, the next want is to crank up the quality for whatever resolution level was requested.
Rishith Kumar Guntuka (Jan 04 2026 at 16:52):Thanks @Sean for the insights about permission changing at the time of initialization and time of use, it really helped me understand the reason behind.
Based on that, I’m considering introducing a small helper function (e.g., cache_check_dir_perms()) that takes the cache directory and required permission flags, and using it at the appropriate points in the code (during initialization and at time-of-write) instead of removing checks completely. The goal would be to centralize permission logic without breaking things if permissions change while the program is running.
Coming to this:
One specific issue still unimplemented is making sure the cache system only uses a specifiable amount of disk space (e.g., 1GB) and doesn't fill up the hard drive regardless of caching -- auto-expiring the oldest cached items to keep things within usage limits.
Regarding the cache size limit you mentioned, I explored a few possible approaches and wanted to confirm which aligns best:
Touch on access deletion - explicitly updating timestamps on successful cache reads (via syscalls) and deleting based on those timestamps which is true LRU, but adds extra I/O on reads.
Memory data structures (e.g., queues/maps)- true LRU but significantly more complex & costly for disk cache because it requires more writes and crash recovery when the brlcad closes, all RAM stored data is lost.
Filesystem metadata based deletion - by scanning cache entries, sorting by modification time, and deleting the oldest files(which were created long ago) until under the limit which is simpler and commonly used, though it approximates LRU rather than tracking read access.
I don’t have a strong preference yet and wanted to check which of these approaches you feel is most appropriate before going further.
Aayush Sharma (Jan 05 2026 at 00:02):Thanks @Sean I did a detailed analysis of the gist pipeline and the utilities it invokes.
gist currently calls rt, rtedge, rtwizard, rtarea, gqa, and mged, and several quality-affecting parameters have a significant impact on runtime. The main cost drivers are render size (-s, O(n²), currently hardcoded at 1024), ambient samples for rt (currently hardcoded at 8), and gqa grid resolution. There is also a FIXME in PerspectiveGatherer.cpp noting the need for low/high quality configurability.
Based on this, I’d suggest a small Phase 1 change: introduce a --quality low|medium|high preset that maps to reasonable defaults for these parameters while keeping the current behavior as the default. This would support fast preview workflows as well as higher-quality final renders without exposing a large number of new options initially.
If this approach sounds reasonable, I’m happy to start with a minimal, incremental implementation (touching Options, PerspectiveGatherer, and InformationGatherer).
Rishith Kumar Guntuka (Jan 10 2026 at 14:38):Hi @Daniel Rossberg ,
I wanted to follow up on the cache permission cleanup PR. It’s been about 6 days since I proposed:
I haven’t heard back yet, so I wanted to check whether this general direction looks reasonable to you, or if you’d prefer a different approach.
Any guidance would be appreciated and happy to revise based on your feedback.
Daniel Rossberg (Jan 12 2026 at 15:10):I don't consider myself as relevant here, because it's not my area, but @Sean made a relevant remark:
As for permissions, keep in mind permissions might change between the time we initialize and the time a write is actually occurring or the cache store is being traversed. Shouldn't be inefficient, but should be resilient to the extent possible as actual I/O or syscalls are performed to ensure things are operating within expected parameters.
Aayush Sharma (Jan 14 2026 at 20:35):Hi @Sean just a quick follow-up.
I spent some additional time looking for internal BRL-CAD precedents and guardrails around the gist quality idea. I found some useful alignment with existing tolerance patterns (e.g., bg_tess_tol) and sketched a very incremental, multi-PR rollout that keeps everything backward-compatible.
No rush at all , just wanted to check whether the general direction still looks reasonable to you before I proceed further. Happy to share details if useful.
Aayush Sharma (Jan 25 2026 at 14:26):Hi @Sean sir
If the quality-knob direction feels too broad right now, I’m also happy to start with a very small, mechanical change (e.g., replacing the hardcoded render constants with named defaults) and take things incrementally from there.
Either way is fine
Last updated: Jan 26 2026 at 01:05 UTC