On Sep 19, 2009, at 1:15 PM, George Toledo wrote:
On Sat, Sep 19, 2009 at 3:13 PM, Alessandro Sabatelli
<[email protected]> wrote:
On Sep 19, 2009, at 12:08 PM, George Toledo wrote:
Nice! I haven't tried this yet. Thanks for letting me know the
route I should be taking.
With the Interaction patch, I'm desiring to be able to hook the
Interaction output (blue cable) to multiple Sprites/Mesh Renderers,
and set offsets between them using math coming off the the x/y
output (imagine a 4x4 + grid) and have every one of the Sprite/
Billboards/Mesh Renderers be "hot"/"grab"able, but also have them
move together as a group, instead of having only one of the Sprites
be the one that is able to interacted with - without having to
involve Iteration in the scenario.
Makes my head hurt a bit, but perhaps perfectly reasonable. File a
feature request.
Ha! Trust me, it makes my head hurt too. There's a long story behind
this one.
Iteration is a deal breaker since iterated objects won't work with
the shadow option in the Lighting patch.
This is a bug and should be filed.
I have - Problem ID: 7233976
Chris Wright may have filed a bug on this as well.
{Digression- I admit, sometimes filing bugs via the official
procedure feels like being in college and having a report I don't
feel like getting started on, or getting asked to do a job for free.
Well, I got paid to go to college, and am not used to working for
free, so I guess I've been spoiled. I'm making an about face on this
though, since it's more important that the OS "rocks". I've always
been more the "jot an email about bug" type of guy.}.
Right there with you.
.xX
I want to be able to control multiple Sprites like this without
involving the Iterator, since I want the shadow effect. For the
sake of argument, imagine a flock of dae birds or again, a grid of
sprites, where the Interaction x/y attaches to each Mesh renderer
or Sprite, with math+lfo making an offset and organic movement
between all of them, but wanting the user to be able to "grab" any
of the objects to "move" the grid/flock, but also get the benefit
of the shadowing.
When one attempts to hook the Interaction out to multiple Sprites,
the oldest connection breaks. One can put multiple Interaction
patches on the editor, but then the Interaction becomes unstable
and "halty" ; probably because this is not intended.
Can you explain this a bit more? Are you chaining Interaction
patches?
.xX
Actually, I now see what was happening, and "halty" is definite
overkill... the effect was exaggerated for me because of using
large, overlapping, Billboards when I first "saw" what I'm going to
describe.
Multiple Interaction patches do work, it's just that I was
experiencing a "jump" where one of the renderers "jumps" to where I
click instead of staying at the point that I grab it at, depending
on the order of Interaction.
Ok, this is a bit odd to explain how to reproduce.
1. Open Composition.
2. Grab Red Sprite. Place on top of White Sprite.
3. Grab White Sprite. Raise it upwards (still underneath Red Sprite).
4. Touch Red Sprite.
5. Now, Touch the bottom edge of the White Sprite. This is where it
goes awry. The White Sprite jumps so that the cursor is pinpointed
in the middle of the Sprite instead of the usual Interaction patch
function of being able to grab anywhere on the Sprite, and smoothly
move it from that point. This makes the Sprite "jump".
I'm including a folder with pictures numbered for each step.
I can understand that this may seem a bit over the top, but I really
don't think the Sprite should jump like that.
-George Toledo
I wouldn't even think to put multiple external event patches like
that but for want of a work-around, and the fact that the x/y
offsets on the patch seem to suggest it as a possible working
method (but it isn't).
There may be an obvious workaround to not involve the Iterator, and
have multiple Sprites or Meshes work with Interaction, with each
being "grab-able", but it's eluded me so far.
I'll also try the 3D sound setup that I've intended now that you've
given me a greatly appreciated running start on capping the counter.
Thanks again,
George Toledo
On Sat, Sep 19, 2009 at 2:27 PM, Alessandro Sabatelli
<[email protected]> wrote:
You can use Javascript to roll your own counter:
var _count = 0;
function (__number Count) main (__boolean Increasing, __boolean
Decreasing, __boolean isLimited, __boolean wrapLimits, __number
Min, __number Max, __boolean Reset) {
var result = new Object();
if (isLimited) {
if (wrapLimits) {
if (Increasing) (_count++)%Max;
if (Decreasing) _count==Min?Max:_count--;
} else {
if (Increasing) _count==Max?_count:_count++;
if (Decreasing) _count==Min?_count:_count--;
}
} else {
if (Increasing) _count++;
if (Decreasing) _count--;
}
if (Reset) _count = 0;
result.Count = _count;
return result;
}
If you wanted to use this in an iterator you would need to modify
this or something like this to have an internal count per iteration:
var _count = []
function (__number Count) main (__index Iterations, __index
Index, ... {
..._count[Index]
}
If the 3D sound player is not working properly inside of the
iterator please file a bug.
As for the Interaction patch it would be helpful if you could
explain the problem you are trying to solve a bit more.
Thanks!!
.xX
On Sep 17, 2009, at 9:06 PM, George Toledo wrote:
I have a some questions about ideas I've had that have been raised
by this example.
Is there a way to cap the counter? What is the proscribed way to
trigger a reset on the counter so that each counter is limited to a
given maximum number? It doesn't seem like this is possible. True
or false?
Secondly, it also doesn't seem as if the 3D sound player will work
inside of an iterator. Is this true?
The basic idea would be to have each iterator counter trigger sound
files by having the iterator counters control index value of a file
structure. I'm not including an actual qtz file with this, as the
most preliminary tests with manipulating the Iterator Counter.qtz
seem to show that the patches aren't designed for this.
Also, I'm not 100% sure, in general, why the Interaction patch
can't work with multiple renderers, but only one at a time. If it
could connect to multiple renderers, math could be used to offset
the x/y translations, and billboard, sprites, spheres, etc., could
be moved around as groups with consistent spacing. Is this a
reasonable request given the design?
-George Toledo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/asabatelli%40apple.com
This email sent to [email protected]
<interaction jump.zip> _______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected]
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/asabatelli%40apple.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to [email protected]
