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!
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Topological Naming, My Take

Post by GeneFC »

Mikeosaurus wrote: Sat Aug 28, 2021 11:48 am I'm too scared to use RT branch in case I find I can't bring my models back to main branch after months/years of working on stuff
The FCStd file format used in the RT version is rather different than the standard version. I believe there is an attempt to make the RT files compatible with standard, but as said elsewhere, no guarantees.

I would plan to stick with one or the other for maximum future compatibility with your models. Going back and forth may or may not work.

There is a growing and somewhat vocal crowd urging the switch to the RT version, but frankly it is a one-person effort (a very good one) and not really the typical FOSS. Obviously there are risks.

The original stated plan was to incorporate many of the changes into FreeCAD. Some of this has occurred, but progress has been slow lately.

Gene
FRIEND OF GOD
Posts: 12
Joined: Wed May 04, 2022 6:01 pm

Re: Topological Naming, My Take

Post by FRIEND OF GOD »

Three Independent Suggestions for removing topographical naming issues:

Suggestion #1:

All New Sketches, and Predefined Shapes, are automatically put onto datum planes; there will be one button for a New Sketch, and there will not be any buttons for Datum Planes; Buttons may continue to exist for Datum Points, and perhaps Datum Lines, et cetera, but no buttons for DatumPlanes;

Suggestion #2:

The orientation of all New Sketches are pegged only to the origin; secondary orientation pegs can be to faces and et cetera.

Suggestion #3:

When beginning a New Sketch, prefill an empty array/hash with thousands of unused values;

for example, at the moment, I presume that the topographical naming array/hash would normally be new and empty ?

instead, of just putting items into an array/hash for a New Sketch with consecutive values beginning with 0, how about prefilling the array with 10,000 unused generic values, or another anticipated amount;

and then, when putting the first "sketch-line" into the array, instead of associating the sketch-line with the array #0, use the array #100;

and then, when putting a second sketch-line into the array...
check for the amount of unused generic array values that exist after the array #100, up to 200 array slots, or another amount (no need to check the entire array), and then, divide the consecutive unused values by 2, and then, put the second sketch-line into the array at that number;

and then, when putting a third sketch-line into the array...
check for the amount of unused generic array values that exist after the last defined array #, up to 200 array slots, or another amount (no need to check the entire array), and then, divide the consecutive unused values by 2, and then, put the third sketch-line into the array at that number;

and then, the same can be done for a fourth sketch-line...
check for the amount of unused generic array values that exist after the last defined array #, up to 200 array slots, or another amount (no need to check the entire array), and then, divide the consecutive unused values by 2, and then, put the fourth sketch-line into the array at that number;

and then, the same can be done for padding the box;

and then later, when including an edit midway into the array, such as when a fillet is included to the padded box after more sketch-lines were included into the Sketch/Array, a check would be done to check for the appropriate array numbers in the array pertaining to the intended fillet edit, and then, the amount of consecutive unused values that still exist after any array value that was to be edited would be checked, and then, that amount would be divided by 2, and then, the fillet name would use that unused array value; and all those array designations would be done without shifting the overall order of the array, and without changing the array values for any particular sketch-line, sketch-pad, sketch-fillet, et cetera.

Suggestion #4:

If not already being done, all topographical naming shall be done using hashes, instead of arrays;

when an edit is done to a Sketch, such as including a new sketch-line, an inclusion will be put into the hash that will have a hash name and a never changing unique hash value; such as "0 = line 0";

all calls done to the hash, will not be done to the hash name, such as 0, and are done to the never changing unique hash values, such as "line 0";

the routine for putting new inclusions into the hash will always check for the existence of the unique hash value, so as to always maintain unique hash values;

an independent counter is always incremented, and inclusions into the hash always get the unique count from the counter while forming new hash values, so as to prevent issues pertaining to "undo/redo";

Suggestion #5:

If any of the above suggestions resolve the topographical naming issue, I request that all other bugs and suggested features posted by Myself get a priority preference.

