> On Jan 12, 2011, at 17:47 , Christopher Wright wrote: >> This isn't possible in the construct of QC > > I understand that. Although logical, it seems paradoxal that Quartz is so > good at real-time rendering and so weak at real-time input. I'll investigate > further on my options. Nothing happens between two frames. Check.
On the surface it's perhaps paradoxical, but a further inspection might shed some more light. Specifically, QC evaluates things "backwards" (from consumer up to provider). This is sometimes called a "pull model" or "lazy evaluation". It makes it so that unnecessary portions of the graph are not executed unnecessarily (stuff feeding disabled consumers doesn't need to do any work). The down side to this design is that you cannot "push" data through QC in any meaningful way. realtime input favors push model evaluation (where data flows from the pushes down to whatever consumers there are, if any). This sort of model needs additional information to know when to not do work, which isn't difficult to gather but isn't the case for QC in any event. There isn't a clear "best" between the two designs, they're simply for different purposes, with different pros and cons for each. Hopefully that fills in a bit more detail as to why it's so painful to do what you're wanting to do (purely in QC). > If you need to retrieve a direction angle from a movement using atan2(x,y), > you must update two queues only if their input values change - otherwise you > end up with equal numbers when motion stops, resulting in a sudden drop to > zero - whatever direction you were facing a frame before. Updating only when > value changes allows you in this situation to keep your last few deltas at > hand, and return consistant directional calculation. > > On the other hand, calculating movement speed calls for continuous filling, > otherwise it won't decrease if you stop moving. Normally for this sort of work I resort to a single javascript patch -- it can store state between frames, so you can effectively queue as you need to (per-frame or per-update, as situations demand). I'm not saying that's a better approach, it's just how I'd do it (JS comes with its own overhead, and it's not always obvious what's going on when looking at the graph; that said, looking at the graph isn't always obvious even when there's no JS.. :). it might also be possible to use the derivator patch to calculate speed (sqrt of dx squared + dy squared) without a queue, but I don't know how accurate that will be compared what you're doing (particularly if the queue length is larger than 2). regarding the angle, you could also special-case 0,0 (no change), and in that case reuse the previous output value (using a splitter + loop). Again, I'm not sure how this would hold up (I could whip some things together, but it's late and I'm tired :), but it might be worth an experiment to two for those who are curious or enterprising. Thanks for the example composition, by the way. pretty slick. _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
