Yes that’s perfect. We’ll see about runtime later if needed.
Hrm, I’d say before going into master, I def need to finish the basic BOP operations but also need to develop a way to serialize/de-serialize the topological history. Then, I can add a compile-time flag for enabling/disabling toponaming and we should be good to go. Of course, this may all take another few months yet…sigh
Imho you need to solve the Performance issue. If the recompute gets slower with every change and is already noticable after 10 simple changes it renders freecad useless. This is a no-go. Large Models can see up to a few hundert changes per object.
I would say, this is not the right approach. The first thing needed are the robust references. This can then be the groundwork to improve the recompute process, because with the robust references there should be in principle the information available, which parts need an update. So in future FreeCAD may be able to do a more sophisticated recompute instead of recalculating everything each time.
Ulrich
I like the sound of that!
this does not hold for recomputes of individual features, every property change triggers always a recompute, and it is highly unlikely for recompute process of many features. And introducing a severe performance drop down for the chance that there “may be” a future possibility of improvement that may counter some of the introduced penalty is not a valid approach.
another applicable software development cliche: http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
Yes, it has to be fast when it is finished. No, it doesn’t have to be fast while it is in development. Yes, anything you put in now that is really slow will have to be changed before delivery. Yes, performance level is part of the acceptance criteria, just as much as lack of bugs.
That could become an official motto for freecad development, wandererfan! 
I’m glad that this has sparked so much discussion! My current next steps are:
- Fix bug where OCC exception is thrown when box is re-sized rather than cylinder
- Develop method of serializing/de-serializing topo history
- Finish implementing other BOPs into topo history framework
- profile TopoNamingHelper outside of freecad and start looking at potential optimizations.
All, as I haven’t posted in a while, I thought I’d drop in briefly to say that I have not been working on this since my last post. This is mostly because I am getting married on the 15th and have been focusing on that. I’ll likely pick this up again over the holidays, so hopefully there will be more meaningful updates in November and December.
Congratulations ezzieyguywuf, All the best 
Nice !! Congratulations all ready 12 days to go enjoy it!
Congratulations and take your time. You have other priorities now. Once things settle down a bit again we will still be here. 
Congrats are in place indeed. All the best wishes for you and your newly wedded wife!
Also good to hear you plan to pick this up after the honeymoon.
And I envy your long holidays: November-December
But seriously, looking forward to your work. Solving this would make Freecad sketcher so much more enjoyable to work with
Thank you all for the well wishes! The wedding was great and our honeymoon was delightful. We’re planning a move here at the end of the year (into a smaller apartment so we can save up for a house!!!) so I’ll plan on picking development back up in the new year, though I may not be able to resist keeping my hands off it all the way until then…
Hello, being neither a programmer, nor a particularly experienced FC user, nevertheless here come my 2ct.
I’m very grateful that the “robust references” issue seems to be under progress again - in fact this is the most annoying issue in FC to me: I little change in a “deep inside” part - and you can happen to start over again.
I’m certain that the “robust reference” approach is the right one to make FC even much better than it is at the moment.
Anyway, I’d like to share one thought:
As robust reference obviously is a complex issue and will quite likely still take quite some time, maybe years - should we thing about an in-between-solution, which can be implemented easily, and will deliver quite some effects of robust reference?
Being a FC dummy, from the user’s point of view my idea of such a solution looks like this:
- when planning a change in a “inner” component - user selects both the component in question and the final result
- user does something like a “destroy” command - which breaks the hierarchy apart (and saves the steps and the parts for reconstruction in the background)
- user applies changes at the “inner” part
- user does a “restore” - which “simply” carries out the steps necessary to reconstruct the final result
To me, that sounds like a fairly simple macro-like task - but of course I know that things are much more complicated that they look from the ignorant’s point of view. Maybe this is useful for somebody.
Have a nice day,
Wolf
Wolf? Is that short for Wolfgang? My name is Wolfgang!
Anyway, regarding your suggestion, I’m not sure I exactly understand. Can you maybe provide a simple example using some basic solids?
Hallo Wolfgang - nee, nur Wolf ohne gang. Eltern kommen auf komische Ideen…
This was my idea.
A part, designed of of a number of parts, fusioned, cut, chamferd etc:
Now I need a change in the “deep down hierarchy” parts - let’s say: change thickness of the “Rippe” parts:
You can try to make the alterations directly - this may or may not be successful.
The safe way is to “destroy” the part - meaning: remove all cuts, fusions, chamfers etc:
You get all your components:
Then you can make your alteration - and re-do all the cuts, fusions, chamfers you did before etc.
You need to pay attention not to make a mistake, and it takes time. And if you have to do it several times (I always have to…), it’s quite annoying.
So - couldn’t we have a possibility to “record” all the fusions, cuts, chamfers etc, to do the rebuilding automatically?
We can think about more sophisticated features in addition - enabling other parts to be added, change s simple step in rebuilding by a stop of the rebuild process where the user wants it etc.
But first - let’s talk about the “automatic rebuild” feature.
Am I more clear now?
Cheers,
Wolf - ohne gang.
Dear ezzieyguywuf,
I have another example model where I would like to hear your opinion to if this is related to ‘topological renaming’ issues or not.
I created a box in Part-Desing-Next and did thicken it inwards. Then I padded the inner bottom face and finally I did cut away of one of the sidewalls using its inner face.
Whenever I now mark all elements in my tree (Box, Thickness, Pad and Pocket) and for recompute the cut flips/jumps from one side to an other. Please see the attached screencast and the FC-model:
sreenfc4.webm.zip (637 KB)
FC_jumping_walls.fcstd (17.2 KB)
Thank you in advance,
HoWil
OS: Ubuntu 16.04.1 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9542 (Git)
Build type: None
Branch: master
Hash: 96dc57c06861922b9dde830e3bcc07e43ed11cf7
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17
Hello. It’s a great job you’re doing. Thank you very much.
There is a lot to want it to be integrated to freecad and I hope it will soon be accomplished. I know it’s a huge job and it’s done on your spare time.
I really need it to be able to make parametric design using external geometry.
Could you still give us an estimate on the temp needed to get to your end (in months in years 
)? Could you in your second post, tell us in percentage the finished work, so that we make an idea?
Again, thank you very much <3
(google translation of my french)