Moving Light tracking motion with Touch, pls help!

Hi groupies,

I am a beginner in TD, only used it a few times for Kinect simple projects. I m having an urgent assignment now to use TD along with a accelerometer motion tracker, to have moving lights tracking a motion of an object on stage, which means I have to have:

  • An anchor point O(0,0,0)
    -The input of the coordinates (xyz) of the object
    -The positions of the moving lights, compare to this object.

The moving lights are moving with Pan and Tilt … So I thought it has to be a formulation that is easy to calculate everytime the object moves. Well, mathematically very easy, but is it possible in TD is something else. (So with rotation, angles, that changes along with the formulation).

How would you recommend best way to do this in TD? I have looked into Line Sop, Point SOP and probably use Magnet SOP? But it is unclear to me how could I translate this in corporation with Motion Tracker and nodes on TD. Please help me… Millions Thanks!

I am also interested in doing something like this.

This looks like something you’d actually want to do with geo/light COMPS and nulls instead of SOPs directly.

A basic setup would probably have your tracked object represented by a null COMP and then light COMPs corresponding to your fixtures placed into your scene. Have the light COMP look at points bound to your null and then use an execute DAT to convert the matrix transforms of the tracking object into rotation values.

You’ll want to have a separate light comp for each light in your rig and iterate through them to extract all their values. Then you will need to interpolate the values to get you into the proper DMX ranges for your fixtures. Also you’ll need to correct for variances in the way they are hung.

Here’s an example for how to extract rotation values from matrix transforms.
lxTrackExample.2.toe (5.68 KB)

Interesting method with the execute DAT. How is it different from the object CHOP?

I haven’t used the object chop before. :slight_smile:

Testing it out here it looks like you would need to use a separate one for each light. also, it looks like the object chop is computing a roll angle variance, which the other method doesn’t. It seems like something you could choose to discard without issue though.

I generally assume that python script based operations are less efficient than raw CHOPs, so I suspect a solution built out of CHOPs would scale better and have better performance.

I modified the example (attached).

Thanks for the tip!
lxTrackExample.4.toe (5.59 KB)

Interesting input!

I will try to send the dmx data and translate the data too try it out.
Thank you very much! I will let you know how it works out!

Best,
luonglinhle

Dear @flowb,

I tried with your patch, I connected the Moving head to its parameter and divide into 8bit of msb and lsb. However, it seems like the 2 lights are moving in seem direction, rather than targeting the same object, it is like they shed2 parallel ray…

Here is my script. Please help me out.
tryout1.toe (8.45 KB)

from what i can tell i think you might just be having issues because your approach to isolating and moving values around your network leads to some disorganization.

The later example that’s posted in this thread would be better for you since it means you don’t need to use the DATto CHOP as it directly adds a CHOP channel for all the values you need.

Next I would try to get rid of the Constant CHOPs in your network. Coming from other platforms I can understand why you did it that way but, the most TouchDesigner-centric approach to managing sampling individual channels from a group in CHOP is using the Select CHOP. You could use a series of these to feed your expression and math chops and have it be easier to visually assess where data is coming from and whence it goes.

when feeding sACN or ArtNet outputs I usually like to explicitly name my target channels for the universe (ie: c1-512) so that i can make sure that I don’t have hidden issues with addressing. The Rename CHOP could do this for you. If both your movers are processing the same values, odds are it’s a fixture addressing issue of some sort.