[Sidefx-houdini-list] deep primid aov?

Matt Estela matt.estela at gmail.com
Sun Aug 17 22:48:28 EDT 2014

Aha, Matt Ebb solved this with some crazy technique called 'reading the

We were unpremultiplying the samples by rgba.a, which is silly, that's
gonna be the alpha _after_ the samples have been collected into a flattened
pixel. I kept seeing these other channels floating about, turns out they're
the opacity per-sample. So, in a deep expression node you divide your value
by the per-sample alpha (also convert to raw int to get around precision

rint(primid.r / other.RA)
rint(primid.g/ other.GA)
rint(primid.b / other.BA)

Then do whatever expression you want, eg, isolate the primid based on the
frame like in eetu's example:

primid.r == [frame] ?  other.RA  : 0
primid.g == [frame] ?  other.GA  : 0
primid.b == [frame] ?  other.BA  : 0

Then you can flatten it with deeptoimage, and use it as a matte to drive 2d
colour corrections (we had to insert a few unpremult/premults to get the
edges perfectly clean)

Will update the odforce thread with hip files and nuke scripts and images
soon. Pretty cool being able to colour correct a motion blurred element
tangled in amongst other stuff!


On 14 August 2014 19:28, Matt Estela <matt.estela at gmail.com> wrote:

> We had some progress on this; seems you have to either use the micropoly
> mode or turn off stochastic transparency, you get render glitches
> otherwise. In this way we could render a solid green plane with a
> transparent red pane on top, and isolate them by depth. Pretty cool.
> We then tried the same with id mattes, mostly worked, will try a few more
> things tomorrow. Will collect results and post to odforce when we have a
> good suite of examples.
> Btw, the deep exr output is very twitchy; easy to create a combo of
> options that shuffles channels into invalid states; red channel gets
> blanked, other channels go strange etc.
> -matt
> On 14/08/2014 6:56 PM, <eetu at undo.fi> wrote:
>> Hey Rangi,
>> That's where the beauty of deep data comes in! The aov values, as well as
>> color and opacity, are stored _per_sample_, not per pixel, and that's why
>> it works.
>> In nuke you can just select all samples that have a given id value
>> (plus/minus a float epsilon..), and remove them or create a mask channel.
>> Matt: Apologies if the example scenes don't work at the moment, they were
>> created with then-current versions of Houdini and Nuke (Dec 2013), and the
>> deep handling has been changing a bit in both, I guess.
>> eetu.
>> (apologies if this shows up twice, I didn't see my first try coming
>> through, now trying with different from:address..)
>> On 2014-08-14 06:26, Rangi Sutton wrote:
>>> Hey Matt,
>>> I don't think it can be tackled like you're describing.
>>> If you say the value identifying the object is  "5", how does the deep
>>> map
>>> say it's 40% of 5 if it's not saying it's "2"? It needs two bits of info,
>>> the fact it's "5", and the fact it's "40%".
>>> You'll need a separate channel for each component you want to be able to
>>> separate, so you're back to multiple AOVs.
>>> Or you embrace that you're working in deep land and render a separate
>>> pass
>>> for every object and deep merge the lot.
>>> ID passes where values rather than channels are used to seperate the
>>> objects is a hack that falls over wherever any sorts of transparancy,
>>> including anti-aliasinng or motion bur, comes in to play. Making it deep
>>> just amplifies the problem.
>>> Cheers,
>>> r.
>>> Rangi Sutton
>>> VFX Supervisor
>>> Cutting Edge
>>> On 13 August 2014 12:38, Matt Estela <matt.estela at gmail.com> wrote:
>>>  Short version:
>>>> Outputting primid as a deep aov appears to be filtered to nonsensical
>>>> values, is that expected?
>>>> Long version:
>>>> Say we had a complex spindly object like this motorcycle sculpture
>>>> created
>>>> from wires:
>>>> http://cdnl.complex.com/mp/620/400/80/0/bb/1/ffffff/
>>>> dad2da95038d2c19ee6f7207eacf5e0c/images_/assets/CHANNEL_
>>>> IMAGES/RIDES/2012/04/wiresculpturerides01.jpg
>>>> Comp would like to have control over grading each sub-object of this
>>>> bike,
>>>> but outputting each part (wheel, engine, seat etc) as a separate pass is
>>>> too much work, even outputting rgb mattes would mean at least 7 or 8
>>>> aov's.
>>>> Add to that the problems of the wires being thinner than a pixel, so
>>>> standard rgb mattes get filtered away by opacity, not ideal.
>>>> Each part is a single curve, so in theory we'd output the primitive id
>>>> as a
>>>> deep aov. Hmmm....
>>>> Tested this; created a few poly grids, created a shader that passes
>>>> getprimid -> parameter, write that out as an aov, and enable deep camera
>>>> map output as an exr.
>>>> In nuke, I can get the deep aov, and use a deepsample node to query the
>>>> values. To my surprise the primid isn't clean; in its default state
>>>> there's
>>>> multiple samples, the topmost sample is correct (eg, 5),  the values
>>>> behind
>>>> are nonsense fractions (3.2, 1.2, 0.7, 0.1 etc).
>>>> If I change the main sample filter on the rop to 'closest surface', I
>>>> get a
>>>> single sample per pixel which makes more sense, and sampling in the
>>>> middle
>>>> of the grids I get correct values. But if I look at anti-aliased edges,
>>>> the
>>>> values are still fractional.
>>>> What am I missing? My naive understanding of deep is it stores the
>>>> samples
>>>> prior to filtering; as such the deepsample picker values returned
>>>> should be
>>>> correct primid's without being filtered down by opacity or antialising.
>>>> Stranger still, if I use a deepToPoints, the pointcloud looks correct,
>>>> but
>>>> I'm not sure I trust the way it visualises the samples.
>>>> Anyone tried this? I read an article recently were weta were talking
>>>> about
>>>> using deep id's to isolate bits of chimps, seems like a useful thing
>>>> that
>>>> we should be able to do in mantra.
>>>> -matt
>>>> _______________________________________________
>>>> Sidefx-houdini-list mailing list
>>>> Sidefx-houdini-list at sidefx.com
>>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>>>>  _______________________________________________
>>> Sidefx-houdini-list mailing list
>>> Sidefx-houdini-list at sidefx.com
>>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>> _______________________________________________
>> Sidefx-houdini-list mailing list
>> Sidefx-houdini-list at sidefx.com
>> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list

More information about the Sidefx-houdini-list mailing list