 | | | Tag Channels | Tag Channels 2005-06-01 - By Brad Friedman
Back
hrm... if you were to try to compress the tag format in a lossless
manner you'd end up with standard huffman coding as the most efficient.
large swaths of integers with identical values are what its made for.
So your typical zip compression or compressed filesystem would be the
way to go. You'd achieve some very impressive ratios with that kind of
data. I'm racking my brain and I'm not really coming up with anything
else that would do a better job without going lossy. If you do the
coverage solution, you do run into some loss when it comes to a pixel
containing more than 2 objects if I'm understanding it correctly.
Mental Images could go through the trouble of compressing the data
internally in the file format, but they'd take a serious processing
performance hit on decompressing it. Which may not be optimal for
compositing (the flints we ran at school liked to keep everything nearly
uncompressed on a drive array for this reason). It'll slow it down. In
general, thats the balancing act non lossy file formats are always
playing between size and speed. MI leaving them uncompressed as they
are, the choice is yours as to if you put them on a compressed file
system or not. Since its fundamentally the same compression. So once
the files render you could move them to a compressed directory in your
file system and take the compression hit. It would net you the same
performance and size profile you'd get if mental images had made it a
compressed file format. Or, you could leave it uncompressed and get a
little performance boost in trade for the drive space (assuming you have
the bandwidth to take advantage of it).
Likewise though, the trinary mattes will compress very well (equally
well actually) for the same reasons. If you output to a compressed file
format, then they're already compressed. If you output them
uncompressed and put them on a compressed file system you'll get about
the same compression as in a lossless file format.
When you get this low level with bits and bytes thre are no freebies
unfortunately. Thats why my personal preference would be to go with the
solution thats quicker to render overall. Since I do a lot of hair
these days, thats the single pass tag for sure rather than the
multi-pass mattes. I really don't want to keep regenerating those hairs
if I can avoid it.
-brad
Andy Jones wrote:
> Well, the worst thing about the tag files is that they're not
> compressed very well, so rendering 3x oversize tags can quickly fill
> up a file server, not to mention the additional file i/o bandwith
> usage. (That's not to suggest that multiple puzzle mattes don't have
> the same problem). This doesn't really have anything to do with the
> academics of the argument but in practice it makes a big difference.
> That's why the coverage thing is really key, so you don't have
> enormous files. We should all start asking for it from Softimage, as
> well as a consistent object tagging scheme (I haven't tested the
> inconsistency myself, but I assume it does exist. I'm also assuming
> it's a SI problem not a MR one). Like Alan mentioned, it's probably
> possible to enable the coverage fb from a geometry shader, but it
> would still be nice to just have a little checkbox. It would also
> probably be worth looking into an output shader to stick the coverage
> information in the alpha channel of the tag file and allow the tag
> file to be output in the file format of your choosing, since not all
> software supports .tag files and converting is a pain in the butt. It
> would also be good to not have tag files and other buffers always
> tossed into the same directory as the rgba buffer.
>
> This is another example of a really powerful feature of Mental Ray
> that doesn't quite have a solid implementation in SI yet. I'm not
> complaining -- I'm just saying we should make an effort to encourage
> SI to unlock whatever potential Mental Ray offers us. Otherwise the
> features sort of go to waste. In general, XSI makes the connection to
> MR so seamless, I think we sometimes tend to forget it's a whole
> separate program with its own new features and capabilities to get
> excited about.
>
> -Andy
>
> Brad Friedman wrote:
>
>> Just for fun of the academic argument:
>>
>> If you were going to go the tag route and you made your matte pass
>> three times the size of the beauty pass, you'd have a block of 3x3
>> pixels in the tag pass for each pixel in the beauty pass. Each pixel
>> can either be part of the tag you are isolating (1) or not part of it
>> (0). There are a total of 9 pixels in the tag block. Resulting in 9
>> bit precision or 512 possible gray values for the 3x3 block, or
>> beauty pass pixel. Which is more than you usually need (8 bit
>> usually suffices). You could go 4x the size and get 16bit precision
>> if you really wanted.
>>
>> If you break it down into puzzle passes and use the really clever
>> Trinary Tree solution Andy writes about, you'd have 9 trinary passes
>> in total for one 3x sized tag pass (by resolution and theoretically,
>> by file size as well). That would be 3^9, or, 19683 possible
>> isolated objects in the same resolution/file-size usage.
>>
>> I'm not sure how many object indexes can be stored in a single tag
>> pass. If its 24bit, then it would be 16777216. If its 16bit, 65536.
>>
>> If you render Trinary passes, then the geometry is recalculated for
>> each pass (this could take a lot of resources if you have a lot of
>> hair, or particularly heavyily deformed geometry).
>>
>> If you render a tag pass, your sampling (its faking subsampling
>> afterall) is uniform rather than adaptive. However your shaders are
>> all simple surface shaders and the sampling should be set to 0mix
>> 0max. But if you have a need to get some fancy shading going on in
>> your matte pass (why would anyone do this? Can't think of a reason)
>> your render time might go up.
>>
>> Ignoring for the moment that its possible the tag values change in
>> the middle of an animation sequence (I've still not confirmed this
>> but I'd to run tests to find out), then both of these techniques seem
>> reasonable in different situations. Infact, they're quite similar.
>>
>> I suppose it would be really slick if Mental Images iterated their
>> concept of a tag file to include the data from the adaptive
>> sub-samples inside a pixel to avoid the uniform oversampling. It
>> would save some HD space. But I'm not so sure the file size is so
>> unmanagable compared to spitting out multiple matte passes.
>>
>> Anyhow, as I said, its an academic argument. Its not production
>> proven. Carry on :) I'll make production worthy arguments when I
>> get closer to graduation :P
>>
>> -brad
>>
>> Andy Jones wrote:
>>
>>> If you're smart about it, you can use each puzzle matte pass to get
>>> 3 times as many mattes for your objects. First divide the scene
>>> into three partitions with different colors, red, blue and green.
>>> Then, for your next puzzle matte, divide the objects in each of the
>>> earlier three partitions into three colors, and so on for each
>>> additional pass.
>>>
>>> Then, to extract the mattes, you extract channels and use minimum
>>> operators to narrow down what the matte cuts out with each node.
>>> I.e., first you have a third of the scene, then a ninth, and so on
>>> for each minimum operation. So, you get 3^N mattes from N matte
>>> passes. With four matte passes, you can get 81 mattes. Or if you
>>> use the raw and alpha trick, you can get 256.
>>>
>>> I think for the Tag channels pass, there's supposed to be a way to
>>> get coverage information. I always thought it was supposed to be in
>>> the alpha channel, but I seem to get all white alpha channels.
>>> Anyway, if it worked, the coverage information would give you the
>>> percentage of the pixel that was covered by the most prominent
>>> object and you can use that to generate an "more" anti-aliased
>>> matte. I think you could also dilate the matte you get from
>>> selecting the color and invert the coverage wherever the selected
>>> color wasn't the most prominent tag in the pixel to get nice alphas
>>> for objects on pixels where they aren't the dominent object. In
>>> theory, something along those lines would give you a perfect matte,
>>> except where three or more objects were sampled in the same pixel.
>>>
>>> I'm pretty sure coverage is one of the frame buffers in Mental Ray,
>>> so maybe it would be possible to write out that data in an output
>>> shader if there's not another way to get it working.
>>>
>>> -Andy
>>
>>
>>
>>
>> ---
>> Unsubscribe? Mail Majordomo@(protected) with the following text in
>> body:
>> unsubscribe xsi
>>
>
> ---
> Unsubscribe? Mail Majordomo@(protected) with the following text in
> body:
> unsubscribe xsi
---
Unsubscribe? Mail Majordomo@(protected) with the following text in body:
unsubscribe xsi
|
|
|