Federgraph

Federgraph is intended to become a community driven project.
This page may be a starting point for your participation.

Federgraph uses springs as components in its physical model.
One end of each spring is attached to a coordinate in 3D space.
All springs are connected to each other in point (x, y, 0).
The connection point is 'moved' in the plane z=0.
The force necessary to move the point is computed and plotted.
The force is a vector, which has a length/amount (Betrag) and a direction (Richtung).
Federgraph will raster over the (x, y) plane and plot Betrag or Richtung as a function z = f(x, y).
Federgraph will also plot the energy (Energie) that is contained in the system.
Start with Betrag, Richtung and Energie.
This will give nice images to look at.
Even if the model is simple, you can discover a lot.

A great scene to start with uses three springs and arranges them in a equal sided triangle for
ultimate symmetry. The coordinates of the springs are in plane z=0, around the origin.
The Federkennline of the springs will be linear with a notation like F1 = k1 * (l-l1);
where l1 is the length of spring 1 when F1 is zero and k1 is not.
Length l is a computed value, the actual length of the spring, which changes as you move point (x, y).

Feel free to implement Federgraph in any programming language you like.
Federgraph is present on the social net and will be happy to share the great images you produce
and the great interpretations of the things you discover.

In the following sections I will specify some details that should be the same across all implementations of
Federgraph. The specification is a draft. It will change until it has finalized. Your comments are welcome.

Using the mouse

Drag with left mouse button down to rotate the 3D figure around the horizontal and vertical axis.
Drag with right mouse button down to rotate around the z axis.
Use Ctrl scroll wheel to zoom in or out (move camera z position).

Use the scroll wheel of the mouse to adjust the value of the selected parameter of the model,
by default in large steps of 10 or -10.
Use shift scroll wheel to change the selected parameter in small steps (1 or -1).

Update: Small change and large change (+/-1 and +/-10) have been swapped around numerous times.
The last thing I found was that the Microsoft Suface Dial out of the box (in scrolling mode) will work better when it corresponds to small change.
Please try it out in the app. The 'documentation' may be out of sync.

You see, I have given top priority (scroll wheel without Ctrl or Shift) to
changing the current model parameter,
because this is what the application is all about.

Using the touch screen

On all 4 sides, the empty area between the square buttons is sensible to touch similar to a trackbar/scrollbar.

The top trackbar will rotate around z axis.

The bottom trackbar will zoom in and out.

The left trackbar will increment/decrement the parameter value by 1.

The right trackbar will increment/decrement the parameter value by 10.

Note that zoom and rotation around z axis are not implemented by the usual gestures as you may expect.
Instead, the center area of the application window is reserved to control the important rotations of the 3D model around x and y axis.
(Use one finger very similar to a mouse move on the desktop.)

Pan has not been implemented in the touch screen version yet,
because it would be too easy to rotate the model out of sight,
once you have panned it out of the center.
(On the desktop, Ctrl left button mouse move can be used for panning.)

Note that the desktop application uses the scroll wheel of the mouse as the
preferred control to change parameters of the model.
On the touch screen device, the vertical track bars take over that task.
Move the invisible thumb of the trackbar/scrollbar slowly while you watch the text labels
that show the current and actual parameter value.

Changing parameter values is a costly operation that is timed.
This means that the frequency of it happening is limited.
If you scroll faster on the trackbar, then it does not update the model more often.

Also pay attention to the amount of detail in the image (32, 64, 128, 512, 1024).
The number of vertices computed in the image will be square (of that number).
Use a lower resolution like 64 while you are adjusting the parameters.
Only when you want to look at the 'final' image would you want to increase the number of vertices to a higher value.
This may vary depending on the computing power of your device.
High resolution images slow things down, you will quickly notice that.
Some skill on your part is required to bring out the full potential of the application.
This is part of the 'game'.

The mouse wheel would give you tactile feedback,
so you can conveniently increment the value in small and large increments using the mouse.
Given that it is not quite so convenient with the virtual trackbar on the touch screen device,
remember to move your finger slowly and keep watching the value in the text label while you scroll.

Using the horizontal track bars for rotation about z and zoom is intuitive, because the operation is fast and it is not timed.
Try it out once and you know it. Only the vertical track bars need special attention.
The skill you develop using them is key to using the App on the touch screen device.

Learning how to use the application is perhaps easier on the desktop,
but using it is as much fun on the touch device.
The touch experience may be further improved in the future as I learn how to do it best.

Smiling is hard, but I keep trying.

Using the keyboard

I have already run out of keys, but found the mapping below useful.
I recommend to reserve the following keys for the important features.
Use keys that I have left blank for your own set of features.
(I will not hit those when I get a chance to test your implementation.)

The data format

An example for the data format is given below.
Several formats have been implemented.
Look at the 'reference application' to see the data as it is output to the multiline edit control or put into the
clipboard.
It should be plain text.
It should be possible to return the data from a web server, store it in files or hide it in a field of a database.
The Text should be encoded as UTF-8 but will look like Ascii/Ansi.
All values on the right side of the key=value pairs are numbers.
Write out the floating point values locale independent with a point as decimal separator.
Applications should be able to parse the java properties style or the Pascal style.

The Pascal style is useful when you want to copy and paste a sample from the TMemo to the
source code editor of the Delphi IDE
to improve a built in sample.

To the left of the equal sign there is the 'Key'.
The definition of the key will be available in source form.
To the right of the equal sign is the 'Value', an Integer value.
Floating point values and Boolean values will be mapped to an Integer.
A float (single or double) will have 2 digits after the decimal point (scaled by 100).

Navigation among built in samples

Navigate to the built in samples with the arrow keys.
On a touch screen, tap on S+ or S- buttons.

The application should have a small number of built in samples. The user should think of a matrix of samples.
Samples are organized in rows (hubs), columns (samples) and levels.
Hubs can have a different number of samples, but no more than a maximum specified.
If a hub does not have enough samples it should 'inherit' the missing samples from the default hub, which must have
a full set of samples. Such the user will be able to navigate the matrix of samples.

(It should be easy to replace the built in default sample data by external data that you load
from somewhere at runtime.)

Animations

View rotations around the screen x or y axis will get a reserved key binding.
Starting/stopping of a transition between the current sample and another (the next) will get a standard key binding,
and be available if implemented. (The next sample may be sent to the program from a remote client.)