Re: Render Channels

["Gene Crucean" <emailgeneonthelist(at)gmail.com>]

I just want to clarify a little. I never said that I wanted passes to be removed, or any feature for that matter. And Peter, I fully understand the benefits of passes. The reason I used the default presets as an example is because if they don't work and you can't tweak them... then whats the point of having them?

To be honest, it sounds like you all are thinking about why you can't use them for whatever reason mainly because of it's current implementation. Try and think forward. How would you guys like to see these things done?

Can someone give me a legit reason why they couldn't be implemented like passes? And again, to be clear... in addition to the current pass system. Not replacing it.


-Gene

On 7/30/07, Andy Jones <andy(at)thefront.com> wrote:

I think you're right, Todd.  My understanding is that the benefit of
rendering multiple passes simultaneously sort of goes away as the
individual passes themselves get slower.  I.e., the time you're saving
often has to do with raster space calculations and other "simple"
operations.  So it saves time on fast passes, but doesn't really help
much and can even hurt for slow passes.  There are of course exceptions
to this, like if you're using the same very expensive procedural texture
to drive both a specular weight and a diffuse weight and you want those
broken out as passes.

The challenge is getting the right threshold settings for passes you
break out into the main buffer.  You could argue that it would make
sense to render your AO pass as a pass channel, while rendering a dummy
pass of AO multiplied by texture in the main buffer.  That way you won't
cross the AA threshold as much in the dark parts of the image, where
you're not going to notice it anyway.

Really, the way this should work (for beauty pass reconstruction) is
that passes should be able to render in a specified sequence converging
on the final the composite.  And ideally, it would use mental ray passes
to achieve that at a sample level, rather than a pixel level.  The
artifacts you get from pixel-based beauty pass reconstruction are often
unacceptable.

- Andy

todd akita wrote:

> Hey Alan -
>
> I may be wrong but isn't the sampling for the framebuffers driven by
> whatever happens in the "main" one?
>
> Like say you plug in a phong shader with a really noisy fractal
> texture in the main framebuffer and an AO in the second one, isn't
> what you have is a scenario where you might be potentially tracing
> many more rays than you'd need if you were to render it alone?
>
> Again I may be wrong but if that is the case I am not sure what that
> means in terms of efficiency.  It definitely sounds weird having a
> shader sampled with in adaptive pattern that belongs to another shader!
>
> -T
>
> Alan Jones wrote:
>
>> Things like AO are a
>> different beat - unless your beauty pass shader is already using
>> ambient occlusion, then it should go in a separate pass, as you're not
>> gaining much computationally
>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> unsubscribe xsi
>

---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi