Hi Ben,

Thanks for your help. When I open the patch and turn rendering on, my terminal keeps spitting out the following message:

/*separator : state->numTexCoords 4 != m_state.numTexCoords 0

*/I get the cursor to follow an object, only when pointing the camera to a steady background and using a very reflective object which enters the scene. I know that motiontracking is a very 'sensitive' thing, so maybe that's just how I should handle it.

This autoscaling from the x/y coordinates of pix_blob to Gem units is interesting. I see you're using the '8 unit'-fact of the gemwindow. Adjusting the window with another aspect ratio, means that I've to adjust the [expr] in order to make it [autoscale] again.

Thanks a lot and maybe till nxt time in Vancouver,

Sara

B. Bogart wrote:

Hi Sara,

I have a gem motion tracking patch I show students at:

http://www.ekran.org/pd/patches/Gem-Tracking-Presence.pd

As you can see I learned a lesson from then that relates to your questions:

1. X/Y coords from pix_blob are 0-1 not in gem units. (in the example

above I did some silly things to autoscale the units it gets to gem units, but I'm pretty sure the scale is 0-1. 2. I have been unable to get pix_multiblob to work myself yet... 3. I've never used [showblob] abstraction?? 4. Ok, I'll quote an email I already sent to the list:

...

Gem coords really only represent distances relative to the window aspect ratio.

0,0,0 is in the middle, -4,-4,0 is the bottom left corner 4,4,0 is the upper right corner. The camera is at 0,0,4...

That is for a square window.

The height of a gemwindow is always 8 units, -4 to 4, but depending on the aspect ratio of the window the number of units wide changes. for a 2:1 window the left edge is -8 and the right 8. For a 4:3 window the left is -5.333 and the right 5.333

Hope that helps a bit.

.b.

sara kolster wrote:

...

Hi,

I'm trying to understand the Gem motiontracking objects, but I don't seem to get very far. The help patch of pix_movement shows the difference between two subsequent frames, but when I connect pix_blob (set to the alpha-channel) after [alpha] in the rendering chain, I have no clue what the relation is to the xy-coordinates that come out and the movement I see in my frame. When connecting pix_multiblob after pix_movement, the xy of'showblob' seem not to have any relation with the movement I see.

Some questions:

• what are the x/y coordinates in relation to my Gem window (defined in

pixels) and the x/y coordinates of the objects [translateXYZ] or [pix_showblob]? Or are the x/y coordinates related to the geo (defined in units) on which I texture my image?

• Does [showblob] represent the movement? Let's say that if we have a

red background and a green moving ball, showblob is following this green ball? Or is my understanding completely wrong/backwards?

• Can anyone explain the definition of units, when p.e. rendering a

rectangle of 3/4 in a gemwin of 800/600? I understand that 'units' are logical sizes in a 3d-application (from: Gem manual), but is there anyone who found a way to explain this better?

Did someone succeed in making a simple motiontracking-patch, just so I can understand how these objects work?

Thanks a lot, Sara

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hi all,

When using [separator] or [pix_separator], GEM displays the last created [separator] chain in the foreground of GEMwin. Is there a possibility of giving something like a set-message (used to set the render order of gemhead) to give a order of rendering when using separator?

Thanks a lot,

Sara

chris clepper wrote:

On 3/16/06, *sara kolster* <sara@x-i.net mailto:sara@x-i.net> wrote:

Hi Ben,

Thanks for your help. When I open the patch and turn rendering on, my
terminal keeps spitting out the following message:

/*separator : state->numTexCoords 4 != m_state.numTexCoords 0

You might have a separator object before a pix_texture which triggers that message. What it really means is that your patch is leaking memory and will eat all of your RAM soon.

cgc

---

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hey,

I didn't think it was a Gem problem, but I was facing the problem when I was working on a patch and the last 'modified' separator would always show on top. But, as I understand you suggest that I could use [t a a] which should provide this from happening. Right?

Sara

the problem you are experiencing are pd-problems and not really Gem-problems: controlling the execution order!

just use the tools provided by pd for manipulating the data-flow. with things like [spigot] and [t a a] (before the [separator]) you can do astonishing things.

note that there is one thing you should _not_ try: using delay-lines for the messages passed between Gem-objects!

mfg.asdr. IOhannes

hi

B. Bogart wrote:

Hi Sara,

#3. separator is a lot like a gemhead, separators don't allow you to specify the render order, so the render order is the order in which you create the separator objects like #1.

I think that covers it.

well, not quite. the creation order of the [separator] object does not matter at all. the "thing" that currently defines the behaviour is the order in which you draw the connections to(!) the [separator]s. and you must not rely this: as long as you connect one outlet to multiple inlets, the execution order is _per-definition_ undefined. that's why there is [trigger]

mfg.asdr IOhannes