Proposal for GSoC - jnxd

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
ickby
Posts: 2936
Joined: Wed Oct 05, 2011 7:36 am

Re: Proposal for GSoC - jnxd

Postby ickby » Wed Apr 05, 2017 5:20 am

The main idea for this project was to work on the data structure and algorithms that are needed and to integrate them into TopoShape, completely without touching the document objects or gui. This scope is already very large and more than enough work. My thinking is that one needs to get the basics done before utilizing it withing the tools, because otherwise one ends up with half-backed special implementations for every tool.

As noted in the proposal there are currently two main ideas started: Jreihnlaender/ickby (both are basically the same: custom data structure on top of occ algorithms) and ezziguywuf (occ full naming framework). The goal should be to go forward on either on of it and not to start over with a completely new approach, as this would only lead to a third unfinished version.
User avatar
DeepSOIC
Posts: 7291
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Proposal for GSoC - jnxd

Postby DeepSOIC » Wed Apr 05, 2017 10:05 am

Here's the plan, not final by any means.
1. Make a new feature, which I would call "blended fusion".

This is C++.
This can take a number of forms, from independent new feature, to added "fillet radius" parameter, to support for use of generic fillets in PartDesign Pattern features, depending on how things go. What I want to achieve here is that jnxd gets the feel for how features are programmed, which is required to give any attempt to introducing toponaming. This will also involve playing with OCC's toponaming-related routines ("modified", most likely). And after all, it will be a useful feature to be merged to FreeCAD.

2. (may happen in parallel with 1). Introduction to how one works with shapes in python. This will probably involve writing a small python feature (maybe a macro). This should help jnxd to better understand what is the role of TopoShape in FreeCAD,

3. Minimalistically expose toponaming information provided by OCC in in TopoShape, for a few key operations such as .fuse. So that we can have a play with it, and find out how much information comes out.

4. Introduce better toponaming infrastructure to toposhape. This is when we'll explore the older attempts. And maybe literature review (IMO the very boring part, but may help).

5. Attempt at actual toponaming in features (i.e. change how PropertyLinkSub is used).

If things start to slip around step 3, there is an alternative place to put toponaming-related effort into: sketcher!
Adding the ability to give user-defined names to geometric elements in a sketch is a thing that will be useful regardless, and should be fairly straightforward and in jnxd's familiar territory.

Jnxd, ickby, anyone, do you like the plan?
User avatar
DeepSOIC
Posts: 7291
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Proposal for GSoC - jnxd

Postby DeepSOIC » Wed Apr 05, 2017 10:47 am

And I think the plan is good, and here's why. Almost every point in the plan contains a piece that is relatively small, and can be merged, and rewarded with user feedback. Thanks to that, I hope it's close to impossible to fail completely. The task is split into pieces that are somewhat scattered in scope, so I hope it's not boring. It has a Plan-B part.

The downside of the plan is that it's totally impossible to completely complete :P , IMO. But it more like a problem of the problem :P :P .

PS. This should have made it into the proposal :roll: so we are late to the party...
ickby
Posts: 2936
Joined: Wed Oct 05, 2011 7:36 am

Re: Proposal for GSoC - jnxd

Postby ickby » Wed Apr 05, 2017 11:11 am

I have a few remarks, mostly as I don't think this task should involve features at all. Also your approach is more a "learning by doing" way of working for the whole topological naming topic, but we already learned alot about the topic due to existing codes/experiments. So utilizing this knowledge and extending is IMHO more important.

Point 1 and 5: The given time is merly enough to extend the current approach, but never to a state where one could start touching features. Point 1 and 5 are IMHO not needed at all. (By the way: the jreihnlaender/cikby approach has been shown to work, so there must not be a seperate proof of principal)

Point 3: That may be nice for fast testing, but this comes for a large price. One need either to cache the operation in toposhape or make an extra datastructure to store the info... don't know if this is needed as one could do this experimenting in c++ anyway whenever porting a algorithm. Also the TopoShape Naming extensions provide access to data generated from this methods, so why not directly use the intended datastructure?


I would focus way more on the working of TopoShape and the principals of the existing implementations.
User avatar
DeepSOIC
Posts: 7291
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Proposal for GSoC - jnxd

Postby DeepSOIC » Wed Apr 05, 2017 11:53 am

ickby wrote:I have a few remarks, mostly as I don't think this task should involve features at all.
It has to. That's what we are aiming at, after all.
ickby wrote:but we already learned alot about the topic due to existing codes/experiments.
Not me and not jnxd. And unfinished code isn't a great thing to learn from.
ickby wrote:: That may be nice for fast testing, but this comes for a large price. One need either to cache the operation in toposhape or make an extra datastructure to store the info...
I see no way around storing something in toposhape. I think the storing should be made only on explicit request by the feature coder, to avoid potential blow-up in memory consumption.

