Layer Ordering Problem

Correction: There's also a second more subtle layering issue with this comp. The cyan button is design to be click-&-dragged.

This led me to eventually make a number of patches that draw arrays and or lists of objects, so that I could control layer ordering in a way suitable to me... tobyspark did a really interesting project that shows drawing triangles and line (I think?) in a loop, and was kind of an eye opener, and the published kineme stuff is really informative from a skanky sdk standpoint.

Now, I think for what you're talking about, maybe an iterator can handle it...

Maybe you should just test for color instead of position. So, when you hover over the correct color, that's like a mouse will click, you click, then you activate a toggle/loop to switch whatever the x/y were with whatever your mouse vals are, and then let the next toggle release.

I haven't looked... if you're actually testing for color vals to your hit test, and green and cyan are too similar, keep in mind that you can actually test for colors offscreen. So you could test for a variety of grey intensity levels with image pixel, while writing your aesthetic color choice on a layer above.

I did a "object detection" thing around here (I think?), that was a very simplistic implementation of the concept of storing data to on offscreen color texture to enable id'ing... that and some principles used in some feedback loop/interaction stuff that's been posted may be a robust route for your scenario.

Thanks George. Even though I just have colour in the billboards in comp I posted, that's just to simplify the comp for demonstration of my problem. I actually have multi-layer PDFs of diagrams inside in the main comp. Will post whole thing to repository when I solve all the problems.

The RII patches handle all the PDF layer toggling business* instead of me doing it with image blending patches which seemed more clunky and potentially had me ending up with co-ord mismatch madness due to bounds differences.

So colour testing is out, and I'd still need to switch billboards to get the right one on top.

I see what you mean by using an iterator, though. I thought about encapsulating the billboard input values into structures and demultiplexing them based on on hit number. That way the top billboard always gets the expanding image. It's easy enough to work out which one is being hit to index the demultiplexers. I guess that's the easiest way. What a drag!

* I would love to see layer support added to Kineme PDF patch. As in, each layer's visibility on/off state (like InDesign has) as set via a structure input port of bools in Kineme PDF patch. I have to use a separate page for each layer as workaround, which means carving up my artwork to separate pages each time I edit the drawings.

Cant you just use sprites instead of a billboard and adjust the z position to control which sprite is in front/visible?

There's a lot going on there, but what I do notice is that when the little interaction sprite is shifted to different places, that the log shows the red/blue reset trigger stuff working in an inconsistent manner in the javascript patches, compared to what I'd expect... I'd scrutinize the code in there as starting point, but it may be the wrong place to look. Not sure.

When you are mouse down on the interaction sprite, all of the other sprites need to go into a mode that changes how their hit test happens; allowing the hit test on them to probably only happen once you've released mouse off of the interaction sprite you've made and the mouse is outside of the zone of the interaction sprite...

I haven't checked it out, but it's especially important that you're checking against more than one point, probably using two points to contrive the zone of what must be the rect. I'm guessing you're doing that because we've talking about that before.

I think you could probably just solve your "layering" issue by getting rid of the billboard approach and shifting to Sprites, so that you can pop the top layer so that it's a slightly higher position in Z.... provided you're not doing anything with blending that will make artifacts. If so, you may want to look at the kineme depth sort sprite/environment.

Hey, I knew there had to be an easier way! I tend to prefer Billboards with Pixel Align set to on for imported artwork, as these will be displaying but if it's looking okay then that's the way to do it. Great tip.

Demultiplex Z instead of demultiplex whole structure of inputs is much cleaner.

Well the point of that JS is just to stop the button trigger from repeating during a mousedown event, it waits for a mouse-up before the button 'trigger' is rearmed, (and changes the state of course which could have been done with a maths patch and an input splitter to hold state).

The thing is whatever is happening, is happening to whichever billboard is set to layer 2 (correct behaviour) and the other two billboards layers 3 & 4 are behaving incorrectly. Changing billboard Layers changes the one which works correctly, and they all have the code... mystery.

The interrupt signal is sent to all buttons, including the one which generated the hit. The logic-test for the interrupt is only for the mousedown part of the hit-test not the continuation of the hit-test. That's where all the hit-tests have to be favorable, X inside range, Y inside range, mouse button down and not(interrupt).

If you look at the Kineme2D Curve with markers demo I made for the demo comps folder, you will see the macro stops testing for X,Y range after the initial mousedown frame, because fast mouse movements (hello Wacom) cause the cursor to leave the button height and width range rather too easily — resulting in a dropped marker mid-drag :/

So the marker follows cursor anywhere until mouseup and is not hit-tested for (X,Y) range after initial hit is registered. For some reason the interrupt seems to be only effective on macro connected to layer 2 billboard.

Yes Z order on a Sprite might be order of the day for the first problem, good tip thanks!