Big merge day

Discussion about the development of the Assembly workbench.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Big merge day

Postby jriegel » Tue Jun 18, 2013 10:33 pm

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...
Stop whining - start coding!
triplus
Posts: 9475
Joined: Mon Dec 12, 2011 4:45 pm

Re: Big merge day

Postby triplus » Tue Jun 18, 2013 10:38 pm

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. :ugeek:
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Big merge day

Postby ickby » Wed Jun 19, 2013 4:35 pm

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
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Big merge day

Postby jriegel » Fri Jun 21, 2013 10:29 am

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.
Stop whining - start coding!
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Big merge day

Postby ickby » Fri Jun 21, 2013 2:21 pm

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 :) )
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Big merge day

Postby jriegel » Fri Jun 21, 2013 4:37 pm

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...
Stop whining - start coding!
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: Big merge day

Postby NormandC » Sat Jun 22, 2013 6:50 pm

jriegel wrote:* 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? :shock: :D
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Big merge day

Postby ickby » Sun Jun 23, 2013 10:22 am

I implemented some simplifications in my branch which address the user experience issues we discussed (more expected results), feel free to pull it.
User avatar
jriegel
Site Admin
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Big merge day

Postby jriegel » Sun Jun 23, 2013 8:52 pm

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!
Stop whining - start coding!
ickby
Posts: 2982
Joined: Wed Oct 05, 2011 7:36 am

Re: Big merge day

Postby ickby » Wed Jul 31, 2013 2:17 pm

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?