p.s. I Am presuming that topographical naming is being done using arrays/hashes.

Thanks

Another Good Day With GOD
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Topological Naming, My Take

Post by chrisb »

FRIEND OF GOD wrote: Wed May 04, 2022 7:16 pm Suggestion #1:

All New Sketches, and Predefined Shapes, are automatically put onto datum planes;...
Suggestion #2:

The orientation of all New Sketches are pegged only to the origin; secondary orientation pegs can be to faces and et cetera.

Suggestion #3:
...
I can't yet judge what #3 adds to solving the TNP, but I doubt that the others are helpful:

#1 It is known that there is no improvement of stability by using a DatumPLane as compared to using a sketch with the same attachment.

#2 The secondary references will bear the same problems as already known from attaching directly to generated geometry.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
c-orderer
Posts: 1
Joined: Wed Sep 08, 2021 2:27 am

Re: Topological Naming, My Take

Post by c-orderer »

FRIEND OF GOD wrote: Wed May 04, 2022 7:16 pm Three Independent Suggestions for removing topographical naming issues:

Suggestion #1:

All New Sketches, and Predefined Shapes, are automatically put onto datum planes; there will be one button for a New Sketch, and there will not be any buttons for Datum Planes; Buttons may continue to exist for Datum Points, and perhaps Datum Lines, et cetera, but no buttons for DatumPlanes;

Suggestion #2:

The orientation of all New Sketches are pegged only to the origin; secondary orientation pegs can be to faces and et cetera.

Suggestion #3:

When beginning a New Sketch, prefill an empty array/hash with thousands of unused values;

for example, at the moment, I presume that the topographical naming array/hash would normally be new and empty ?

...

Suggestion #4:

If not already being done, all topographical naming shall be done using hashes, instead of arrays;

when an edit is done to a Sketch, such as including a new sketch-line, an inclusion will be put into the hash that will have a hash name and a never changing unique hash value; such as "0 = line 0";

all calls done to the hash, will not be done to the hash name, such as 0, and are done to the never changing unique hash values, such as "line 0";

the routine for putting new inclusions into the hash will always check for the existence of the unique hash value, so as to always maintain unique hash values;

an independent counter is always incremented, and inclusions into the hash always get the unique count from the counter while forming new hash values, so as to prevent issues pertaining to "undo/redo";

Suggestion #5:

If any of the above suggestions resolve the topographical naming issue, I request that all other bugs and suggested features posted by Myself get a priority preference.

p.s. I Am presuming that topographical naming is being done using arrays/hashes.

Thanks

Another Good Day With GOD
#3 Sounds like trading 1 problem for 100s of other problems.

If sketches are always attached to planes and the whole system is sequenced why can't the plane be relative to the previous? Removing something would require re-orienting the lower plane(s) but links wouldn't be broken right?
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Topological Naming, My Take

Post by adrianinsaval »

FRIEND OF GOD wrote: Wed May 04, 2022 7:16 pm
I appreciate the effort but you clearly don't understand enough of the subject and you can't possibly expect to solve a problem you don't actually understand. Besides even if your idea was good it's not much use if you don't code it. Also we already have working code to vastly mitigate this problem waiting merge approval.
and there will not be any buttons for Datum Planes
huh? how does this help? :?
Suggestion #5:
If any of the above suggestions resolve the topographical naming issue, I request that all other bugs and suggested features posted by Myself get a priority preference.
That's not how this works buddy
FRIEND OF GOD
Posts: 12
Joined: Wed May 04, 2022 6:01 pm

Re: Topological Naming, My Take

Post by FRIEND OF GOD »

chrisb wrote: Wed May 04, 2022 10:16 pm
FRIEND OF GOD wrote: Wed May 04, 2022 7:16 pm Suggestion #1:

All New Sketches, and Predefined Shapes, are automatically put onto datum planes;...
Suggestion #2:

The orientation of all New Sketches are pegged only to the origin; secondary orientation pegs can be to faces and et cetera.

