[kalthans]

i think the single biggest improvement in particles will come when there are some built-in capabilities for varying particles that are textured with a clip. currently if you map squares with a clip all the squares will update with the progression of the clip…regardless of how long they have been alive. two suggested changes would be:

#1 add a parameter or particle modifier that allowed for the texture source clip to be referenced from varying start points or frames….this would allow you to add a bit of variety by effectively slipping each particles texture. in a perfect world this would be a dynamic value that could be animated or controlled with an expression.

#2 add a function that allows the particle system to reference a given set of clips (say a reel called “particle_source”) randomly. this would allow you to have many different types of particles within the same emitter (different bits of debris, differnt types of leaves, etc). this would have the added benefit of being able to effectively take advantage of particle sorting (currently particle emitters don’t obey each other’s sorting, so you if try to add variety by adding many emitters you often get zbuffer issues).

IMHO this is a very simple function and one that could add tremendous flexibility and value to the particle system.

[kalthans]

jeff

bringing in an experienced moco op will be key…they have workflows that allow transparent integration with live action crews…all they need is an electrical outlet and 5 min to zero the head they they are in business…they just sit back and hit “record” and capture the data from the head in a series of data files.

i’d still give joe over at general lift a call…they have some really sexy and easy to use heads (encoda cam, etc) already set up for this kinda thing

again, good luck…. let me know how the shoot and kuper-to-inferno data path works out

k

[kalthans]

well, i assume you’re talking about a Kuper system

are you talking about using a moco driven head (programmed) or a loose head that is just encoded and recorded to the kuper system?

either way, first you need to make sure the head axes are calibrated properly so that the data generated by the kuper is meaningful.

then, you’ll need to make note of the nodal offset of the film plane from the center of the head’s rotational axes (pan, tilt). this data will help you later when you set up your worldspace in 3d and/or flame. unless you are working with a very heavy studio rig the likelyhood of the film plane being nodal to the center of pan+tilt is virtually nil

from there it’s just a matter of exporting the data from kuper as an ascii file file that lists the absolute rotational position of the pan + tilt axes during the move…what’ you’ll get is essentially a list of keyframes and values for EVERY frame of film(video) that is shot. you’ll be able to get this data no matter if the move is being programmed to run off of a moco head or just encoded from a live head.

as for timecode, i’ve never generated timecode simultaneously before…i’ve always used the data raw and synched it up to the framemarker at the head of the shot (kuper systems have a bloop light that fires at a first frame of the move so you can do this visually)

you may want to talk to joe lewis over at general lift (http://www.general-lift.com/)…they have some awesome tools for doing just this type of stuff…they’ve figured it ALL out and their stuff is very portable and robust.

good luck

k

[kalthans]

what app are you talking about? ffi/fs?

in flame i find it easiest to copy point animation on a surface to another image by duplicating the image with the animation then APPLYing another layer to that image

[kalthans]

hi carlos

i’m sorry i did not see this post sooner or i would have replied.

i was a motion control cameraman for some years and might be able to shed some light on your situation.

while the underlying concept of motion control is very simple, the level of integration required for good film work is quite sophisticated and not to be ventured into lightly. one man, Bill Thomas of Kuper Controls has pretty much devoted his career to developing software just for this purpose.

if all you are looking for is a “diagram” then i’m afraid very few resources exist….all of the motion control systems out there are either custom built or of a proprietary nature (Mechanical Concepts, General Lift, Tiffen, Sorensen and Mark Roberts all have excellent and well engineered rigs). my best suggestion would be to figure out what you need moco for then try and design a simple rig to accomplish only the tasks you need (i.e. pan/tilt only or pan/track, etc).

you can find TONS (literally: TONS) of used moco gear on the secondary market: swap meets, manufacturing closeouts, ebay, etc…. this includes linear slides, bearings, rotators, motors, drivers and ballscrews. if you or somebody you know has a bit of mechanical prowess you can frankenstein these surplus/used parts into a very servicable motion control rig.

as for the software to control it there is really only one choice, the RTMC cards from Kuper Controls and the software that goes with it. they sell for a variety of prices depending on the number of axes you need. my guess is that Bill would probably sell an older RTMC card with 16 axes for around $1500 or less. it’s been awhile since i bought mine so i’m not current with the prices (plus he’s come out with a few updated products in recent years which might have driven down the price of older cards).

his software is the industry standard and contains all of the bells and whistles you need to correctly interface a film/video camera into a motion control system.

so, to recap here’s the design/hardware/software “diagram”

the software runs on a PC…..the PC has a dedicated hardware card that generates a set of signals (step&direction) that tell motors when to move…..these signals go into what are called drivers (basically powersupplies for stepper motors), these drivers convert the digital signals into the correct power phase for steppers to operate…..the drivers send power to the stepper motors and the motors move in discreet increments…..the motors are hooked up to either linear (track, lift, boom) or rotary (pan, tilt, swing) actuators which move your motion control system around. the camera is a special case which is handled as a special rotary axis by the software to take into account shutter phase, framerate, etc.

if you’d like more info including contact info for the vendors i’ve listed feel free to contact me off-list.

good luck

yours

k

[kalthans]

the new version of Flame (v8.0) which is due out any day now will have selective motion blur per layer in Action that you can toggle on/off (as well as on/off for geometries).

if you can’t wait for it or won’t be upgrading you might try this for certain types of comps:

once you’ve got your comp like you want it go ahead and load up that Action node in Batch and make a bunch of copies and string them together. then, hide all but one layer in each Action node (remember to pipe the MatteOut for each layer). you can then turn on motion blur on only the Action nodes that matter and leave them off on the ones that don’t.

again, this only works for certain types of comps…but can save a bit of rendering time in the long run

good luck

[Author]

Posts