# Difference between revisions of "Topological Naming Project"

Renatorivo (talk | contribs) (Marked this version for translation) |
|||

(4 intermediate revisions by one other user not shown) | |||

Line 1: | Line 1: | ||

+ | <languages/> | ||

+ | |||

+ | <translate> | ||

+ | |||

+ | <!--T:1--> | ||

This page is dedicated to the description of the Google Summer of Code project idea regarding topological naming. For the topic in itself please see [[Naming project]]. The linked wiki page can also serve as a starting point to get into the naming problem. | This page is dedicated to the description of the Google Summer of Code project idea regarding topological naming. For the topic in itself please see [[Naming project]]. The linked wiki page can also serve as a starting point to get into the naming problem. | ||

− | ==Outline== | + | ==Outline== <!--T:2--> |

FreeCADs is a parametric modeling system, hence different modeling steps depend on one or multiple previous steps. Changes done to one object propagate through the modeling history to all dependend objects. This is achived through a linking system, implemented with properties. This linking is very robust when done on a object basis, however, many links need to be more fine grained and hence link to subparts of a certain 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 guranteed within freecad, wich can lead to many errors in the dependend 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. | FreeCADs is a parametric modeling system, hence different modeling steps depend on one or multiple previous steps. Changes done to one object propagate through the modeling history to all dependend objects. This is achived through a linking system, implemented with properties. This linking is very robust when done on a object basis, however, many links need to be more fine grained and hence link to subparts of a certain 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 guranteed within freecad, wich can lead to many errors in the dependend 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. | ||

+ | <!--T:3--> | ||

The GSoC project aims at laying the foundation to solve this issue and to prove the choosen approach on test cases. The prefered 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]. | The GSoC project aims at laying the foundation to solve this issue and to prove the choosen approach on test cases. The prefered 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== <!--T:4--> |

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

Line 13: | Line 19: | ||

# Create a set of test cases to show the effectiveness of the implementation. | # Create a set of test cases to show the effectiveness of the implementation. | ||

− | ==Expected Outcome== | + | ==Expected Outcome== <!--T:5--> |

# A first implementation within FreeCAD to show the working algorithm | # 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 | # 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== <!--T:6--> |

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== | + | ==Project Properties== <!--T:7--> |

===Skills=== | ===Skills=== | ||

*Programming language C++ | *Programming language C++ | ||

Line 29: | Line 35: | ||

Hard | Hard | ||

− | ===Additional Information=== | + | ===Additional Information=== <!--T:8--> |

+ | <!--T:9--> | ||

[[Category:Google Summer of Code]] | [[Category:Google Summer of Code]] | ||

+ | |||

+ | </translate> |

## Latest revision as of 21:22, 20 January 2020

This page is dedicated to the description of the Google Summer of Code project idea regarding topological naming. For the topic in itself please see Naming project. The linked wiki page can also serve as a starting point to get into the naming problem.

## Contents

## Outline

FreeCADs is a parametric modeling system, hence different modeling steps depend on one or multiple previous steps. Changes done to one object propagate through the modeling history to all dependend objects. This is achived through a linking system, implemented with properties. This linking is very robust when done on a object basis, however, many links need to be more fine grained and hence link to subparts of a certain 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 guranteed within freecad, wich can lead to many errors in the dependend 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 choosen approach on test cases. The prefered 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