End-of-path AOVs

[jon]

Quick question about film outputs. Can AOVs like POSITION, OBJECT_ID, etc., be reported for the end of an eye path, or only for its first intersection?

[Dade]

Quick question about film outputs. Can AOVs like POSITION, OBJECT_ID, etc., be reported for the end of an eye path, or only for its first intersection?

Only the first intersection. The end of the eye path would be quite arbitrary, it would be due to reaching max. path depth or Russian Roulette kicking in, etc.

[jon]

True, end-of-path outputs are useless for compositing, which I assume to be the intent of LuxCore's AOVs. But they're quite valuable in certain types of non-image-forming analysis, for which Radiance is often used (https://floyd.lbl.gov/radiance/rtrace.1.html). It's atypical for high-level renderers to expose this info... but figured I'd kick the tires just in case.

[Dade]

True, end-of-path outputs are useless for compositing, which I assume to be the intent of LuxCore's AOVs. But they're quite valuable in certain types of non-image-forming analysis, for which Radiance is often used (https://floyd.lbl.gov/radiance/rtrace.1.html). It's atypical for high-level renderers to expose this info... but figured I'd kick the tires just in case.

IRRADIANCE AOV is there for replicating Radiance-like applications: viewtopic.php?f=4&t=2142&p=22680&hilit= ... aov#p22681

[jon]

Thanks, Dade. I saw that -- a very nice feature, but not what I'm driving at. There are certain simulation workflows (e.g. calculating annual daylight levels near dynamic facades) in which it's useful to capture explicit intersection data. I imagine this would involve significant surgery on your end. Given the lack of production rendering applications, I also wouldn't expect it to be a high priority.

[B.Y.O.B.]

It sounds like a situation where it would make sense to create your own fork of LuxCore, with these special data-capturing features.

[jon]

Makes sense. Thanks, guys.