Reimplementing constraint solver

[DeepSOIC]

@DeepSOIC

Any chance of a todo list, table or info graphic tracking the progress? Like all this red things still need to get sorted out and all this green ones have already been done?

I don't have one, so let me write one up real quick...

[DeepSOIC]

Development progress: https://github.com/DeepSOIC/FreeCAD-ellipse/issues/34

[triplus]

Looks good and i have to say nice progress already. Could you do me a favor and add one item under each:

Code: Select all

[*]3d geometry
[*]3d constraints

Whatever is considered "the easiest" to do. I suspect point and point-point distance could qualify? The math behind it doesn't look all that terrifying and in general most 3D geometric constraints solvers i have tried have the least amount of issues with it. Seeing something like that in writing would further solidify this effort as genuine. In addition it will be easier to redirect people here. @ickby might finally say heck i have that in my private branch already.

As for the front-end, beyond Sketcher. Are you particularity interested in tackling that or would rather see someone like @realthunder to chime in with Assembly 3 expertise? All that selection stuff, constrain representation in tree view as document objects and icons and ... possible edit modes ... I am mainly asking due to trying to figure out the appropriate upstream strategy. As if you are OK with that, then likely this will be made a requirement. That is potential directly Assembly upstreaming related functionality to be in-sync with this efforts scope for now.

[abdullah]

You may remember the quick fix from unique_ptr to shared_ptr to make MSVC compile. I have changed this back to a unique_ptr, but revised the way and it should compile now.

Why not just use shared_ptr? I get a feeling that using unique_ptr in this case gives a lot of restraints, no benefits, quite a bit of extra code, … an I get a feeling you are only doing it to flex your c++ muscle

A unique_ptr does not need reference counting and does not need to create a control block.

Aside from those benefits, which may be marginal given that the structure is almost not used in comparison to the overall solve, there is no real software requirement reason why to use shared pointer in this situation. I really struggle to accept there is no way to "convince MSVC", basically because I already got away with it in GeometryExtensions...

There should be no extra code once MSVC swallows it...

[abdullah]

Second crash is fixed, and I can now make a triangle. Yay!
FCSSketch-triangle.png

Thanks man! I have been looking at the fixes and they should have come from me. There was actually nothing wrong with ConstraintSolver. Sorry for that.

[DeepSOIC]

Thanks man! I have been looking at the fixes and they should have come from me.

No problem!

there is no real software requirement reason why to use shared pointer in this situation. I really struggle to accept there is no way to "convince MSVC", basically because I already got away with it in GeometryExtensions...

You're right, and there probably is a way to convince it, but i think it is just not worth the fight. + the problem might come up again as the code is modified.

[czinehuba]

Looks good and i have to say nice progress already. Could you do me a favor and add one item under each:

Code: Select all

[*]3d geometry
[*]3d constraints

Awsome work guys. Not a developper so don't know how easy or hard is to implement. But just a few things what other software do in terms of 3D sketch if this helps.
[*]3d geometry
- line
- helical curve(i know this exists in primitives already)
- arc (3points andn centre)
- bend
- point
- equation curve
- spline (control vertex and interpolation)

[*]3d geometry projections
- intersection curves
- silhouette curves
- project to surface
- curve on face
- include geometry

[*]3d constraints
- dimensions z,y,z
- coincident
- colinear
- on face
- lock
- equal
- parallele
- perpendicular
- parallele x.y.z and xy,yz,zx
- tangent
- smooth (g2)

[triplus]

Hi @czinehuba

That is a nice list BUT in my opinion it is not yet the time for that. One would more than do for now. More can be added after, like over the next decade.

[abdullah]

You're right, and there probably is a way to convince it, but i think it is just not worth the fight. + the problem might come up again as the code is modified.

I have the very bad habit of fighting lost causes.

The underlying idea of a unique_pointer vs shared_pointer is exclusive vs shared ownership.

In the case of GeoDef, there is a clear exclusive ownership. It is a FCSSketch-only structure that serves the purpose of keeping track of the relation between Sketcher and Solver. Neither the Sketcher, nor the Solver want it, it is worthless for them.

Looking at the error, I think I might be forced to explicitly write a move constructor/operator for GeoDef, but I need time to look at it.

I would also like to refactor the geometry and constraint creation before I extend the concept to other geometries and constraints.

This week is an awful one though, I do not think I will have time to code before the weekend.

[czinehuba]

Hi @czinehuba

That is a nice list BUT in my opinion it is not yet the time for that. One would more than do for now. More can be added after, like over the next decade.

Agree, just wanted to help out to show what other system do and work. Developpers then can choose one or two which is the easiest to implement.