Big merge day

[jriegel]

Today I merged jreinlaenders and ickbies branch into my assembly development branch.
Both of the guys did amazing work.

The Body works already good and one can test the 3D constraint solver.

I will now start to iron out some stuff.

* We have to test the impact on old PartDesign project (some kind of migration scripts)
* Task Watcher for Assembly
* First simple move tool in Assembly to move Parts by hand

After minor polishing I think we can do a crash landing in master...

[triplus]

Fantastic! I played around a bit with stuff jrheinlaender is doing because he provided PPA but once all this things land in master (daily PPA) then the fun begins.

[ickby]

About the move tool: I'm trying to get this weekend around implementing a drag/move functionality into the assembly solver (basicly just adopting logari81's code). So please consider a interface of the move tool with the constraints system while implementing so that integration will be easy. The solver move code will be very easy: construct the system the same way as now, just instead of

Code: Select all

solver->solve()

you can do

Code: Select all

boost::shared_ptr<Geometry3d> geom = ...; //the geometry which is dragged or should be moved
boost::shared_ptr<Part3d> part = ...; //alternatve is to move a complete part, works the same way as with geometry
solver->startMove(geom);
solver->solve();
geom->set(); //set updated value
solver->solve();
solver->move(dx,dy,dz); //alternative single command, no need for geom->set and solve
... and so on, can be done every mouse move
solver->endMove(); //finish moving

[jriegel]

Ok, but normally you don't want to have the solver in play when you move.

Often you move unconstrained stuff in a close position, so you can decide where to place the constraint.
Also I use the move tool often to move some parts out of an constraint system to get a better view.
Then later I press recalculate and all falls in place again.

But moving with solver on, has maybe also some use cases, so I will surly incorporate it...

At the moment I would have an other wish to the solver.
If you construct some parts they are most likely proper aligned to the main axis.
At the moment the solver nearly always rotate the parts, even if not necessary.

So I would wish the solver first to try to solve without touching the rotation. Only after that fails using the rotation.
In the best case the solver also tries to use sane angles like 90° 180° or 45°
I think that will lead in 99% of the use cases to a better result.

[ickby]

Ok, never thought of that usecase for moving parts. I mainly use it to test the relations of the parts to each other. But we can provide two tools or allow the user to decide if he wants to acknowlage constraints or not.

About the rotation: I know the issue. However, there are two points to it: First it's not trival to only solve for translations or rotations as all constraints have both as parameter in their equation, it's not possible to seperate both into seperate constraints. I have ideaas how to do it, but it's quite some work. Second, to handle the non-metric parameter space of a assembly system I had to implement some funky scaling algorithm and therefore rotations will nearly always rotate not around the parts origin but around some other point. Therefore even if I would seperate both, the result might not be as expected (for the case a simple translation is not enough).

To solve this in a userfriendly way a lot more is needed, and even if the infrastructure is mainly there it will take a long time to implement it. But a separation might result at least in a bit more expected results. I think about it ( I always prefere to design for the most general case, sometimes I need to be pushed for the obvious things )

[jriegel]

Actually your solver will sure work, but will force to fix all open degrees of freedom. In Catia e.g. you have only to set the minimal constraints and the rest will be left untouched. Both work, but the later is more work for the user
But first we have to role out Assembly, polishing comes later! And your solver is easily in a stage to role it out.

I think I will do some adjustments to make it easier. E.g. distance between faces needs always a automatic parallel to make sense, and so on...

[NormandC]

* First simple move tool in Assembly to move Parts by hand

Silly question,

There's already a "Transform" tool (when double-clicking on a shape in the tree) that brings up some gizmo that allows you to translate and rotate an object. Why can't you use it rather than code a new utility? The possibility or rotating the part would also be useful as it would allow to orientate it in a rough general position prior to applying the constraints.

Are you really planning to make this big merge soon?

[ickby]

I implemented some simplifications in my branch which address the user experience issues we discussed (more expected results), feel free to pull it.

[jriegel]

Hi Norm,
thats actually a good idea. I was planing to use the pre-selection to move along a face or edge, but the transform dragger will do for the beginning. What I for sure want to implement is a dialog which give you control over the transformation (editing and grid snap).

@ickby
great! I will pull it and take a look!

[ickby]

Hello jriegel,

I propose to merge the dev-assembly into the master branch with the current code status (jreihnländers and my branchs newest versions should be integrated). I think it's important to start some serious testing and that will only happen in master. Even if the code is unstable not not fully functional and many things are still missing: it's a developper version, it's ok if it is broken now and then

Of course only if you find the time, no pressure intended! What do you think?