Differences

This shows you the differences between two versions of the page.

--- ai:examples:movingscreens:movingscreens [2018/11/11 17:49] – icke_siegen
+++ ai:examples:movingscreens:movingscreens [2018/12/05 13:57] (current) – icke_siegen
@@ Line 8: / Line 8: @@
 ^ published: | here |
 ^ tested in version: | Ai v8 |
-^ download: |  |
+^ download: | {{ :ai:examples:movingscreens:stagepatch.zip |Stagepatch}}, {{ :ai:examples:movingscreens:models.zip |Models}}\\ The models are distinct as for their UV mapping - make sure to load the correct model into each screen. |
 //Hint: click the images to show them larger.//
@@ Line 26: / Line 26: @@
 Some of the special aspects of this project:
   * it was necessary to mimic the real behaviour of the segments, in order to reproduce it from the position data
-  * something what was completely new to me: we ran into a gimbal lock, and Mr. Dave Green was kind enough to explain this and provide a solution - see tbd. (Euler to Quaternions)
+  * something what was completely new to me: we ran into a gimbal lock, and Mr. Dave Green was kind enough to explain this and provide a solution - see [[#EulerToQuaternion]]
   * the handles of the projectors and of most of the screen fixtures were hidden from the stage construction page, in order to gain overview
   * it is not possible to do a proper softedge on surfaces which can dynamically tilt. Hence it was decided to go for a hardedge, and only some segments were displayed per projector
@@ Line 39: / Line 39: @@
   * [[ai:modules:controller:monitor|]]
   * [[ai:patches:EulerToQuaternion|]]
+  * [[ai:modules:math:formula|]]
+  * [[ai:modules:network:artnetinputlarge|]]
+  * [[ai:modules:patch:patch_io|]]
+  * [[ai:modules:text:notepad|]]
+  * [[ai:modules:math:vector_math|]]
 ===== Stage Patch =====
@@ Line 69: / Line 74: @@
   * top-left, there are some [[ai:modules:controller:constant|constants]] to define the general position: ''X_Pos'', ''Y_Pos'' and ''Z_Pos'' set where the segment generally is (its origin), and ''Susp_Width'' and ''Susp_Height'' let us fine-tune how the segments are rigged (the smaller the suspension distance, the more tilt can be acchieved with a little winch travel)
-  * ''Winde 1-3'' is a subpatch. It takes the global ''Artnet Input'', ''Artnet Universe'' and ''Height''. Also, the IDs of the winches are exposed as inputs and need to be set to match which winch is located where. The patch then takes the Artnet data and calculates the height of each of the three points (left, right, back). These results are then send to the next subpatch ''Calculate''. For an explanation of the calculations [[winde_1-3getting_the_absolute_height_data|see below]].
+  * ''Winde 1-3'' is a subpatch. It takes the global ''Artnet Input'', ''Artnet Universe'' and ''Height''. Also, the IDs of the winches are exposed as inputs and need to be set to match which winch is located where. The patch then takes the Artnet data and calculates the height of each of the three points (left, right, back). These results are then send to the next subpatch ''Calculate''. For an explanation of the calculations [[#winde_1-3getting_the_absolute_height_data|see below]].
-  * ''Calculate'' is the subpatch where the magic happens: from the height data for each point the absolute position and rotation of this segment is calculated. Inputs are the constants defined and the positions from the previous subpatch - outputs are position and rotation (angle) data. For an explanation of the calculations [[:tbd.|see below]].
+  * ''Calculate'' is the subpatch where the magic happens: from the height data for each point the absolute position and rotation of this segment is calculated. Inputs are the constants defined and the positions from the previous subpatch - outputs are position and rotation (angle) data. For an explanation of the calculations [[#calculate|see below]].
   * two [[ai:modules:controller:monitor|]] modules were inserted here only to monitor the computed angels
-  * [[ai:patches:EulerToQuaternion|]] is another subpatch which is [[:tbd.|explained below]]. It converts the computed rotation data to another dimension (Quaternions).
+  * [[ai:patches:EulerToQuaternion|]] is another subpatch which is [[#eulertoquaternion|explained below]]. It converts the computed rotation data to another dimension (Quaternions).
   * ''x_corr'' is a fader to allow for minor corrections of the x position - its value is also sent into the Calculate subpatch
   * finally, bottom-left is the screen fixture for this very segment:
@@ Line 85: / Line 90: @@
 === Winde 1-3: getting the absolute height data ===
+As described above the subpatch ''Winde 1-3'' takes the Artnet dat and returns the absolut heights for the three points. Double-click the module to reveal its contents:
+{{:ai:examples:movingscreens:moving_screens_winde.png?400|Moving screens, subpatch winde}} {{:ai:examples:movingscreens:moving_screens_winde_2x8to16bit.png?300|Moving screens, subpatch winde, sub-subpatch 2x8bit to 16bit}}
+This should be easy to understand - simply read it left-to-right:
+  * the (exposed to the parent patch) [[ai:modules:controller:constant|constants]] take the Id per winch, and based on this, the following [[ai:modules:math:formula|]] modules compute the two channel numbers per winch
+  * the [[ai:modules:network:artnetinputlarge|]] module (with the ''Server Input'' and ''Universe'' ports patched to the [[ai:modules:patch:patch_io|]]) return the Artnet values for the 6 channels in question (here it was decided to get the values normalized, i.e. 0..1)
+  * the ''2x8-Bit to 16-Bit'' subpatch uses a little [[ai:modules:math:vector_math|]] to combine the high and the low channel into one value
+  * of course, for debugging, some [[ai:modules:controller:monitor|]] modules display the results
+  * the [[ai:modules:math:formula|]] modules convert the results to meters (as the winches have a resolution of 1/millimeter), and subtract this from the global height (again from the patch io)
+  * the result is then returned via the patch io
+  * the [[ai:modules:text:notepad|]] simply gives some explanations: '//The winch returns its position in mm. One Artnet digit equals one mm travel. E.g. 1 (hi byte) + 255 (lo byte) gives a travel of 511 mm.//'
+=== Calculate ===
+''Calculate'' is the main subpatch where from the three points' height the position and rotation is computed.
+**Note that this is not exact - honestly I had wished to have someone with a degree in physics to help me with this. However it was close enough to reality to be used on a tour for more than a year.**
+{{:ai:examples:movingscreens:moving_screens_calculate.png?400|Moving screens, calculate position/rotation}} {{:ai:examples:movingscreens:moving_screens_calculate_maxrot.png?250|Moving screens, calculate, subpatch max_rotation}}
+Let's try to explain the logic:
+  * ''highest_front'': the highest front height (from //Left_Abs// and //Right_Abs//)
+  * ''max_rotation'': the max. height difference based on suspension width/height
+  * ''left_real'', ''right_real'': either //Left_Abs// (//Right_Abs//) if this is higher, or (if this is the lower point) the other point's height minus //max_rotation//
+  * ''highest_total'': the greatest height - either from //highest_front//, or //Back_Abs//
+  * ''max_tilt'': right now this directly passes //Susp_Height// but is already a formula module for further tweaking
+  * ''back_real'': the greatest height from either //Back_Abs// (if the back point is the highest) or the highest point from L, R, B, minus the suspension height
+  * ''min_front'': (this is in case B would be the highest point - it was agreed that this would never happen by controlling the travel properly, to prevent the pane from flipping): //back_real// minus //Susp_Height// plus 0.001
+  * ''rotation'': the 'roll', computed from //left_real//, //right_real// and //Susp_Width// -- note that this result is in radiants
+  * ''rotation_grad'': converts the rotation (roll) value to degrees (by multiplying with 180/PI)
+  * ''y_position_front'': either the mid between //left_real// and //right_real//, or //min_front// (if L and R are slack)
+  * ''tilt'': the tilt angle is computed (in radiants) from diff between //back_real//, //y_position_front//, and //Susp_Height//
+  * ''tilt_grad'': by multiplying with 180/PI tilt is converted to degrees. +90 accomodates for rotated models. The result is //x Angle Adjust//
+  * ''x_z_correct'': the amount of correction for the x value, based on the tilt angle
+  * ''x_correct'' is the amount of correction to the x value (how far the model is shifted horizontally). This is computed from //rotation// (roll), //Susp_Height//, //x_z_correct// and //x_correct// which allows to be set from the parent patch
+  * ''x_total'': //X_Pos// and //x_correct// give the total x value (//x Pos Adj//) - this is the left-right-position based on the computed rotation angles
+  * ''y position'': the amount of correction for the y value, based on the computed heights of the front (//y position front//) and back (//back real//)
+  * ''y_total'': //Y_Pos// and //y position// give the total y value (//y Pos Adj//) - this is the top-bottom-position based on the computed rotation angles
+  * ''z_total'': it was planned to add some logic to also correct the z parameter (front-back) - however, here //Z_Pos// is only passed to //z Pos Adj//
+=== EulerToQuaternion ===
+When creating this project I ran into a strange problem: x, y, and z rotation are no independent from each other. I described it like this:
+> in AI, the x and y rotation of a screen fixture refer to the world’s x and y axis. However, z rotation refers to the screen’s z axis. This leads to the situation – with x_rot = -90 – that y_rot and z_rot do exactly the same, but the screen cannot be tilted sideways (what z_rotation does).
+Dave Green was kind enough to give a thorough explanation of this:
+> You have discovered one of the draw backs of the Euler angle system we use in to rotate screens in Ai.  Gimbal Lock.  There is a short video explaining the problem here: https://www.youtube.com/watch?v=zc8b2Jo7mno.  The advantage to using the Euler system for angles is that everybody understands it.  But the trade off is that it has limitations in the form of gimbal lock.
+>
+>So you are probably thinking what can I do to resolve this problem?  Well the simplest option is to have a second version of your model which is 'pre-rotated' by 90' on the x axis.  That will allow your z rotation to function as you expect.  That might not be the solution you need in this case, but it is a common solution to the problem.
+>
+>Another option is to use the alternate skin for the Fixture in the stage patch and then connect to the x,y,z,w Quat ports.  I believe these allow you to rotate the fixture using quaternion rotation.  Only problem is I just tried this and I have no idea what data you need to feed into it.  I know this solves this problem though if you can work out what to feed into it.  Ciaran may be able to elaborate here as he added these ports.  There is a short video explaining quaternion rotation here: https://www.youtube.com/watch?v=SCbpxiCN0U0 you should be able to take some math / trig modules in salvation and replicate the conversion detailed in this video if you are feeling brave ;)
+And while I was still struggling to find my way through all this Ciaran was so kind to create a patch which is now included as system patch:
+>As Dave has said you encounter this problem based on the way Euler angles are defined in Euclidean Space. To get around this we can either use a 4x4 rotation matrix or quaternions. Without getting into the maths too much I have created a patch that should convert your Euler Angles into Quaternions, giving you back full 3 degrees of rotation.
+{{:ai:examples:movingscreens:moving_screens_eulertoquaternion.png?450|Euler To Quaternion}}
+(This concludes the top part - the calculations for the hung models)
+==== Lower part: Mediaspinners, standing on the ground ====
+{{:ai:examples:movingscreens:bottom_mediaspinners.png?450|Mediaspinner Screens}}
+This part is pretty much straight-forward: each one of the six screens which are standing in mediaspinners on the ground is represented by its own screen fixtures so that each one can be loaded its own model (again, distinct by the UV mapping), and can be controlled, as per the y roation, via Artnet from the Mediaspinner controller.
+This is done in a little subpatch: MediaSpinner ArtNet
+=== MediaSpinner ArtNet ===
+{{:ai:examples:movingscreens:mediaspinner_artnet.png?300|Mediaspinner ArtNet subpatch}}
+This subpatch simply allows to set the DMX addresses per mediaspinner - each one takes two DMX channels as 16bit. From the given start address per spinner, the next channel is computed. Then the ''ArtNet Input Large'' gets us the values, which are then being combined to a 16bit value (0...65,535), which is then normalized (0...1) and multiplied by the full travel (450 degrees). The result is returned, and used as y_rotation parameter ''y Angle Adj.'' for the respective spinner.
+==== Bottom: the projector outputs ====
+{{:ai:examples:movingscreens:projectors.png?450|Projector outputs}}
+Finally, at the very bottom of the stagepatch, the projectors are defined. Note that again we didn't use softedge, but assigned each screen to a specific projector - see [[ai:examples:advancedoutputpatch:advancedoutputpatch|]] for details (essentially it is disabling ''Use All Fixtures'' per projector, and patching the screen fixture outputs to the respective inputs).