Topological Naming, My Take

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Topological Naming, My Take

Post by realthunder »

C_h_o_p_i_n wrote: Tue Sep 29, 2020 9:25 am might it be that the split feature does only work with a face right now ?

I recently tried to split a body using a second body due to I were needing some clearence between the resulting Bodys...
( I tried this, using your Freecad built from july )
You mean using a face from the second body? Just set the first body as the active body. Select the face in the second body. Click the green binder button to bring the face to the first body and split with it.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Topological Naming, My Take

Post by Kunda1 »

realthunder wrote: Wed Sep 30, 2020 3:39 am :bell:
@realthunder I've closed most of the tracker bugs related to toponaming as dupes of issue #922. I've also assigned the closed dupes to you.

Questions:
1. Do you have unit-tests for toponaming on your branch ?
2. Have you had any bugs reported lately regarding toponaming?
3. Are there any outstanding toponaming bugs on your branch that you're still tackling ?

Thanks for all your effort on this awesome feature. I really loved the FOSDEM presentation with you and @oficinerobotica
I've very excited for toponaming to be merged after v0.19 is released. Thank you again!
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Topological Naming, My Take

Post by realthunder »

Kunda1 wrote: Sat Feb 20, 2021 2:03 pm Questions:
1. Do you have unit-tests for toponaming on your branch ?
2. Have you had any bugs reported lately regarding toponaming?
3. Are there any outstanding toponaming bugs on your branch that you're still tackling ?
1. Not yet. I am hoping someone can step up and create one, haha, lazy me... But seriously, we do need someone else besides me to be familiar with the new APIs.
2 and 3. Not really a bug, but there is a known memory inefficiency problem, which I have already fixed in my other branch, but involves some big internal changes. I'll release that for the public to test soon. I plan to merge that improved version for toponaming. The differences is mostly changes of internal encoding.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
OficineRobotica
Posts: 433
Joined: Thu Feb 21, 2019 8:17 am
Contact:

Re: Topological Naming, My Take

Post by OficineRobotica »

I hate to be the annoying guy but I'm facing a problem and it could be related to the topo naming algorithm .
In the attached file there is an assembly that contains a link called "Bracket002". The "Bracket002" link references a body that has a configuration table set up for it. This link has the property <LinkCopyOnChange> set to <Enable> and also has some sublinks.

1- If inside the assembly I constrain the sublinks in the position they need to be then change the <Configuration(Braket type)> of "Bracket002" the elements used for constraining will give this error: "expected shape or sequence of shapes."

2- I'm wondering if the <LinkCopyOnChange> should be set to "Owned" before constraining and if the user should be warned that constraining a variant link before "individualizing" it is just asking for troubles

3-Now that I have the error, I'm lost. Take this as a typical user experience. My first instinct would be to delete the "Bracket002" link and start over with a fresh one already set up in the desired config then constraining it. But how do I delete the relative elements and constraints belonging to the link that previously yelded the error? I always wished for a "Delete object and related assembly elements" button . That might have consequences on the other constarined elements that rely on the deleted elements ... so yes , it's a complex matter.

4- Now that I'm here I wanted to report some problems with shadow. In the latest releases it seems that shadow on the ground is a bit hit and miss if the ground is transparent. I played with the <BoundBoxScale> and <Epsilon> but the shadows on the ground aren't there although the model itself receives them. I didn't want to report this but I think that the new renderer is not yet around the corner and shadows is what give visual punch to screenshots. That is important for PR reasons :)

ConfigTable.jpeg
ConfigTable.jpeg (345.83 KiB) Viewed 3466 times
Attachments
Bracket.FCStd
(593.24 KiB) Downloaded 71 times
profilo50x50.fcstd
(31.04 KiB) Downloaded 71 times
Check out my Youtube channel at: https://www.youtube.com/@OficineRobotica
hyarion
Posts: 139
Joined: Fri Jun 26, 2020 6:08 pm

Re: Topological Naming, My Take

Post by hyarion »

realthunder wrote: Tue Feb 23, 2021 4:15 am 1. Not yet. I am hoping someone can step up and create one, haha, lazy me... But seriously, we do need someone else besides me to be familiar with the new APIs.
I’m sure we can all help out testing and creating unit tests for it but right now I can’t even test it isolated since there’s no branch for it on freecad (I know you have it on your fork but I understand you have a lot of other changes too)
I think a good way to get people familiarized to the new feature would be to create a PR for it. I’m really looking forward to it :)
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Topological Naming, My Take

Post by realthunder »

OficineRobotica wrote: Tue Feb 23, 2021 5:52 am I hate to be the annoying guy but I'm facing a problem and it could be related to the topo naming algorithm .
In the attached file there is an assembly that contains a link called "Bracket002". The "Bracket002" link references a body that has a configuration table set up for it. This link has the property <LinkCopyOnChange> set to <Enable> and also has some sublinks.
You are entering some no man's land there.

I'd like to correct some misconception first about this solution to the Topological Naming Problem. The first the most important thing to solve is to detect topo name changes. With upstream, the indexed based topo name can change arbitrarily because of model history changes, and the user is not notified about this, until he/she finds out that something looks odd in the final shape. And tracing back the origin of the problem becomes difficult. So, the first thing to solve is to detect changes exactly at the referencing site.

