I’m aiming to contribute for GSOC 2026. While I was looking for project ideas from the list, I did come across this project idea, and did dig into it a little to know if it would be suitable for me to work on as a GSOC project.
If you would like to study the codebase related to this, I would suggest you to start with the FEM workbench, as it has clearer structure and documentation compared to Assembly or MbD.
Directory - src/Mod/Fem. Some keyfolders you can look at are - femobjects, gui
Since the feature invloves mapping MbD forces to FEM loads, you can look into the directory - src/Mod/Fem/femobjects/ to understand how loads are implemented.
If you want to start by small contributions, you can fix a few FEM issues, or improve FEM documentation or simple UI fixes. You can search issues labeled ‘good first issue’ in the FreeCad repo.
I’ve been going through the list of project ideas for GSOC. The project idea that caught my attention is “Measurement: Add snapping to measurements”. (Issue #13708)
From what I understood, the goal is to improve measurements by snapping - where FreeCad would automatically select the closest geometrical point or edge or circle midpoints, if we click slightly beside the point/ vertex. This seems like a very useful improvement for usability.
Working on this idea would help me to understand how FreeCad handles selection, geometry detection, and interaction in 3D view.
Could someone kindly guide me on a few things :
Which modules or parts of the codebase are most relevant for this project? (For ex, I’ve seen references to the Measure workbench and the selection / 3D viewer code.)
Are there any good first issues related to measurement tools, selection, or snapping that I could begin with?
Is there any documentation explaining how the selection or snapping system works in the 3D view?
My plan is to understand the current workflow and contribute small fixes before drafting a proposal.
As part of getting familiar with the FreeCAD codebase and contributing to the project, I recently submitted a pull request related to the Spreadsheet module. The PR addresses a UI issue with the Escape Character preference used during CSV/TSV import and export.
I explored and learnt how CSV parsing is handled in the Spreadsheet workbench and how the preference is defined in the Qt UI.
The PR is still under discussion and review, and contributors have raised some useful points regarding CSV standards (RFC 4180).
Regardless of the final outcome, this process has helped me better understand the FreeCAD code structure and the contribution workflow.
Hi FreeCAD community! I’m Aakruti Ghatole, an MS Information Systems student at Northeastern University, graduating December 2026.
My background: At Siemens Digital Industries Software, I developed features for Solid Edge in C++. At Foundation EGI, I built Python automation scripts using NX Open to process CAD geometry and PMI data, engineered synthetic CAD datasets, and integrated that data with an AI Copilot system. I’ve used FreeCAD personally for mechanical part modeling and assemblies.
For GSoC 2026, I’m interested in the OctoPrint Integration project (issue #27320). The reason this connects to my background is that at EGI, the hardest part of CAD data handoffs wasn’t the transfer itself — it was ensuring geometry and metadata were preserved correctly, templates were followed, and errors were caught before propagating downstream. The FreeCAD → slicer → OctoPrint pipeline has the same class of problem.
I’ve already commented on the GitHub issue with a technical question for @kkremitzki about the slicer subprocess architecture. My current thinking is to build this as a Python addon, using a configurable subprocess call to an external slicer (PrusaSlicer or CuraEngine) and the OctoPrint REST API for file upload and print job management — architected to support multiple slicers from the start, similar to how FreeCAD handles multiple FEM solvers.
Looking for feedback on this direction. Also trying to find a good first issue to contribute to before the deadline — happy to take suggestions on where to look in addon or CAM-adjacent parts of the codebase.
I’m Abhijeet Kumar Thakur and I’m very interested in contributing to the OctoPrint Integration project for GSoC 2026. I’ve been studying the issue discussion and exploring the workflow between FreeCAD, slicers, and OctoPrint.
From a systems perspective, this problem looks similar to other CAD data pipelines used in FEM/BIM workflows, where geometry must move reliably through multiple processing stages. My idea is to implement a robust FreeCAD → Slicer → OctoPrint pipeline as a modular Python add-on.
The approach I’m considering includes:
• Automated STL/3MF export validation from FreeCAD models
• Configurable external slicer integration (PrusaSlicer / CuraEngine) using subprocess pipelines
• OctoPrint REST API integration for G-code upload and print job control
• A lightweight FreeCAD task panel for managing the full print workflow
Additionally, I’m exploring some possible enhancements such as:
• Multi-slicer architecture similar to FreeCAD’s multi-FEM solver approach
• Basic print monitoring dashboard using OctoPrint APIs
• Error detection in the export–slice pipeline to avoid failed prints
I’m currently reviewing the addon architecture and OctoPrint API to refine the design and will be submitting a detailed GSoC 2026 proposal shortly.
I’ve been preparing a proposal for GSoC 2026 over the past few weeks based on the project idea “Measurement: Add Snapping to Measurement Tools in FreeCAD.”
Before finalizing it, I would really appreciate feedback from contributors or mentors who are familiar with these parts of FreeCAD codebase.
In particular, I would be grateful to suggestions regarding :
Whether my understanding of the relevant codebase components is correct
If the proposed snapping workflow and approach make sense within the current architecture
Any improvements I could make to the technical design or implementation plan
I’m still learning and would appreciate any advice or pointers to help improve my proposal or deepen my understanding of the system.
Thank you for your time and feedback!
I would be happy to review other contributors’ project proposals and exchange feedback. gsoc proposal .pdf (117 KB)
I think it would also be important to support the intersection snap.
Perhaps this would be included in the future work section: Support for additional snap targets.
I hope you can get this google summer of code because it is an important feature to implement !
Welcome @Abhijeet005! Happy to see more interest in this project. I’ve been digging into the addon architecture in src/Mod/ — the CAM workbench looks like the closest structural reference for how to build this. Have you looked at how FreeCAD currently handles subprocess calls to external tools? Curious what approach you’re considering for the slicer CLI differences between PrusaSlicer and CuraEngine.
That is a really helpful suggestion - I hadn’t specifically considered intersection snapping in detail yet, but I agree it would be a useful addition. I will make sure to include it more clearly in the future work section.
I will also check the GitHub thread you mentioned and post there to get more feedback from contributors.
Thank you for taking the time to review my proposal and for the encouragement!
Hello Aakruti! Yess i had looked at currently subprocess for external tools like going to tree view and selecting the design and then go to the button which process I want to do. I had used prusa engine as it and made a secure connection btw Octoprint and FreeCAD with the api keys for transfer file.
I’ve been preparing a second proposal for GSoC 2026 on the project idea “Measurement: Add Snapping to Measurement Tools in FreeCAD.”
I had already submitted my first proposal on the same idea, and modified it by learning more things and implementation ideas.
Before finalizing it, I would really appreciate feedback from contributors or mentors who are familiar with these parts of FreeCAD codebase.
In particular, I would be grateful to suggestions regarding :
Whether my understanding of the relevant codebase components is correct
If the proposed snapping workflow and approach make sense within the current architecture
Any improvements I could make to the technical design or implementation plan