A Special Type Of Parenting? Transforms - Clutches

Questions
1

Withdrawn: Writing out the problem made me realise the solution - whoops sorry, it seems obvious now with hindsight I was just not thinking about it the right way - I was fixated about my current top level parents remaining top level.

The answer is to add another level of hierarchy - a new parent one level higher and through the software to provide for or allow all types of transform apart from rotation about a nonimated (common) axis.

The children of this additional level then would typically coded to only allow for rotation about the nominated (common) axis.

So if you want to transform the whole assembly you choose the new top level parent as your ā€œhandleā€ but if you want to spin different components around the common axis at different speeds or by different amounts then your ā€œhandleā€ is that component but the software only provides access to "rotation about Z.

The top level parent holds the assembly together, the children are responsible for their own rotations about the axis.

===========================================================

Hi

I wondered if anyone had suggestions how to mimic the usual babylon parent child relationship with respect to transforms with one special caveat - not all transforms of the parent affect the child.

A classic example would be a simplified clutch mechanism in an engine transmission - the drive plate or fly wheel and clutch plate travel everywhere together, changes in position and orientation but the drive plate may sometimes be spinning about its axis whilst the clutch plate is freewheeling at a slower speed or even not spinning at all - however the assembly as a whole might be simultaneously traveling along at great speed with changes of direction and orientation.

Its a common situation in machinery - all transforms, both translation and rotation would be applied to child except perhaps rotation on the Z axis where the relationship between parent and child might be governed by other factors.

Basically I want to pick up all translations for the child except rotation about their common axis ( say local Z which stays aligned with the parts ) - the parent is under direct control of the user, if the user moves the parent they expect the whole assembly to move, if they rotate in X or Y then they expect the child to follow - its only rotation in Z where they expect the child to ignore what the parent is doing.

Engineers generalise the concept of clutch to both linear and rotation cases, it boils down to ā€œI will copy everything you do apart from displacement in this direction or rotation about this axis - then I will do something differentā€ - also found in various types of linkage where components share a common axle and so are partially constrained but can act independently otherwise.

I have ideas for how to go about this - either a post process that restores the child as intended (child counter rotates), basically backing off some of the applied transformation or to avoid the standard parent-child option and to implement a bespoke process that monitors the set of meshes of interest and maintains the desired relationships.

I just wanted to see if anyone had looked at similar requirements and come to any neat ways of going about this.

thanksā€¦

2

When transformation A is to be applied to the parent and transformation B is to be applied to the child

parent transform A
child transform B

Something like this? Babylon.js Playground

3

Hi John

Yes but the clutch scenario would require that if I rotated the largest box about the common axes of all the boxes then the children would not rotate. However any other type of transform I applied to the larger box would result in a similar transform in the child boxes, the boxes would move and act in ā€˜formationā€™ keeping their relative positions with respect to one another intact in all aspects except rotation about a specific axis of rotation - their common axis if you like.

Seen from a certain perspective it means a kind of filtering on the parent child relationship so that only certain types of transformation are propagated but I suspect that in practise it will be necessary to have a post-process to selectively undo some of the transformation on the child rather than to stop it happening - or alternatively not to use the babylon parent-child relationship for this special instance and write bespoke code instead.

One solution I could implement in my code is a callback that checks for a certain type of rotation on the parent and so performs a counter rotation on the child to undo the rotation preserving the rest of the inherited changes. This method exploits the existing parent-child relationship functionality but then undoes the unwanted component of transformation.

Another solution is not to use the Babylon child parent relationship - but to use bespoke code and callbacks to ensure that each mesh in a selected sug-group of meshes is transformed whenever the other is transformed except when that transform is rotation about (say Z) in which case the transform is not propagated to the other meshes in that special group.

I am interested to know if anyone has looked at this type of situation before and if there are any neat(er) ways of doing this, I thought it was worth a mention since this is such a common situation in engineering. I guess you could say I am raising the topic as a talking point rather than a problem since I believe solutions exist, its just whether more elegant ones exist instead of the sledgehammer approaches that I have suggested.

I wonder for instance whether the architecture of Babylon would be capable of supporting filters on parent-child transformational relationships.

4

A rough and ready approach https://www.babylonjs-playground.com/#2713PF#1

Oops missed you edit when doing the PG

1 Like
5

Hi John - thanks, sorry for your time, unfortunately it seems sometimes that the solution only pops out when you write it all down.

1 Like