The secondary, or shall I say, the other good-to-have bonus feature is for the algorithm to auto deduce what the referenced geometry has changed into. This involves guess work, and there will never be 100% foolproof solution. There is some auto deducing implemented in my branch, but they are quite conservative. If the algorithm is not sure about the result, it will mark the referencing object as error, and in other word, ask for user intervention. Since the problem is reported at the source, it is relatively easy to correct.

Now back to your use case here. The direct cause of the element error is actually not the topo naming error, at least not there yet. It is because variant link will copy its linked object on configuration change. The copy only happens on first change. Once changed, it will become "Owned". The copied object will change its name, and that is what caused the element error. The linked element can be found in element's LinkedObject property. There you'll see string path leading to the referenced geometry. Any object along the path misplaced will cause an error. It is possible for me to add extra code to auto correct any existing links that refers any sub-object of the mutating link, but it won't solve your problem here. Because the copied geometry will have totally different topo names than its origin. The topo names encode inside the object ID for uniqueness and history tracing. Copied objects all have different IDs, therefore will form completely independent history. It is as if you have replaced it with an unrelated part.

The recommended way, when used inside an assembly, is to mutate the part before hand, and create a sub-assembly to wrap each mutated part, create element manually to be used by upper assembly for constraining. And most importantly, assign the same label for each element in those sub-assembly to create a common interface so that they can be used by upper assembly interchangeably. You can add any one of the sub-assembly to an upper assembly using link, and then create configuration for the upper assembly to dynamically change what this link points to.

The interchangable assembly/part is one of the main purpose of the Element concept introduced by asm3 before I worked on topo naming. There is also a tutorial about that.

4- Now that I'm here I wanted to report some problems with shadow. In the latest releases it seems that shadow on the ground is a bit hit and miss if the ground is transparent. I played with the <BoundBoxScale> and <Epsilon> but the shadows on the ground aren't there although the model itself receives them. I didn't want to report this but I think that the new renderer is not yet around the corner and shadows is what give visual punch to screenshots. That is important for PR reasons :)
Can you please post a video showing the problem in the shadow thread? Your bounding box is too big, which will severely lower the quality of the generated shadow. Consider that the shadow is drawn on a fixed size image. The bounding box defines how big the area to fit into this image. If it's too big, the shadow will be scaled down too much.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
-alex-
Veteran
Posts: 1856
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Topological Naming, My Take

Post by -alex- »

OS: Debian GNU/Linux 10 (buster) (LXDE/LXDE-pi)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.27742 (Git)
Build type: Unknown
Branch: LinkStage3
Hash: 0a157a307c91d241a370cdda6d8f0471b7c48915
Python version: 3.7.3
Qt version: 5.11.3
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)
realthunder wrote:ping
Hi realthunder,

Thanks for your efforts in Linkstage3 2021-03-28 release: https://github.com/realthunder/FreeCAD_ ... 3/releases
The Daily branch has an important update on Topo Naming internals for much improved speed, memory, and storage efficiency. I plan to merge this version of topo naming into upstream, so please download and try this, and report any problem you have.
Sounds promising, but I guess there is some regression:
2021-04-01-new_toponaming_algo_regression.gif
2021-04-01-new_toponaming_algo_regression.gif (911.41 KiB) Viewed 2887 times


In this video I can't select one of the new edges by editing the existing filet featue when the base sketch is modified, no way. If I delete the filet feature then I make a new one it's ok. The behavior was more reliable with the previous algorithm AFAIK.
I have another example if you want, but the gif file is larger than 1Mo ATM.

Edit: OK, now I understand I've got it wrong, the toponaming I described here is not the new one because I did not compiled your linkdaily branch. However the above behavior is weird isn't it?
Last edited by -alex- on Fri Apr 02, 2021 7:00 am, edited 2 times in total.
User avatar
-alex-
Veteran
Posts: 1856
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: Topological Naming, My Take

Post by -alex- »

Ok, here is the 2nd example:
2021-04-01-new_toponaming_algo_regression2.gif
2021-04-01-new_toponaming_algo_regression2.gif (1.11 MiB) Viewed 2874 times

Toponaming is ok while modifying the base sketch but it is not ok while adding an intermediate pocket feature.
This behavior was ok in the past (2020-10-19 linkstage3 release for eg.).
Thanks you for your attention and your efforts.

Edit: same comment, the toponaming I described here is not the new one because I did not compiled your linkdaily branch. But here I can say that the behavior was more reliable in a previous daily build win64-Py3-Qt5 20201019.
Anyway, maybe my comments are outdated, if so I'm sorry for the noise.
Now I'm gonna try your linkdaily branch ;-)
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Topological Naming, My Take

Post by realthunder »

-alex- wrote: Thu Apr 01, 2021 10:18 pm Edit: same comment, the toponaming I described here is not the new one because I did not compiled your linkdaily branch. But here I can say that the behavior was more reliable in a previous daily build win64-Py3-Qt5 20201019.
Anyway, maybe my comments are outdated, if so I'm sorry for the noise.
Now I'm gonna try your linkdaily branch ;-)
I did discover quite a few problems with the enhanced topo naming thanks to your report. You may want to sync the LinkDaily branch again.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
mdesign
Posts: 104
Joined: Sat Mar 13, 2021 10:56 am

Re: Topological Naming, My Take

Post by mdesign »

Is there any plans to merge realthunder solution into the main branch during 0.20 cycle?
Post Reply