Reimplementing constraint solver

[chrisb]

Two recent topics about a flipping sketches made me think again about improvements, and perhaps it worth to be included in your considerations.

We don't have inequalities among the constraints but I think such new kind of constraints aren't even necessary. In many cases an "oriented dimension" would be enough. I'm not sure if it would work in all cases, but it would sure be a relief.

The new dimension would have a start and an endpoint and distinguish between positive and negative values. For a horizontal dimension this would mean that a positive dimension would go from the first point selected always to the right:

Snip macro screenshot-3e9d37.png (2.47 KiB) Viewed 2605 times

and a negative value would always go to the left:

Snip macro screenshot-6165d1.png (2.6 KiB) Viewed 2605 times

In the GUI these constraints could live in an icon submenu similar to radius/diameter, or the various regular polygons.

If you think it is worth considering I would think about the arbitrary oriented length constraint, which I haven't done yet.

[abdullah]

In order to avoid this kind of mistakes, I have removed the type from function:
...
Should I bring similar changes to ParaObject::tieAttr_Child?

nice! yes please

Unfortunately, I did not manage to.

The Type that tieAttr_Child takes is not the one of of ChildType (e.g. ParaPoint), but the one of the twin Python class (ParaPointPy).

1) I have tried to get the type ParaPointPy from ParaPoint without success.

ParaPointPy has a limited knowledge (string in Type struct of the PyObject) of ParaPoint. But a string is no cool at all for type checking.

ParaPoint does not know about ParaPointPy (other than knowing it is a friend class and a hardcoded type in getPyObject(), which I do not find it usable to extract the type via template metaprograming).

2) It may be possible to get it from the Interpreter, but really I do not like that dependency.

3)As an alternative, I have thought of constraining template function generation (so that we get a compilation error if the parameter is wrong):

Code: Select all

   template <  typename ChildType,
                typename PythonType,
                typename = typename std::enable_if<
                    std::is_base_of<ParaObject, typename std::decay<ChildType>::type>::value
                    &&
                    std::is_base_of<ParaObjectPy, typename std::decay<PythonType>::type>::value
                    &&
                    std::is_same< std::decay<typename PythonType::PointerType>::type, typename std::decay<ChildType>::type>::value
             >::type
    >
    void tieAttr_Child(UnsafePyHandle<ChildType>& ref, std::string name, PythonType * type, bool make = false, bool required = true, bool writeOnce = false);

The above does not work because of this:

[code]
std::is_same< std::decay<typename PythonType::PointerType>::type, typename std::decay<ChildType>::type>::value

PointerType is not a member function of PythonType, but a typedef. It is the only place were I see the type information of the twin function coded:

Code: Select all

class FCS_G2DExport ParaPointPy : public FCS::G2D::ParaGeometry2DPy
     ...
    typedef ParaPoint* PointerType ;
    ...

I will give it a further go before giving up. Maybe somebody reads this and says: "C'mmon, you can use XXX"...

[DeepSOIC]

it should be feasible to completely transfer child attributes to use c++ typesystem.

[DeepSOIC]

The fourth case is the typical select a line a hit the angle constraint. How should this be done with FCS?

I guess you'll have to add the fixed axis line and use line-line angle constraint. Writing separate FCS constraint for this case feels a bit wasteful...

[DeepSOIC]

The new dimension would have a start and an endpoint and distinguish between positive and negative values. For a horizontal dimension this would mean that a positive dimension would go from the first point selected always to the right:

that's pretty much exactly what horizontal-distance and vertical-distance do. The sign is made positive automatically by swapping the endpoints at creation time if necessary, but negative numbers are very well supported.

As for length along a fixed direction - that might be useful, but difficult to use.

[chrisb]

The sign is made positive automatically by swapping the endpoints at creation time if necessary, but negative numbers are very well supported.

If it is fixed at creation time the sketch from above should never flip. I will do some tests.

[abdullah]

it should be feasible to completely transfer child attributes to use c++ typesystem.

I tried. Take a look to this:
https://github.com/abdullahtahiriyo/Fre ... 7c37f1ab21

I am facing a problem, that the ChildType::getClassTypeId(); returns type 0. My debugger returns zero even if I evaluate ParaPoint::getClassTypeId().

At first I was thinking that it might relate to the order of initialisation of static data members (getClassTypeId()), but at the position in code where it appears (when adding a line), types should be long initialised.

If the type is zero, then I cannot construct the type.

Code: Select all

template <  typename ChildType,
            typename
>
void ParaObject::tieAttr_Child(UnsafePyHandle<ChildType>& ref, std::string name, bool make, bool required, bool writeOnce)
{
    ChildAttribute tmp;
    tmp.value = &(ref.template upcast<ParaObject>());
    tmp.name = name;
    tmp.type = ChildType::getClassTypeId();
    tmp.make = make;
    tmp.required = required;
    tmp.writeOnce = writeOnce;
    _children.push_back(tmp);
}

[DeepSOIC]

I am facing a problem, that the ChildType::getClassTypeId(); returns type 0. My debugger returns zero even if I evaluate ParaPoint::getClassTypeId().

Yes, I also noticed this problem when I exposed sketcher subsystem as console variable: repr strings were like "BadType object". The types are initialized in AppConstraintSolver.cpp, and the code is run when I import ConstraintSolver. Either I have misplaced the typesystem ::init calls, or it should be explicitly invoked by Sketcher. I will look into it asap.

[abdullah]

I am facing a problem, that the ChildType::getClassTypeId(); returns type 0. My debugger returns zero even if I evaluate ParaPoint::getClassTypeId().

Yes, I also noticed this problem when I exposed sketcher subsystem as console variable: repr strings were like "BadType object". The types are initialized in AppConstraintSolver.cpp, and the code is run when I import ConstraintSolver. Either I have misplaced the typesystem ::init calls, or it should be explicitly invoked by Sketcher. I will look into it asap.

I think the sketcher needs to import ConstraintSolver.

I checked PartDesign and it imports the sketcher in AppPartDesign.cpp. So I imported ConstraintSolver in AppSketcher.cpp.

Now it works. I have pushed it to your branch.

Still, take a look to my modifications to change the type from py type to base type.

With this, the type in tie is gone. I think it is good news.

[DeepSOIC]

awesome, thanks!!