PRT Volume Channels...

The PRT Volume object makes a lot of channels for the points. Are those only generated as needed, or are they all evaluated and then later tossed? Seems to me that 90% of the time, we’re only using the position channel, and ignoring things like normals, mapping, and signed distance. If those are in fact being generated, would it be reasonable to have checkboxes or something to allow us to optimize for what we actually use?

Yes, 99 mapping channel checkboxes is excessive, but other than that?

  • Chad

I try to follow the C-style “Only pay for what you use” mentality. The PRT Volume exposes a list of channels it can fill, and only fills those if an up-stream operation is asking for that channel. If you write a KCM that asks for the Normal channel it is going to fill it in. Also the renderer might request a channel, for motion blur, phong shading, etc.

Its not too smart though, since it will fill the Normal channel in even if an up-stream operation clobbers it with a non-dependent value.

Hadn’t considered that. Does it fill it whenever the renderer asks for the normal (phong, env reflections) or only if the KCM also has a normal channel input (which might get clobbered)?

  • Chad

The strategy our objects take is to fill any channel (that the “current” operation has a useful value for) if somewhere an operation closer to the renderer requests it. If you enable Phong shading, and have a KCM that writes to the Normal channel from a texmap, the PRT Volume with dutifully fill in the Normal from the volume even though it gets overwritten by the KCM.

Did that answer the question?

Example of how the channels get figured out:

From bottom to top:

  1. PRT Volume offers channels Y,Z,W
  2. KCM Offers channel Y

From top to bottom:
3. Renderer requests channels X, Y, and Z
4. KCM sees request for channel Y, so it enables writing to channel Y
5. PRT Volume sees request for channel Y, so it enables writing to channel Y

Yeah, that explains it. Thanks. My question was backward, but you understood anyway.