Topological Naming Project: Difference between revisions
(Removed link to Naming_project.) |
|||
(15 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
⚫ | |||
⚫ | |||
==Outline== |
==Outline== |
||
FreeCAD is a parametric modeling system, hence different modeling steps depend on one or more previous steps. Changes done to one object propagate through the modeling history to all dependent objects. This is achieved through a linking system, implemented with properties. This linking is very robust when done on a whole-object basis. However, many links need to be more fine grained and link to subparts of an object. In the Part workbench environment, for example, many links go to special topology entities like vertices, edges or faces. The stability of those links depend on the exact naming of the topology elements after a recompute. This is currently not guaranteed within FreeCAD, which can lead to many errors in the dependent modeling steps after simple changes to a base object. As the current development direction of FreeCAD seems to lead to a stronger use of those links the naming issue needs to be resolved. |
|||
The GSoC project aims at laying the foundation to solve this issue |
The GSoC project aims at laying the foundation to solve this issue and to prove the chosen approach on test cases. The preferred approach to solve the issue is described [https://docs.google.com/document/d/1-d2JD8RH13ar7QPh_SpX2H5eiNND4DiCPBmGwA2R9Ug/edit here], with an implementation started [https://github.com/ickby/FreeCAD_sf_master/tree/Naming here]. |
||
==Details== |
==Details== |
||
# Get familiar with opencascade, FreeCADs geometric modeling kernel, and grasp how the topology data structure works and how algorithms share, change and generate topology |
# Get familiar with opencascade, FreeCADs geometric modeling kernel, and grasp how the topology data structure works and how algorithms share, change and generate topology. Preferable the student already worked with opencascade, as the library is complex and getting into takes it's time. |
||
# Get familiar with FreeCADs linking system and how it links to topology entities in the opencascade datastructures. It is also important to understand the usage of occ in FreeCAD, the use of a dedicated topology class combined with direct use of occ algorithms outside of that class. This dual approach may not be ideal for a solution of the naming problem, hence a good understanding of it is required |
# Get familiar with FreeCADs linking system and how it links to topology entities in the opencascade datastructures. It is also important to understand the usage of occ in FreeCAD, the use of a dedicated topology class combined with direct use of occ algorithms outside of that class. This dual approach may not be ideal for a solution of the naming problem, hence a good understanding of it is required. |
||
# Start implementing a Identifier class that stores the creation history of a shape. Identify all data needed to make it unique and detail the interface. |
|||
# Go through books and papers to study possible topology naming algorithms and compare them to the occ approach. It is essential to evaluate all available possibilities in context of FreeCADs architecture to choose one which fits into it. A short list of intros can be found on [[Naming project]]. |
|||
# Integrate the identifier class into the Topology data structue and port a few first algorithms to use it. Also extend the Topology class python interface to allow the use of the identifiers for extracting subshapes. |
|||
# Provide a first prototype implementation of the chosen approach within FreeCAD. This may include necessary changes to FreeCADs handling of topology in the shape class and in features. The implementation requires a set of test cases and an integration into the available test system to ensure its stable working.. |
|||
# Create a set of test cases to show the effectiveness of the implementation. |
|||
==Expected Outcome== |
==Expected Outcome== |
||
⚫ | |||
# A extension of [[Naming project]] to include the reasoning for the chosen route of action, including references and comparisons of different algorithms. |
|||
⚫ | |||
# A set of test cases integrated into the available test system which show major cases of the topological naming problem and how they are resolved by the prototype implementation |
# A set of test cases integrated into the available test system which show major cases of the topological naming problem and how they are resolved by the prototype implementation |
||
==Future Possibilities== |
==Future Possibilities== |
||
If this project is finished successfully a full integration into the FreeCAD source can be part of further contribution or even a own GSoC project |
If this project is finished successfully a full integration into the FreeCAD source can be part of further contribution or even a own GSoC project |
||
==Project Properties== |
|||
===Skills=== |
|||
*Programming language C++ |
|||
*Deep understanding and use of APIs from FreeCAD and opencascade |
|||
*Ability to read and understand scientific texts and papers |
|||
*Knowledge of 3D modeling, topology and computational geometry is a plus |
|||
===Difficulty=== |
|||
Hard |
|||
===Additional Information=== |
|||
[[Category:Google Summer of Code]] |
Latest revision as of 20:02, 4 March 2022
This page is dedicated to the description of the Google Summer of Code project idea regarding topological naming.
Outline
FreeCAD is a parametric modeling system, hence different modeling steps depend on one or more previous steps. Changes done to one object propagate through the modeling history to all dependent objects. This is achieved through a linking system, implemented with properties. This linking is very robust when done on a whole-object basis. However, many links need to be more fine grained and link to subparts of an object. In the Part workbench environment, for example, many links go to special topology entities like vertices, edges or faces. The stability of those links depend on the exact naming of the topology elements after a recompute. This is currently not guaranteed within FreeCAD, which can lead to many errors in the dependent modeling steps after simple changes to a base object. As the current development direction of FreeCAD seems to lead to a stronger use of those links the naming issue needs to be resolved.
The GSoC project aims at laying the foundation to solve this issue and to prove the chosen approach on test cases. The preferred approach to solve the issue is described here, with an implementation started here.
Details
- Get familiar with opencascade, FreeCADs geometric modeling kernel, and grasp how the topology data structure works and how algorithms share, change and generate topology. Preferable the student already worked with opencascade, as the library is complex and getting into takes it's time.
- Get familiar with FreeCADs linking system and how it links to topology entities in the opencascade datastructures. It is also important to understand the usage of occ in FreeCAD, the use of a dedicated topology class combined with direct use of occ algorithms outside of that class. This dual approach may not be ideal for a solution of the naming problem, hence a good understanding of it is required.
- Start implementing a Identifier class that stores the creation history of a shape. Identify all data needed to make it unique and detail the interface.
- Integrate the identifier class into the Topology data structue and port a few first algorithms to use it. Also extend the Topology class python interface to allow the use of the identifiers for extracting subshapes.
- Create a set of test cases to show the effectiveness of the implementation.
Expected Outcome
- A first implementation within FreeCAD to show the working algorithm
- A set of test cases integrated into the available test system which show major cases of the topological naming problem and how they are resolved by the prototype implementation
Future Possibilities
If this project is finished successfully a full integration into the FreeCAD source can be part of further contribution or even a own GSoC project
Project Properties
Skills
- Programming language C++
- Deep understanding and use of APIs from FreeCAD and opencascade
- Ability to read and understand scientific texts and papers
- Knowledge of 3D modeling, topology and computational geometry is a plus
Difficulty
Hard