[Bf-committers] Re: render passes & workflow

[GSR]

Hi,
matt at mke3.net (2006-12-07 at 1125.47 +1100):
> Right now, the object ID pass doesn't seem that useful, they pretty  
> much just give me a black and white image that it's hard to do  
> anything useful with, and similar enough to just putting that object  
> on its own render layer anyway. Having to tweak number buttons and  
> assign an ID to each object manually is a real chore and it seems a  
> similar approach to Cinema 4D, where it's mostly used as a workaround  
> for having no render layer system like we do. Also unlike other apps,  
> none of our nodes have an option to selectively apply effects to  
> certain object IDs, and I don't think that really fits with our  
> compositor either.

In a blog there was somebody asking for conditional node, BTW, I hope
he had a reason for the request. It could indeed be used to generate
masks.

> Something that I've used before when working on some architectural  
> rendering stuff (though I'm not sure exactly which app rendered the  
> images) is an object ID pass that includes every object, with random,  
> non-antialiased RGB colours. I presume it generated each colour based  
> on a hash of the object's name or something like that, and in this  
> particular scene there were so many objects I seriously doubt the IDs  
> would have been assigned manually. Anyway, it looked a bit like this:  
> http://mke3.net/blender/etc/obid.png

That case reminds me of the DupliMat proposal, things have to be
reproducible from one render to another, frame to frame, machine to
machine. And a system for scripts/nodes to peek/poke would be pretty
nice in that case, for automatization.

> It was great because I could then go into photoshop and interactively  
> tweak the appearance of individual objects, just by using simple  
> masking. Now that we have the nice chroma key nodes and the colour  
> picker eyedropper, it's extremely easy to do the same thing in  
> Blender - see this node setup:
> http://mke3.net/blender/etc/obid_nodes.png
> 
> The packed file is here:
> http://mke3.net/blender/etc/obid.blend.zip
> - you can see how easy it is to pick other objects to isolate, using  
> the eyedropper, and it's easy to include additional objects just by  
> adding a new difference key and adding the mask on top.

So 3 object mean 3 key and 3 mixer nodes, 10 objects mean 10 key and
10 mixer nodes, that does not scale nicely.

> Doing the object IDs like this would be better since it'd:
> * be much easier to use
> * be more flexible for going back and tweaking things without having  
> to re-render - i.e. currently if I decide later on that I want to  
> tweak some object that I didn't previously assign an ID to, I have to  
> assign it and re-render the entire thing again. If every object has  
> its own random colour from the start, I'm much more free to  
> experiment or change my mind
> * allow people to also do their edits easily in external image  
> editing or compositing apps of their choice too, not just Blender.

ID can be still under user control instead of being random and only
random: it could be a 24 bit number that gets assigned randomly when
new objects are added but still can be manually overriden (as hex /
colour without alpha). In EXR it could be 32 bit integer channel
representing 24+8 padding or maybe just go with 32 bit RGBA. But it
would be mapped internally to float RGB(A) thus being "user visible",
precise and avoid conversions. As result we would get over 16M (4000M)
different controllable IDs.

A single object could be easily identified, but user could do patterns
(easily seen in hex, but also in colour, maybe just more limiting) to
identify groups and then select with a reduced number of nodes even if
the number of objects is huge or go the long way and use a "one by
one" approach or make collections of items with a single ID if he does
not care. Duplicators and particles could be set to share base or
increase mode. Via scripts, user could do batch (re)assign, collision
checks, etc.

Flexible, scalable, useful externally, and the user still in control.

GSR
 
PS: The more I think about it, the more I feel it is highly related to
the DupliMats idea (the ID could be the seed for the randomization,
for example) and should be tackled at the same time, or at least lay
the base for future DupliMats work.