The main idea about it is that the information is very useful for developing python features, even ignoring tomonaming stuff overall. The whole BOPTools is based on such information, for example.
ickby wrote:as one could do this experimenting in c++ anyway
my personal dispreference here. Python please!
ickby wrote:Also the TopoShape Naming extensions provide access to data generated from this methods, so why not directly use the intended datastructure?
I haven't really investigated the topic yet, thanks for pointing out. From what I read, I got an impression that it doesn't fit FreeCAD's way of operation, but sinsce you are bringing it up, I assume my impression is wrong and needs reconsideration.
User avatar
tanderson69
Posts: 1516
Joined: Thu Feb 18, 2010 1:07 am

Re: Proposal for GSoC - jnxd

Postby tanderson69 » Wed Apr 05, 2017 4:26 pm

Glad to see a discussion on a long standing problem! Going with the 'Jreihnlaender/ickby' idea you will need to implement your own naming resolution algorithms. With that in mind, I uploaded a zip file consisting of published pdfs on the subject. The file is too big for the forum so I uploaded to the following address. I will leave it there for a few weeks.

https://c.gmx.com/blobfish@gmx.com/JXO9 ... ZG51-R3INQ
ickby
Posts: 2936
Joined: Wed Oct 05, 2011 7:36 am

Re: Proposal for GSoC - jnxd

Postby ickby » Thu Apr 06, 2017 5:18 am

DeepSOIC wrote:It has to. That's what we are aiming at, after all.
It depends a bit on your point of view. My problem description when starting with this was to solve the reference problem, meaning being able to reference subshapes in a predictable and stable manner. The most important use case for me was the python API, to support easy finding of subshapes based on creation criteria and generating stable references for those subshapes. The usability for features comes than automatically
Not me and not jnxd. And unfinished code isn't a great thing to learn from.
Fair point. I think I will make a write-down of jreihnlaender/ickby approach for better accessibility. If it is choosen for further work is open, but may be nice to understand the experiments already done and the reasoning behind it.

One thing I like to stress is the amount of work that can be done in 3 Months. This includes the learning about a complex topic, and also by a student that is in general not as fast as a experianced coder. So the amount of progress will be rather limited and the scope should not be overestimated. That was annother reason for my initial restriction to TopoShape API.
User avatar
DeepSOIC
Posts: 7291
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Proposal for GSoC - jnxd

Postby DeepSOIC » Thu Apr 06, 2017 10:01 am

ickby wrote:I think I will make a write-down of jreihnlaender/ickby approach for better accessibility. If it is choosen for further work is open, but may be nice to understand the experiments already done and the reasoning behind it.
That'd be very nice, yes please :D
ickby
Posts: 2936
Joined: Wed Oct 05, 2011 7:36 am

Re: Proposal for GSoC - jnxd

Postby ickby » Sat Apr 08, 2017 5:46 pm

DeepSOIC wrote:
ickby wrote:I think I will make a write-down of jreihnlaender/ickby approach for better accessibility. If it is choosen for further work is open, but may be nice to understand the experiments already done and the reasoning behind it.
That'd be very nice, yes please :D
Here you go: https://docs.google.com/document/d/1-d2 ... sp=sharing
User avatar
DeepSOIC
Posts: 7291
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Proposal for GSoC - jnxd

Postby DeepSOIC » Sat Apr 08, 2017 9:29 pm

Thanks, I'm trying to digest this document. A few points that I think I understood so far:
* Each shape (TopoShape, to be precise) stores a dictionary (map) between subshape and its HistoryInfo. The map looks something like this:
"Edge1" <-> <history object>
"Edge2" <-> <another history object>
...
All edges and faces and vertices of the shape are listed. (nor not? there was something about the possibility to figure out an edge off of the other named subelements, such as a combination e.g."Face2", "Face3"))

These history objects and the map can be written to the file (which you wrote is not implemented yet)

* In SubLink, a hash of the history object is remembered, so SubLink will look like this:
>>> App.ActiveDocument.Extrude.DirLink
(<App.ActiveDocument.Box>, ['957620299569'])

And to get the actual edge, I should use this:
dir_edge = App.ActiveDocument.Box.Shape.subshape('957620299569')
And I can look up the hash of an edge like that:
>>> dir_edge.Reference
'957620299569'


* the history object has a few members that store hashes of shapes the subelement came from, as well as a UUID of an operation that was performed.
history_object.Type = [either NEW, GENERATED, or MERGED]
history_object.Base = ['28389275', '00198646'] #(list of hashes of subshapes this subshape was created from)
history_object.Name = <string> # (optional - a human-readable identifier of the shape, if history_object.Type == NEW)
history_object.Operation = <what? another object?>
history_object.OperationUUID = 187364901973 # this should be somehow tied to the feature that performs the operation, this is an unclear bit so far
history_object.Counter = <int> # unclear so far... but looks like optional

I'll try to figure out what is right and what is wrong with this understanding. @ickby: if you point out wrong bits in this interpretation, please let me know.
--------------------------
Questions that pop up.

1. on diagrams, you show that a vertex persistently gets the same exact hash (and it is a small number) as more and more extrusions are applied to it. How is that possible? (most likely there's something wrong with my understanding) ... Is it just taking the history object of the original Vertex in its full glory, which consequently has the same hash? If so, the hashes pointed by that history object may become unresolvable...

2. I think the Type enum is missing a "SPLIT" item.