CGI Data Import & Export

Importing data into motion control from CG or exporting the shot camera move into the CG system is becoming more and more popular and commonplace. Both of these data transfers involve taking a 3 dimensional move from one world into another. They each introduce their own challenges, but are intrinsically simple procedures that Camera Control has done numerous times and we are possibly the most experienced at this of any Motion Control Company.

A write up of some of the issues that can be encountered importing data into CG may be downloaded here. Many of these issues are addressed right here on this web page.

The Data format used by Flair for exporting and importing may be downloaded here.

Some issues are common to both operations and these are:

Scaling

The move in a motion control system is in "real world" space. This means that if the camera starts 4 feet above the floor and ends at 8, that is the data that will be in the file. The CG world scale is totally arbitrary and I have seen doors modeled at 6 units high where the units are centimeters and thus nothing is going to match the real world. So it is vital for both import and export that the modeling be done in actual sensible units. You can use feet, inches or whatever, but the modeled items should be the right size.

Orientation and Translation Offsets

The only real commonality between the CG system and the Motion control system is that Up is Up. Left, Right, Forwards and Backwards are totally dependent on how the models are lined up and how the rails are laid down in the stage. You do have to establish the relative orientation of the axes and some translation offsets that may exist between the systems. (The translation offsets have to do with where 0 is determined to be in the 2 worlds. Often the floor is zero in height, but not always). Both the Orientation and the translation offsets are best resolved by a Line Up or Reference move.

Line Up or Reference Move

A Line Up move is a camera move (real or CG) on an object that will exist in both worlds. For example: If you wanted to shoot a table in the real world and add a CG object to it, you need to know where the table is and how it is oriented up in moco space. If you take the motion control camera and line up the cross hairs onto one corner, and then move across to another corner and export that motion, you can get definite data on where the table is in moco space and this will tell you how to convert it into the world space of the CG Camera. Flair Motion Control software natively works with a target, and a move like this exported with a target, not only gives the camera position, but also where the target is, and the target point can be used to EXACTLY match the 2 worlds together. The size of the move will also be useful for ensuring that the scale between the 2 systems is correct. If you are not using a target system when this data is exported, then you either have to record the data of how far away the target is or use triangulation on each point and this gets more complex.

Lining it up

