Layer Number of Macro

toneburst's picture

Anyone know if it's possible somehow to get the layer-index of a macro from inside that macro?

For example, macro 'This Macro' is inside macro 'Container Macro', and I'd like to get the layer index for 'This Macro' inside the containing macro. Confused?

This is all to work around the crapness of the Iterator patch, and to save me setting individual ID numbers for x number of macros manually.

a|x http://machinesdontcare.wordpress.com

cwright's picture
layer number

the layer number for a consumer patch isn't actually stored in the consumer (it's derived from the graph structure in the parent node I think), so it's not quite easy to extract. It should't be too crazy, but it's definitely territory that hasn't been explored, and is likely to change.

I've always wanted a better solution than the layering one that QC has had so far -- it's great for fixed level compositing, but lousy for situations where layers are dynamic.

gtoledo3's picture
Re: layer number

Is there any kind of mod that could currently make layer available via index port? Renderers at lower levels do have lower Item keys.

cwright's picture
Re: layer number

no -- the layer is not stored in the composition (as I noted above), so an input port cannot set it (because it's not a value). I guess the port could reorder the graph, but that'd break a ton of stuff and would cause problems (if 2 patches claimed layer 0, who wins?)

you really don't want dynamic layers. trust me. you want fixed layers (like QC has now), or no layers at all.

gtoledo3's picture
Re: layer number

Hmmm... I guess when I check it, it look like renderers always represented as Item numbers low->high, but maybe I need to look more and see that there may be exceptions (?). It doesn't seem like there is though. So, it's not described as "Layer 1", but it's there, no?

The Item number isn't a port value, but since it's a Dictionary and part of the QC patch, I thought it might be able to be changed...

I guess that it would be weird to maintain the layer shuffle that happens if index values were hooked up directly to the ports, and they were conflicting. When you have a structure and there are multiple keys in the same index with the same key name, the duplicate just gets ignored. I don't know if that really applies here though.

Flipping layers around wouldn't break input or output connections at least.

I definitely see your point about dynamic layers, and understand why you say that I don't want dynamic layers, but I would really prefer the option to what is available now; things get screwy when doing over blend and quad/sprite type things and trying to shift back and forth in Z. Actually being able to layer flip in via an external control would make many more things possible... though I know that one would have to intelligently plan out layer changes to avoid layer changes being jarring.

cwright's picture
Re: layer number

Correct, it won't break connections (thankfully) -- however, it's not a "dictionary", it's an array. Dictionaries don't have indices (and they're not guaranteed if you iterate), so they're not a good fit for layer order.

When you have a dictionary with dups, the dup wins (the last value set for a key kills the former value set for a key) -- so setting layer 1 when layer 1 is already set would kill the old layer 1 (yikes). But since they're not dicts, that doesn't matter here.

I wonder if it would be possible to create an infinite loop where evaluating layer 1's inputs would change layer 1 to layer 2, and evaluating old layer 2's inputs would change it back -- or something similarly contrived. That would be a big problem.

I don't disagree that it's be more useful than static layers, but I'm not a fan of halfway solutions, or solutions that just cause more problems :/ swizzling layers isn't addressing the real problem, unfortunately.

gtoledo3's picture
Re: layer number

After more thinking about it, I realize it would have to be a specialized data type like Interaction so that loops couldn't occur, and at that point it all becomes sort of stupid and hackish (but, no more contrived than interaction, imo). It would be better to address it differently, agreed.

I thought they were dictionaries because of how they are represented as plist (where it describes the Item _ as a Dictionary).

The depth sprite is a good enough solution, but I guess I really want that same premise to work with K3D planes and/or OpenCL mesh. If there was a depth GLSL grid, it would be painful, but still better than having just the sprite.

cwright's picture
Re: layer number

plists can have arrays too -- open a composition in plist editor, and you'll see Array as well as Dictionary used for compositions. (picture attached)

Depth GLSL seems incredibly difficult (because the vertex shader can change the object's depth, and nothing but the GPU will know about it), but perhaps passable (if you don't deform it too much, it'll be "good enough")

(composition title was for some crazy tricks, not referring to the contents of this particular screenshot - I picked that composition at random off of my desktop)

PreviewAttachmentSize
ArrayOfNodes.png
ArrayOfNodes.png69.2 KB

gtoledo3's picture
Re: layer number

Oh ok, I see what you mean, I understood that the whole node is an Array. The "nodes" entry is an Array, but each of the Item #'s, which seem to correspond with layer count, is a Dictionary.

I have that composition already, I know of it ;-)

I see what you mean about GLSL, but would something like K3D be possible since it works on the CPU? Not that it's likely to be implemented.