Re: Render Channels

["Axel Akesson" <axel.akesson(at)gmail.com>]

That would be really sweet indeed... kinda like Magic Lights > http://www.renderman.org/RMR/Publications/sig06.course25.pdf.gz

On 7/30/07, Alan Jones <skyphyr(at)gmail.com> wrote:

Hi Todd,

> I may be wrong but isn't the sampling for the framebuffers driven by
> whatever happens in the "main" one?

Yes - that's correct (as of MR 3.5 at least - I believe that sampling
will be able to be triggered by framebuffers in future versions).

> 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?

It is possible that this would mean some shaders would be evaluated
more - i.e. the sampling pattern could differ. So yeah - there are
possible scenarios where it would be increasing the workload - though
it would be difficult to get a scenario where framebuffers should have
been used, but the cost was so significant that tessellation etc were
a lower overhead than the additional calculations.

> 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!

Yep - though I'm not sure that the new version will improve this issue
- in fact it may make it worse as the sampling would be worst case for
all of them. So everything would be sampled as much as is required for
any other framebuffer.

I saw people asking about separate framebuffers for each light. This
is kinda doable (though not without some custom work at the moment).
You can't dynamically define framebuffers part way through a render
(as far as I'm aware). So you'd need to define the framebuffers for
all the lights first. Then you've got a couple of options.

You could program an illumination shader to store into each of these
framebuffers. So one per light. Or you could make the shader pass
custom light lists to each illumination node and then push that into a
particular framebuffer in the rendertree. For the second suggestion it
might be nice to ask Soft to make the light list a dropdown which
defaults to all lights, but is intelligent enough to pick up groups in
the explorer (which have lights in them). So this way you could just
create groups for lights and then the illumination node could just
select which lights to use. I kinda like this more than the current
setup for grouping lights to objects. It would allow you to do what's
done at the moment, or alternatively have different lights for
different parts of your material - which could be really sweet.

Cheers,

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