jamesthomasgriffin / parametrisedtransforms

A small template header library for parametrised transforms, with examples for Dear ImGui

NB

I thought this was neat enough to develop further, so have started from scratch with a different model for the transformation stack and a different focus, only on matrix transformations. The new code is far more efficient and will be available soon, it will be called ImControl.

ParametrisedTransforms

A small template header library for parametrised transforms, with examples for Dear ImGui.

Read the source files for documentation. To run the demos start with your chosen Dear ImGui implementation example and call each of the three declared functions immediately before or after the ShowDemo function call.

If you have any questions about the code then please contact me or raise an issue. Furthermore if you have any suggestions for transforms you want included then again raise an issue. Contributions to the code are of course welcome.

You may notice some strange behaviour when dragging certain control points around. This is probably a result of the underlying geometry, the simplest way to mitigate such issues is to restrict the domain of the parameters.

Tests

There are some tests I used when developing the transforms, they check that the transforms do what I expected them to do and they perform a numerical check of the hard-coded formal derivatives. To run them you need to link the glm library and the googletest library.

parametrisedtransforms's Issues

Remove use of std library

The std library is currently used for the vector of transforms and for shared_ptr.

The code relying on std::vector can at least go in a separate header file and IM_VECTOR can be used for the ImGui code.

The code relying on std::shared_ptr is to allow for ownership of polymorphic types and the is no IM_ equivalent. This dependence would be removed by enacting the suggested change in Issue #2, where the objects are not owned, instead a stack of matrices and derivatives is recorded.

Select and drag multiple control points

Desired use case: user either shift-clicks or drags a box around control points, then the user drags all of these points together. This is more complicated than dragging all points individually because the control points will be dependent on the same parameters, thus it is not correct to just drag all points individually as one might expect.

Thoughts on implementation

• Only one control point can be active at any one time, so within a single DraggableView we will need to keep a vector of ids. Implementing a draggable box means this list is never edited so it may be easiest to implement this first.
• For moving the points we minimize the sum of squared distances between where the points are and where they should be. This requires summing the derivatives and second derivatives of each individual squared distance function, with respect to all involved derivatives, then applying the conjugate gradient method.
• Dragging a box occurs only after individual control points have been tested for interactions, then testing for control points being within the box will happen in subsequent frames. Moving only happens after the box is released. Hence the operations of selection and dragging are entirely separate.
• Selection should be allowed programmatically so for example dragging a single point could result in dragging multiple points.

Remember where the user first clicks when dragging

At the moment when dragging a ControlPoint, the centre of the control point is moved to the mouse cursor.

Instead one could record the position of the mouse cursor in the coordinates of the control point itself and use this as the anchor point. It is not enough to remember the offset of the mouse from the centre of the control point because the control point could get bigger / smaller.

This behaviour should be optional with a suitable flag.

Demos of library in action

A very simple arm which can be dragged with the mouse cursor.

Computational complexity (and possible optimisation for ImGui code)

Some general thoughts and possible change

A stack of transformations is contructed per-frame and when a value or (second) derivative is required at a particular point the whole stack is traversed. So the complexity is O(n^2). When the positions at which values/derivatives are required are not known in advance, this is the best we can do. If all transformations are matrix transformations then there is the possibility of computing the transformation and derivatives for all possible parameters as the stack is being built, however the number of second derivatives could also grow as n^2 so unless the number of parameters is known to be << n the complexity of this approach is n^3.

On the other hand if we do know the positions to be computed and the variables that need to be differentiated against in advance then these can be computed as the stack is built and the complexity is linear in n.

Application to ImGui code

The second derivatives are only used for moving an activate point which is not activated, this means the point is unique and the parameters are changed from the second frame that it is active for. The reason for this is to allow for z-ordering when control points are overlapping. As a result we know in advance the position of the control point (lagging by one frame if it moves) and the variables associated to it (from the previous frame). These variables can be differentiated against as the stack is constructed.

The first derivatives are only used for the unique active control point and when plotting derivatives, these could be requested for the next frame rather than supplied at the call. However the values of the current transformation are required for each control point whether active or not. Storing every control point position for the next frame is feasable but increases the complexity to O(n^2) again.

If we now restrict to transformations which can be represented by 4x4 matrices then it is no longer necessary to store every point as the current matrix representations and the required derivatives can be stored in the stack. This restriction does not affect any of the ImGui style calls currently implemented. There is an implicit x ---> x / x.w at the end of the stack, but this can be handled separately.