|
|
RectHit (Composition by gtoledo3)
This composition demonstrates a hit test method that works for rectangles. It was inspired by a hit test method description that I read about in an interview with Bill Atkinson about the development of QuickDraw that uses logic based on two points to determine if a hit is inside or outside of a rectangular area. This patch is strictly 2D compatible. Z translation as well as X, Y and Z rotations are not taken into account, and it won't work inside of 3D transforms since it doesn't "know" what happens outside of the patch. One must hook the outputs of the HitRect patch to the corresponding inputs on a Sprite (or Billboard), for this to work properly. There IS a more full featured hidden hit test patch (which sometimes provokes oddities in QC). This was done mostly out of curiosity after reading the interview with Bill Atkinson, and to reproduce that particular method by using QC patches. |
That is clear and elegant. Much appreciated.
Cool, thanks, glad you think so! I'm attaching a second demo that makes it a bit more graphically interesting, and shows how it can be used to do the type of hit=particle bloom that is so popular in Processing.
MacPaint brings back some fond memories. In picking up on & porting that RectHit function concept you're proving that a good idea lasts forever :-) .
Substituting and publishing X Position and Y Position input splitters (settings: Number, tolerances: -1 to +1) for the Mouse patch gets it working in CamTwist (and so maybe VDMX too?) with access to the butterfly via 2D XY position box. I suspect I'll be having big fun with this. Thanks so much!
It's a pretty essential function. It's cool to make "neat looking stuff", but it makes sense to make some patches to fill in missing utilities - this was really aimed towards making the "QCButton" that I posted about.
When I use the private hit patch, every so often I get the "big Viewer" syndrome like happens with some patches - the image gets twice as big every time the composition runs. That made it necessary to reconstruct a decent hit patch from scratch, that isn't buggy (interaction can "sort of" be used, but it puts out an erroneous mouse down in certain scenarios, and has some other problems that make it better to not have to use interaction ports/noodles).
This is a fun demo that I made that shows how to do some game type logic. It uses Spooky to gather all of the individual hit counts, and then sum them outside of the iterator.
If anyone knows a good way to sum all of the index values in a 1D structure, it would be handy so that one doesn't have to break-out the individual object hit counts to sum them outside of the iterator. I don't know how to offhand.
Neat! This one appears dependent on the presence of the Mouse patch? I'm suspecting that may restrict it's usage to QC exclusively due to the need for manipulation via the Viewer? Does anyone know how to access the mouse patch functions, other than X and Y positions, in third party apps?
Oh, you mean cam twist can't receive the mouse up/down events for left and right click, and you can't publish those to root? Hmm, I didn't know that. That is limiting.
It can be viewed in non QC-settings, like Safari (maybe not Spooky "grand total score", depending on someone's settings).
You could just turn the left click permanently to "on", and the right click to off, but it will remove the toss effect, and the ability to clear numbers.
Ahhh. You're right. Ok. I'll give the reset a boolean toggle of it's own. Sorry for the confusion. Probably the cleanest remedy for me would be to simply place a hit area in a corner somewhere to activate the reset toggle. That would make good use of this great feature you have created. Thanks again.
But this leads me to inquire if there are indeed any third party apps that can directly access that mouse patch in quartz compositions that they are hosting? I don't know of any, but if they exist I really would like to know how they work.
I guess this depends on the scope of "directly access" -- you can publish all the mouse patch's outputs (providing access to the app), and the app can provide mouse events to the QCCompositionRenderer-obedient class (QCView, QCRenderer, unfortunately not QCCompositionLayer since that slipped through the cracks), which directly control the mouse patch. So while it's not literally accessing the patch, it's in complete control of 1) what inputs it uses and 2) what outputs it provides.
hmm. So that would be up to the application's developer to achieve? Actually, I bet we could nonetheless achieve it via Kineme Multitouch and the Magic Mouse. I was just trying to figure a way to have all the functions in one nice tidy controller instead of in numerous individually published ports, each requiring their own individual control interface (slider, checkbox, etc) in the third party application.
Any idea why mouse and key events don't get through to QC based files placed onto Keynote slides — is it a QC framework problem or (more likely) a limitation of the Keynote implementation of QC comps?
Keynote plays QC compositions through the QuickTime wrapper -- that wrapper strips off all event information (and only allows safe mode patches); it's not a particularly good way to render compositions, but it's better than nothing (back in 10.4, this was a common way to get QC supported in QT-supporting apps. Nowadays it's easier to just use a QCView or QCRenderer)
So either .qtz files and .mov are using a Quicktime wrapper? I've tried using KinemeCore pref's safe mode mods and obviously not got events. Can't remember if I got any 'non-safe' or 'non-stock' patches working.
as far as I understand it, yes, they both use the wrapper. Events are completely unrelated to safe mode -- events require the application to actually provide data (so no amount of tweaking/hacking will make them just work; it's a non-trivial problem).
QuicktimeVR can receive mouse events from the Quicktime Viewer area.
QT has code in place to do that for QTVR -- its QC retrofitting apparently didn't get such a blessing. (and even then, QT can't magically will events into existence without the app making some provisions for it).
solving this is technically possible, but doing it using the QT pipeline is not the simplest nor most direct way to do it.
I'm attaching a tweaked version of the last one that shows how to have the object hitting the block cause a extra friction on the object, by using the output of the hit test via the Spooky.
This really bring to mind that the impasse of only being able to publish out of an iterator or consumer environments if there isn't a consumer in the patch, is sort of stupid, because after testing with the Spooky, I can see that an iterator with consumers is obviously still working "the same", and can deliver the type of info that one might want to get outside of the queue - like the structure of all of the separate object counter values in this case.
Layer order doesn't determine execution anymore anyway, right? It doesn't seem to be causing any crazy leaks or miscues to be doing this, though I could imagine being able to construct things that are "wrong". I think this is one of the first times I've really had to use Spooky because of it and that the patch can't really be re-ordered to avoid it. I think making a duplicate macro without renderers would be dumb, but I guess I could do it to keep it stock.
It sure enough all does work well in Safari on my Mac, George. Everything works including the grand total. It works in NetNewsWire's default browser, too. I'm guessing that my inability to use the mouse function via CamTwist's viewer window is that CamTwist isn't a browser and it's viewer window isn't a browser window. CT may actually even be constructed (just speculating wildly) according to the method that Chris described for OS 10.4 QC support via Quicktime. I guess I shouldn't be taken aback, insofar as the CT viewer window is not of basic necessity to the primary function of the application which is to prep imagery for streaming.
layer order still determines execution order. however, it's not as straightforward in 10.6 as it was in 10.4/10.5
I definitely understood that when I made the comment. I guess what I'm pointing at is that QC is a non-trivial technology compared to QTVR, yet QTVR actually does this kind of scene panning with mouse via the Viewer as opposed to a menu bar or something. Actually, it's kind of funny that QCVR intercepts like that, it might be an exploit.
It's interesting that at one point it was declared a must for something like QTVR, but for QC, someone said "scratch that".
Also, I understand the technical reasons why the mouse events work this way, but I can't help but think that it would be great if the OS worked in such a way that mouse events "just worked"... a freebie of using the Mouse in QC, so to speak. I'm actually amazed that so many apps don't forward mouse events, or make you use the app shell for some reason. This actually gives me pause, because it presents in impasse for actually doing stuff in QC that isn't just "cool visual" if things like an interactive GUI in QC won't "just work" when loaded as a resource in QC hosting apps. Again, I understand why this is like this, so I make these comments in that light.
Not sure if this is a regression to Leopard thing but I had to rename the "QCButtonPatch.qtz" to "QCButton.qtz" to get "QCButton-Demo.qtz" working. Now I have the 'Patch with name "/momentum scrolling" is missing' error for RectHit Demo 3 – Hit Map and Score.qtz composition.
"scratch that", or "don't bother" ? engineering resources are disturbingly short, so non-essentials (and even essentials sometimes, unfortunately) get axed. fully functional QC in QT has never had a compelling demand, so it was likely never deemed worthwhile to spend more effort on.
Event forwarding does work like that, but from the "top down" (i.e. from the app to the window to the view hierarchy) -- something at the bottom (QC Mouse, which is a sub-object of a QCComposition that's associated with a QCCompositionRenderer that may or may not be view-or-layer-backed, and may or may not actually be on screen, cannot simply "demand" for things to come its way -- it can snarf mouse position (though that was kindly broken on 10.6) due to some appkit tricks, but other stuff cannot be (clicks, in particular, along with scroll events).
If any piece of the chain forgets to pass things on, or thinks it's irrelevant, downstream responders suffer. That's unfortunately just how it is.
If you really want to demand access, use the HID patch, hopefully not in exclusive mode :) (and that won't scale, of course, because USB mice are all different :/)
It can just work -- use a QCView (And set the event forwarding mask appropriately); QCView is configured to accept and deliver events as QC expects. It's when a different method is used that things aren't so simple (i.e. using a QCRenderer + NSOpenGLContext like QuartzBuilder does -- I had to emulate what QCView does to get that to work, or QCRenderer inside a QTMovieView, or even QCView-as-a-sublayer-to-a-non-event-delivering-view setup, as I've seen in some instances).
It's a tricky thing, and niche enough that it's often overlooked (if a button accidentally ignored mouse events, heads would roll. If a QC composition doesn't, most people wouldn't be as concerned)
You can't get the momentum scrolling because you're in Leopard and it depends on the feedback patch... it's a system wide patch (momentum scrolling).
I know I always have problems whenever I've had compositions that use virtual patches like this get made in SL, and then I open in Leopard. I didn't check it, but I honestly didn't necessarily intend for it to be Leopard compatible. At this point, I'm not checking for backwards compatibility too often. Change is inevitable/has happened.
I just looked into it more. For some reason, the filename being QCButtonPatch, yet the "name" in the plist is QCButton ... I'm not sure how that happened(happens?) exactly, but it's interesting that it doesn't cause problems in SL. I'll upload a change for that I guess.
wow cool, missed this as i have been in iphone land for a few days. reminds me of mario brothers with the bricks. defiantly a good example, hit testing shouldn't be overlooked now that QC has interactions as it makes non inter-actable objects inter-actable. i just made an open cl patch like this didn't know you had posted this, i guess great minds think alike.
Weird, you've been on Vimeo and here the past few days. Just sayin'.
Edit: Hmm, the comps look pretty familiar lol... but fwiw, yours don't render or work.
Fuck me...
what is fwiw ?
[edit] i figured out fwiw "for what its worth" sorry i'm daft sometimes. i actually looked up "imho" the other day as i have seen people using it on boards for years but never had any idea what it was and never bothered to google it. just had to point out my own stupidity.
Good stuff. It's essential to figure this stuff out if you want to do any kind of UI within QC (and considering how cool a QC based UI can be, especially paired with a touch screen!)
Are you using the Hit Test patch to get it running btw?
Nope, made this IS a hit patch, made from scratch. Then the QCButton thing uses the hit test I made. Thanks man.
i usually try to browse vimeo every now and again. i like to look at the things people are doing with qc. i try to make frequenting kineme a ritual as people are posting some really nice things here, but honestly george i haven't had the time the last few days to participate here.
i mean i came by a couple days ago noticed some cool 1024 plugins but didn't have time to read any threads / download or comment on things until this morning.
i guess i was just mentioning this as i didn't want you to think i was trying to byte one of your comps and make a hit tester or something like you did my friend.
layer order seems to matter while hit testing in an application context or at least so i have found. not necessarily using just a qc view but when using a qc view as a CA layer with sub views stacked etc.. as there seems to be an order to which layer view gets evaluated first in order to make the hit test.
it get tricky sometimes as you could have a layer view on top of window etc, and if you want to get your hit test or touch events down to... ( or actually i think up to... depending on how you look at it) a window layer. then you need to pass the event through the responder chain by using nextResponder or something. it gets confusing as i normally have to print the next responder class to the log in order to really know which class the responder forwards events to.
it would be interesting to see a layered hit test patch like this in qc. interactions work like this but it would be interesting if we could access the the layering order of consumer patches through a input port or something. maybe thats all ready possible not sure ?