Suggestion #3:
...
I can't yet judge what #3 adds to solving the TNP, but I doubt that the others are helpful:

#1 It is known that there is no improvement of stability by using a DatumPLane as compared to using a sketch with the same attachment.

#2 The secondary references will bear the same problems as already known from attaching directly to generated geometry.
quote from chrisb: "I can't yet judge what #3 adds to solving the TNP"

Response: My Impression of the topographical naming issue is that the location names change in the internal hash/array when including an edit to a sketch, such as including a fillet into the sketch; it seems, presumably, that the location names are put into some type of array/hash, and then when an edit is done, such as including a fillet, the location name is pushed to the next line in the internal hash/array;

I am suggesting predefining thousands of unused slots in the internal hash/array, and then, when a sketch line is done, for example, the sketch-line can be placed in an appropriate location in one of the empty slots, with sufficient empty slots between, and then, when an edit such as a fillet is done, the edit can be included in the appropriate place in the hash/array without bumping any of the other slots to another location;

quote from chrisb: "#1 It is known that there is no improvement of stability by using a DatumPLane as compared to using a sketch with the same attachment."

Response: It is because there may not be a need to have a separate DatumPlane, that I suggestion just combining/attaching a DatumPlane to every New Sketch, and removing the DatumPlane Button as being unnecessary; Perhaps even the DatumLines, and DatumPoints, can just be done as a New Sketch, on New Sketches, and then, the buttons for DatumPoints and DatumLines can also be removed.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Topological Naming, My Take

Post by chrisb »

FRIEND OF GOD wrote: Sat May 07, 2022 5:39 pm quote from chrisb: "#1 It is known that there is no improvement of stability by using a DatumPLane as compared to using a sketch with the same attachment."

Response: It is because there may not be a need to have a separate DatumPlane, that I suggestion just combining/attaching a DatumPlane to every New Sketch, and removing the DatumPlane Button as being unnecessary; Perhaps even the DatumLines, and DatumPoints, can just be done as a New Sketch, on New Sketches, and then, the buttons for DatumPoints and DatumLines can also be removed.
If there is no need I don't see any advantage to have a DatumPlane. It just crowds the tree.

Besides: Please don't quote whole posts, but only the parts you are directly referring to.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
FRIEND OF GOD
Posts: 12
Joined: Wed May 04, 2022 6:01 pm

Re: Topological Naming, My Take

Post by FRIEND OF GOD »

@adrianinsaval
adrianinsaval wrote: Thu May 05, 2022 12:41 pm
FRIEND OF GOD wrote: Wed May 04, 2022 7:16 pm
I appreciate the effort but you clearly don't understand enough of the subject and you can't possibly expect to solve a problem you don't actually understand. Besides even if your idea was good it's not much use if you don't code it. Also we already have working code to vastly mitigate this problem waiting merge approval.
and there will not be any buttons for Datum Planes
huh? how does this help? :?
Suggestion #5:
If any of the above suggestions resolve the topographical naming issue, I request that all other bugs and suggested features posted by Myself get a priority preference.
That's not how this works buddy
quote from adrianinsaval: "I appreciate the effort but you clearly don't understand enough of the subject and you can't possibly expect to solve a problem you don't actually understand. Besides even if your idea was good it's not much use if you don't code it. Also we already have working code to vastly mitigate this problem waiting merge approval."

Response: My Impression of the topographical naming issue, is that every edit done to a sketch is given a location name in an internal hash/array, and therefore, when including an inclusion is done to a sketch, such as including a sketch-line into the sketch; it seems, presumably, that the location name of the sketch-line is put into some type of array/hash, and then when an edit is done, such as including a fillet, the location name is pushed somewhere midway into the hash/array somewhere next to the sketch-line or something else that is already in the internal hash/array, thereby causing the entire list in the hash/array to shift, and thereby causing the location names of the items in the hash/array to change, such as Sketch007 to Sketch008.

