I understand there is nothing to be tested specifically to toponaming yet, just generally if everything still works?
I get a compilation error (probably due to using OCC latest?) regarding include "Standard_TooManyUsers.hxx" ( - strange naming) not found. Compiles fine when I just remove that line.
@realthunder: how much compatible are the files with the master atm? Could it be, if the files are saved in the development/toponaming branch, they are not backwards compatible? Just asking.
@realthunder: how much compatible are the files with the master atm? Could it be, if the files are saved in the development/toponaming branch, they are not backwards compatible? Just asking.
Greetings
user1234
I didn't find any incompatibility so far - if you save a file with the new version and reopen it with a "pre-toponaming" one, everything looks good and works as expected.
If you then save with the "pre-toponaming" version and reopen with the new FreeCAD, you''ll see (if enabled) lots of console messages stating required recompute to regenerate the element map, but everything works as expected after that. So it appears there is no drawback except the required recompute.
@uwestoehr: since you have merged the PRs, please allow me a question. How often will get the development/toponaming branch the commits from the master, i mean how often it will be harmonized? Because when it is too far ahead as the big PR#4752, harmonizing will be hard again.
mfro wrote: ↑Wed Sep 07, 2022 3:48 pm
I didn't find any incompatibility so far - if you save a file with the new version and reopen it with a "pre-toponaming" one, everything looks good and works as expected.
I wonder how this can be. If I attach something to a face, then it can behave differently in master and branch if I change a previous step, because a full recompute assignes the numbers to the faces more or less randomly. If the files are backwards compatible, does this mean that the random numbering isn't changed and only the mapping is different?
mfro wrote: ↑Wed Sep 07, 2022 3:48 pm
I didn't find any incompatibility so far - if you save a file with the new version and reopen it with a "pre-toponaming" one, everything looks good and works as expected.
I wonder how this can be. If I attach something to a face, then it can behave differently in master and branch if I change a previous step, because a full recompute assignes the numbers to the faces more or less randomly. If the files are backwards compatible, does this mean that the random numbering isn't changed and only the mapping is different?
My understanding (although not completely sure) is that the current state (with two PRs committed) generates and saves the information required to recover from TNP, but doesn't use it (yet). So the results appear (although not tested in every detail) just as wrong (or "compatible") as before.