All these angles result in the same rotation when applied to a transformation of a particle.

Maybe you would then just say to yourself: "Ok then, let's just use rotations from 0° to 360°". However sometimes it is very usefull to know that e.g. 353° and 7° are in fact very near together.

This is more obvious when you just compare the two angles 353° and 360°+7°=367°

  
  367° - 353° = 14°
  

When you compare these values by subtracting them from each other you see that they are just 14° apart from each other.

Just keep in mind that angles of any degree make sense (not only those between 0° and 360°) and are valuable to work with (like 367° in our case). We will make benefit from that later.

these angles all result in the same rotation:

 0° = 0 cycles
 360° = 1 cycle
 720° = 2 cylces

these angles result in different rotations:

 90° = 0.25 cycles
 180° = 0.5 cycles
 270° = 0.75 cycles

Again: When thinking of an object rotated by a certain angle, we at first aren't interested in the cyclecount of that angle, because adding or subtracting full cylces have no influence on the rotation. But we are only interested in the Fraction of a full cycle.

To get the fraction of an angle in vvvv, use the Frac (Value). The Whole Part will give you the full clycles, the Real Part will give you the fraction of a full cycle.

To check equality of two angles use the = (Value Cyclic).

And with filter nodes i mean:

• Damper
• LinearFilter
• Newton
• Oscillator
• DeNiro

A more mathematical approach to say the same:
With the cyclic pin you can change the toplogy of the space filters are acting in.
They act in linear space (Cyclic Pin OFF) or in cyclic space (Cyclic Pin ON).

Note that even if you plan to use just angles between 0...1, the cyclic pin will be your friend. The filters just know that angles of 0.01 and 0.99 are very near to each other...

Again, all these different angles still have their right to coexist with us, but in a static snapshot you wouldn't be able to see a difference.

We had this topic already with a factor of 360°. And we were only concerned about the fraction of full cycles.
Let's try to extend that lazy cyclic behavior to fractions of half cycles or quarter cycles.

Now lets say, we want to a have a most lazy animated quad.

We again use a cyclic damper for that. But if it is rotated about 30° and it should go to 90°, in fact it should decide to rotate to 0°, because it will result in the same appearance like if it would rotate to 90°, but 0° is nearer to 30° than the specified 90°...

The filter nodes however can only handle a cyclic mode with full cycles. So since there is no pin at our damper for specifying a quarter cycle, we have to trick a little bit: Lets use map nodes so that the damper treats quarter cycles as full cycles, does its cyclic animation, and after that use the full cycles of the damper and map them back to quarter cycles.

• we think of our values as related to quarter cycles (0..0.25)
• the damper needs values related to full cycles (0..1)
• > map 0..0.25 to 0..1

• > damper on full cycles

• we need our original value range back
• > map back 0..1 to 0...25

It is used in here: Draw.

  divide by 360

To convert vvvv angles into Degrees:

  multiply by 360

To convert Radians into vvvv angles:

  divide by 2*Pi

To convert vvvv angles into Radians:

  multiply by 2*Pi

To convert Radians into Degrees:

  map the values from 0...2*Pi to 0...360 (map node)

To convert Degrees into Radians:

  map the values from 0...360 to 0...2*Pi (map node)

In some special low level nodes, which are really thought to be direct implementations of math functions, we decided to use the unit radian (rad on your calculator), because this is the unit which is used in most other languages as well. In this way it is easier to implement algorithms which are already formulated in a peace of code (in one of these typical textual languages).