I am suggesting that by predefining thousands of unused slots in the internal hash/array, that when a sketch-line is done, for example, the sketch-line can be placed in an appropriate location in one of the empty slots, with sufficient empty slots before and after, and then, when a sketch edit is done, such as a fillet, the sketch edit can be included in the appropriate place in the hash/array without bumping any of the other slots to another location; the empty slots in the hash can be filled and predefined with the value "empty" or another appropriate value; for example...

(prefilling hash with several "empty" values after each sketch edit, allows empty slots to be filled later without moving items in hash)

0 = empty
1 = LINE001
2 = empty
3 = empty
4 = empty
5 = empty
6 = empty
7 = empty
8 = empty
8 = LINE008

and then, when a fillet is edited, such as to LINE001, the fillet can be inlcuded into one of the empty slots, without shifting LINE009; for example...

0 = empty
1 = LINE001
2 = empty
3 = empty
4 = empty
5 = FILLET005
6 = empty
7 = empty
8 = empty
9 = LINE009

quote from adrianinsaval: "
and there will not be any buttons for Datum Planes
huh? how does this help? :? "

Response: It is because there may not be a need to have a separate DatumPlane, that I suggestion just combining/attaching a DatumPlane to every New Sketch, and removing the DatumPlane Button as being unnecessary; Perhaps even the DatumLines, and DatumPoints, can just be done as a New Sketch, on New Sketches, and then, the buttons for DatumPoints and DatumLines can also be removed.

quote from adrianinsaval:
Suggestion #5:
If any of the above suggestions resolve the topographical naming issue, I request that all other bugs and suggested features posted by Myself get a priority preference.
That's not how this works buddy
Response: If I can provide a viable solution to the topographical naming issue that has been an issue for years, then I was just suggesting that the bugs and features I suggest can get a priority review ?
user1234
Veteran
Posts: 3320
Joined: Mon Jul 11, 2016 5:08 pm

Re: Topological Naming, My Take

Post by user1234 »

FRIEND OF GOD wrote: Sat May 07, 2022 6:09 pm Response: If I can provide a viable solution to the topographical naming issue that has been an issue for years, then I was just suggesting that the bugs and features I suggest can get a priority review ?
Your suggestion solves nothing. You do not understand the real problem of the TNP.
FRIEND OF GOD
Posts: 12
Joined: Wed May 04, 2022 6:01 pm

Re: Topological Naming, My Take

Post by FRIEND OF GOD »

@c-orderer
c-orderer wrote: Wed May 04, 2022 10:48 pm
#3 Sounds like trading 1 problem for 100s of other problems.

If sketches are always attached to planes and the whole system is sequenced why can't the plane be relative to the previous? Removing something would require re-orienting the lower plane(s) but links wouldn't be broken right?
Response: #3 is pertaining to temporarily prefilling hashes with empty values that can be used later without shifting what is put into the hash; And if sketches are attached to DatumPlanes automatically, then perhaps all those DatumPlane Buttons would not be necessary; And if each New Sketch / DatumPlane is automatically attached to the origin, and then somehow linked to other Sketches at the fringes, then perhaps each New Sketch can be isolated from the other Sketches, except perhaps at the link points between Sketches; at least the isolated hashes for each sketch will not be affected by other Sketches ?

And instead of linking two Sketches together directly, perhaps there can be intermediate DatumPoint/DatumPlanes (Reference Sketch), that are also automatically attached to the origin, and then, each isolated Sketch can be linked together by the DatumPoint, such as linking the ends of two lines to a isolated independent point that is not likely to change position because the point is isolated, and therefore, if one of the Sketches does have a topographical naming issue, then the isolated independent point will not move, and the other Sketches will not move.

There is a Drawing Software at www.getpaint.net that uses "layers"; each layer can be moved up or done in the menutree, cover or uncovering a different layer, and each layer can also be clicked to be hidden/shown in the layer tree; the layers can later be "merged" together to form an "image"; perhaps FreeCAD can use a similar scheme with Sketches, by using Sketches as "layers", and then later "merging" the layers into a single "image" ?
Post Reply