Of course, a line`up on video or a line up on film only gives you the position of the object on the screen left/right and up/down, it does not give you how far away the object is. If the object appears too small, this can be corrected by moving the camera closer, changing the focal length, or adjusting the image size (gate size). Once you depart from doing something correctly using the exact data you have and start matching by eye, you have abandoned using the data any more and have gone into the realm of match moving. Whilst it is very temping to fudge it around by eye as it will make it look better right away, the moment you do that, you are committed to doing only that. Using the target distance in the flair system and importing/exporting this data, you can get the exact distance that the camera is supposed to be from the object and so make sure your line up is perfect. Note that the distance from a camera to an object in the CG world is almost always from the front nodal point of the lens - and so is it with a real camera. Flair will automatically convert a nodal distance into a focus distance when the lens is correctly set up.

CGI Import

Importing a camera move from the Motion Control system is in itself relatively simple. Numerous scripts, plug-ins etc have been written and this task is usually the simplest. Once you have the move in the CG system, making it match the footage shot is an entirely different job and one this it often believed to just fall into place if only the data could come in. There is no substitute for being on set and seeing what is happening for making sure you have a fair chance of getting it all to work out. You can also make sure that the lens data is correctly recorded as well as ensuring that there is a bloop light somewhere in frame that will wind up on the transferred footage.

Line up for Import

For every series of shots from one track placement, you should insist that the Motion Control Operator be given time to record a line up move of some sort, and also insist that he gives you the data on set if possible. The line up move must be recorded on a object that makes sense. Here you will often be able to assist in making sure that a suitable object is chosen and knowing how the line up is done will assist in getting it all sorted out. Once you have the line up move into the CG package, you can see where it is in relation to the actual CG object that it is supposed to match. If you ONLY rotate about the vertical axis, and adjust XYZ translations until it lines up you will then have the exact values to apply to the Motion Control Move. Of course if the scale is wrong on the object, and it cannot be made to match, then you MUST find out why, not just scale to correct as there may be some other error that you are not accounting for, and this may throw the motion control move off.

Matching the images

So the move is imported and adjusted so that it is correctly lined up and offset, but the images do not match. What has gone wrong? Well the most common problem at this point has to do with focal length of lenses and the image size. Presumably, you have set the focal length of the lens correctly, but the aperture size really depends on HOW the film was transferred or telecined. A standard 35mm film gate full aperture is .981 by .735 inches. If the telecine cropped any of this, then that will affect how the image looks. If they have not centred the transfer then you can get a pan or tilt offset that will make it all look very strange. The secret here is to find out what was done and correct for the errors, not guess at it. Often in the CG package, you can set the gate size to however the transfer was done and fix that. A pan or tilt offset is another problem, and you should always insist that the image is transferred centred.

HD Cameras all seem to have different image sizes and the format you are recording will also sample different areas from the actual chip. It is VITAL to find out the size of the chip and the image scanning used to ensure your gate in CG matches what was really used. We warned, you will often be told is it a"2/3" chip. This is not accurate enough, you need actual mm or inch dimensions to make it work.

Once you have removed all the errors and accounted for any offsets, the images should match well. If they are right at the beginning and the end and drift badly in the middle, maybe there is a speed issue or you have not got the right start (bloop?) point. Otherwise if it is close but seems to drift a bit, then you have to determine if this is as good as it gets and track it in or if there is some other error that needs to be fixed. This is a matter of experience and judgment. The real world is never perfect, the rig's position is going to be very close to the reported position, but mechanical arms do bend under load and lenses often have some alignment or spherical aberrations. Do note that generally, lens aberrations will throw the image off more the further you get from the middle of the image. If the image matches well in the middle, then it may be just lens aberration.

Zoom Lenses

Please do not use a zoom lens unless you really have to. They do not model well and the nodal point moves when you zoom, so it adds a whole extra complexity. You have been warned! If you must use a zoom, then it makes sense to repeat the motion of the zoom lens only on a grid and use that to model the lens and also if you get a chance, run the move once without the zoom and use that for tracking then add the zoom after. This is often not possible in the time available, but if you get the chance...

CGI Export

CGI Export is the easier of the 2 processes (at least for the CG artist) and the major concern is to make sure that both the reference move as described above and the camera move are exported in world space, not relative to a moving parent object. This can be done in most CG packages, but it does vary. It is also important that you notify Camera Control of the units you are using just in case this needs to be accounted for. The easiest way to get the data out of a CG package is via Maya(tm) since the MEL script automatically adjusts axes and units to ensure the process is as simple as possible. If this is not possible, then if you can get the camera and reference move out into Ascii, we can import it somehow.

Accelerations & speeds

Once the move is imported into the Motion Control system, there remains the question "Can rig can actually run the move?. Mostly likely you will have some idea as to how fast the rig you are using can move as well as its range of travel, but the hardest thing to see is the acceleration needed to get the camera to move like that. Whilst a CG camera can change speed infinitely quickly, and even an abrupt change of speed is not entirely noticeable to the eye, a 1200lb Milo needs a little more time to respond. CG Systems often use cubic curves which are smooth and join smoothly, but do not necessarily meet with matching accelerations, so you can get sudden accelerations where these curves meet, and a sudden acceleration means a sudden force which means camera shake - don't blame me, it's Newton's fault. Basically, try to get the curves to be as smooth as possible and try exporting the data before the shoot and have it tested. A motion control rig also can not start instantaneously. If your move starts at speed, it is often a good idea to build on a ramp move to start and stop the camera smoothly, even if this part of the shot is not going to be used. This is not vital but can make the import process a little easier.

Guide for the move

Moves imported into Flair for match moving often have a lot of jitter in them from the tracking software. This is not really perceptible in the CG system, but once you put the motion into a real camera, it becomes very shaky. In my experience this data often has to be smoothed a lot before it can run at live action speed, and for this reason, the match move data is not going to be frame perfect, but will give a very close approximation which can often be tracked in to make a perfect match. Moves programmed in CG and then exported to Flair are often delivered with the message "This is the approved move - do it exactly like this" Alas this is very often not the case, more often than not something was not modeled exactly right and so the framing won't look quite perfect and will have to be adjusted. It is better to simply sample the imported move every 12-24 frames and then adjust these few points rather than try to adjust discrete data for every frame.

Line up for Export

The line up move for exporting will really depend on what the move is all about. If there is no obvious thing to use as a line up, contact Camera Control and we can work something out. Even if it is to model an apple box in the CG package and use that as a line up. Of course, bigger is better with line up moves try to use something at least 4 feet in width. A vertical line up will not provide the rotational factor, so make sure your line up move has a significant horizontal element.

Zoom Lenses

Please do not use a zoom lens unless you really have to. They do not model well and the nodal point moves when you zoom, so it adds a whole extra complexity. If you do have to use a zoom, be prepared for a little extra work in post. Be sure to run the move without the zoom moving and run the zoom more without the rig moving if you really want to work out the zoom issues which also include not zooming on centre and other abberations

If you have any questions about Import or Exporting moves please feel free to contact Simon Wakley at Camera Control (310) 581 8343 or email simon at cameracontrol.com

MEL Script

A MEL script is available for customers of Camera Control Inc to facilitate import and export of data to and from Maya(tm). The MEL script has been developed over several years and is fully featured. The script is easy to use and converts between Maya camera move data and Flair standard data files for easy import and export. The Script is supported by the writer of Flair software/CCI Lead Operator Simon Wakley and so full technical support is right at hand.

It has an interface similar to the existing Flair Import/Export interface and will import and export Single node Camera, as well as the standard 2 node Flair Camera (Camera and Target) as well as the advanced Maya 3 Node camera (Camera, Target & Up) which greatly facilitates moves that go over the top of objects and also any world space rotations that affect the horizon. - No other Motion Control rig or interface supports these advanced features (Used on Aviator movie and NetZero commercials).