Thread-topic: depth testing: none of them seems to be correct?
User-agent: Microsoft-Entourage/11.2.4.060510
>From my much more limited perspective of iterators -- I would do the layer
ordering "above" all the iterator patches. I would assume that it's best to
do all the calculations -- as much as possible, outside an iteration,
assuming that iterations are just object references and they re-calculate
all the code inside for each and every item being moved.
Does the JavaScript in Quartz allow for a multidimensional array? Then you
could just "sort" on Z depth. I would think that even if render order were
an issue, you could imagine that all your iterations were merely references
in your array, and use a multiplexer to pass the actual image to the
iterator. Storing all the image types in a multiplexer allows them to be
cached and will improve performance anyway.
Thus, for instance, as a square moved "in front of" a triangle, it's
actually swapping out the image held by iteration 3, with a square [rendered
later and "on top of"] with a triangle.
So you would sort [z_depth,image_index,my_index], then the iterator would
grab and render each item in the array in the proper order. I include
"my_index" as a way to keep track of an item for continuity (the original
creation order).
Letting the iterator just do work once as the "difference" of the object
from a previous state in an ordered execution is good. But I could see where
doing all this in a JavaScript, to deal with objects rendering correctly
could be confusing.
-- I hope I added something to that discussion,
Mark Johnson
> From: Pierre-Olivier Latour <email@hidden>
> Subject: Re: depth testing: none of them seems to be correct?
> To: Roger Bolton <email@hidden>
> Cc: quartzcomposer-dev list list <email@hidden>
>
> You can use some math inside your iterator to "re-order" the current
> index dynamically:
> n' = f(n) where n is the current index, and n' the modified current
> index to take into account back to front rendering
> f() might not be so hard to figure depending on what you do
>
> Inside the iterator, between the Iterator variables patch and its
> current index output and the other patch inputs it's connected to,
> insert f()
>
> For instance, if the index goes (0,1,2) after re-ordering you would
> have say (2,0,1) so your iterations actually happen in that new order.
>
> On Jul 13, 2007, at 11:22 AM, Roger Bolton wrote:
>
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/email@hidden
This email sent to email@hidden
