[Feature request] Sketcher point-on-point gives one common point

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!
User avatar
Pauvres_honteux
Posts: 728
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: [Feature request] Sketcher point-on-point gives one common point

Post by Pauvres_honteux »

chrisb, now we are just typing past each other.
Please reread this topic and try to understand its intended goal: simplify and stabilize (and declutter).
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: [Feature request] Sketcher point-on-point gives one common point

Post by chrisb »

Ok, I had thought your last proposal was about a single coincidence connecting more than two points.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: [Feature request] Sketcher point-on-point gives one common point

Post by abdullah »

Hi there!

Sorry for the very late response. I had a tough summer.
Pauvres_honteux wrote: Fri Aug 27, 2021 10:03 am What I'm proposing is to get rid of the coincident constraining for the case when you create (in a chain-event) line after line after radius after ... you get the picture.
My suggestion also involves creation of separate lines, radii, spline connected with points belonging to already existing geometry.
The coincident constraint is the "glue" here. You would need to create all the combinations of all supported geometries for the general case of coincidence.

From a different view, if you add three lines with one common coincident point as you show, the use of two coincident constraints ensure that you can delete any of them while keeping the other two (under the hood the coincident constraints are mangled where necessary to support this).
Pauvres_honteux wrote: Fri Aug 27, 2021 10:03 am An interesting observation is that when creating a fillet between two lines (connected or not) the coincident constrain disappears and gets replaced by tangent constraints instead! So in a sense some of the functionality is already there.
That is why I wrote "general case" above. Tangent+coincident and normal+coincident are special cases. The reason is that the corresponding tangent and normal solver implementations implicitly force a coincidence. However, the moment you remove the tangency/normal you do need "glue" again.
Pauvres_honteux wrote: Fri Aug 27, 2021 10:03 am Another gain would be to get rid of the problem of selecting a specific point when they are on top of each other.
I can give you that. The problem of selecting a specific point is annoying. However, the solution needs to come from elsewhere. I think RT's branch has a better selection for coincident elements.
abdullah wrote:
Perhaps abdullah can comment on the possibility of less strain on the CPU if a lot of constraints got replaced by a common point?
[/quote]

The solver knows little about "geometry". It has a number of "parameters" (as many as the geometries need) to which it applies constraints. It does know a lot about (solver) constraints. With a point you've got two parameters (x,y). If you want to make two lines coincident on a point, you need to equate the x,y parameters of one point of each line. This is the coincidence constraint. If you do not do that, no matter how you implement the higher level, one line will move with respect to the other. This also applies to the "combination of elements"...
User avatar
Pauvres_honteux
Posts: 728
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: [Feature request] Sketcher point-on-point gives one common point

Post by Pauvres_honteux »

abdullah wrote: Fri Sep 10, 2021 12:01 pm I had a tough summer.
Sorry to hear that, but you are in good company, however unfortunate.

abdullah wrote: Fri Sep 10, 2021 12:01 pm ... make two lines coincident on a point, you need to equate the x,y parameters of one point of each line. This is the coincidence constraint
I interpret your answer as: the number of CPU-clock cycles are the same for solving an equation system as for linking one set of (x,y)-coordinates to another point?
Last edited by Pauvres_honteux on Fri Dec 10, 2021 10:05 am, edited 1 time in total.
drmacro
Veteran
Posts: 8862
Joined: Sun Mar 02, 2014 4:35 pm

Re: [Feature request] Sketcher point-on-point gives one common point

Post by drmacro »

Maybe it's just my mental image of things...

Two edges, each has two vertexes. Thus there are 4 distinct vertexes. Declaring one from each coincident means they happen to be in the same location in space and are to remain so...not that they are one thing.

Coincidence is a condition, a defined relationship.
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: [Feature request] Sketcher point-on-point gives one common point

Post by abdullah »

Pauvres_honteux wrote: Mon Nov 22, 2021 12:13 pm I interpret your answer as: the number of CPU-clock cycles are the same for solving an equation system as for linking one set of (x,y)-coordinates to another point?
You cannot separate a point from the rest in "solving an equation system". You generate a number of relations between different coordinates of different points of different geometries. All these relations define "the" equation system. If you link one set of coordinates you are changing the equation system. The new equation system needs to be solved.
User avatar
Pauvres_honteux
Posts: 728
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: [Feature request] Sketcher point-on-point gives one common point

Post by Pauvres_honteux »

abdullah wrote: Mon Nov 22, 2021 1:24 pm You cannot separate a point from the rest in "solving an equation system".
Okey, I get your point. ;)

Now, how about my point? That is, cpu clock cycles must surely be higher for running/solving geometric constraints versus a link to a 2D-vector (X,Y), right?

Next question would be for the case where the user ONLY drags one end of a line/curve/radius. Here I'd like to know the difference in clock cycles between link to a 2D-vector versus geometrical constraints. Does this use case even trigger the solving of the equation system?
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: [Feature request] Sketcher point-on-point gives one common point

Post by chrisb »

Pauvres_honteux wrote: Fri Dec 03, 2021 6:06 am That is, cpu clock cycles must surely be higher for running/solving geometric constraints versus a link to a 2D-vector (X,Y), right?
I don't see this. Please elaborate, e.g. by giving a simple example and an outline of an algorithm that prove your statement.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
drmacro
Veteran
Posts: 8862
Joined: Sun Mar 02, 2014 4:35 pm

Re: [Feature request] Sketcher point-on-point gives one common point

Post by drmacro »

Two edges have 4 vertexes (2 for each edge). The vertexes are unique individual parts of their respective edges. Coincidence is a condition between two of the vertexes, it is not a redefinition or physical merging of the vertexes.

As for saving cpu cycles, short of having someone actually lash up the code and run benchmarks it is just guesswork.
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
User avatar
Pauvres_honteux
Posts: 728
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: [Feature request] Sketcher point-on-point gives one common point

Post by Pauvres_honteux »

chrisb wrote: Fri Dec 03, 2021 8:19 am ... a simple example and an outline of an algorithm that prove your statement.
You will not get any proof. It was a question, not a statement.
Traversing drmacro's simple example and adding: coincidence must be calculated, compared with a link to a memory adress (a pointer in programming terms).

The number of cpu-clock cycles involved in reading and writing a pointer is among the lowest a cpu can do while still doing anything meningful (for a human).

Purely logical, calculating coincidence must use more cpu-clock cycles than that. No proof, just simple logic.

Regarding abdullahs stement: "solving an equation system must still be done".
Well, you who read this must separate equation system from geometrical constraints, they are two different things. One doesn't necessarily trigger the other.
Solving an equation system shall not be done if no geometry has changed.
When an equation system must be solved, then the overburden of coincident calculation should be kept as low as it is ever possible.

Now, why whould a few coincident constraints matter you say? In a real world working environment one usually link things to each other including sketches as a whole and part of sketches. That is, when changing something (e.g. moving a defining 2D/3D point) it will trigger a lot of changes, including sketches, which in turn changes other stuff and so on. If one has done it right the whole model updates without breaking and if everything is done properly one can "simulate" in real time how a proposed change will affect the model (very common during development in a conference room where suggestions fly through the room).
And here lies the culprit, in order to have resonable update speed, everything must be made cpu clock cycle efficent, leaving no stone unturned. I.e. this includes sketcher internals.

As the saying goes: "many small streams soon turn into a large river".
Post Reply