What are the light path expressions and how to use them?

[PIXELBOX_SRO]

Hi all,
sorry for the amateur question but i have never came close to this tech so i would please love to hear from the creators and/or more experienced users how to make advantage of LPEs and in what situations they are good for? Any visual example, link would be really appreciated!
cheers
M

[PIXELBOX_SRO]

https://docs.chaosgroup.com/m/mobile...#page/62452854

found this but still not very clever from it

[^Lele^]

For normal situations, you'll hardly need them.
For example, standard compositing to rebuild a beauty happens without the need for LPEs.
If, however, for whatever reason you needed to extract something very specific happening along a ray path, then they allow to precisely select what to store in the render element.

Say, you want to extract just the diffuse component which has refracted at least once.
Or the fourth specular bounce, or all the specular interreflection up to the third, but no more.
Or just the emissive part of a volume.
The list is nigh endless.
EDIT: I'd be remiss if i didn't mention the matting capabilities.
All of the above can be combined with node names.
So the second diffuse bounce which has been refracted twice of object myGeo01.
I have already made very good friends with black in my REs.

They are exceedingly powerful, and have been a staple of competitors like RenderMan and Arnold for a while now.
This to say, they have historically not been used outside of big VFX studios, as very few other kind of user cases will find themselves needing this level of control.

You can play starting with the presets for now, editing them to see if you can get what you'd like to work, while we prepare more documentation and perhaps some tool to ease building the expressions.
Notice the full breadth of functionalities is guaranteed only with a fully-BF render.
Some things won't work with the LC, nothing at all will work with the IRMap.

Finally, it's well stated in the docs but it's worth mentioning: LPEs will be slower than their counterpart REs.
If you need a standard Specular pass, use the provided RE, not the LPEs, if you care about rendertimes.

[PIXELBOX_SRO]

Thank you for detailed reply, Lele, looks indeed very powerful. I can see some usage scenarios in some of our projects.

[^Lele^]

To complete some of the background history on LPEs, originally they were theorised by Paul Heckbert in this paper, in 1990.
They were further refined by Eric Veach in his PhD thesis (in 1997), chapter 8.
Later, Sony picked up the baton and ran with it in Arnold, thanks to Alejandro Conty.
They also then included them in the OSL specification, which is what we drew inspiration from.

[Muhammed_Hamed]

Thanks for explaining this!
It is clear on how this could be used.
Would be great to have that on the documentation page when it is live.

[fixeighted]

Could someone elaborate by mentioning a real-world example of a practical use of this?

[^Lele^]

You can combine a multi-matte, and a specular pass, f.e., in one single RE.
You can get anything that has gone through refraction without additional passes rendered.
You can extract only the emissive component of a volume.
You can do exactly what the LightSelect REs plus the lightmix does, but in post.

[gandhics]

Ah.. :LPE... i know it is powerful.
I wonder how many max user would use.
Max user always need buttons and checkboxes.

[fixeighted]

I think many users would, once they understand the particular abilities of any new advance.
When that advance is seemingly only for those users who are in a specific production environment,
or who don't have the same level of technical expertise regarding 'under-the-hood' technical parts
of the software, that advance can seem inapplicable to their workflow unless they can apply it to
some ongoing real-world project, see the benefit and thus more thoroughly understand how much more
they could employ its use.

So, to reference what Lele mentioned; what use exactly would there be in having
'' just the diffuse component which has refracted at least once.
Or the fourth specular bounce, or all the specular interreflection up to the third, but no more'' ?

[^Lele^]

I think many users would

I can't speak for anyone.
Old workflows still work, so no one is forced to change.

So, to reference what Lele mentioned; what use exactly would there be in having
'' just the diffuse component which has refracted at least once.
Or the fourth specular bounce, or all the specular interreflection up to the third, but no more'' ?

Nothing at all. It's an abstract example of the LPEs capabilities (all that stuff is currently not achievable.)
You must have missed the post here:
https://forums.chaosgroup.com/forum/...23#post1072823

[fixeighted]

Ah ok it's abstract. I like abstract. I'll keep an eye on the post to see if anyone finds a cool use for some of this - I'm sure there are some good ones.

I guess I only asked the original question as you mentioned that historically this had only been in use in big vfx houses, so was curious as to what they had used it to achieve.

I didn't miss the post btw - it's this one

[^Lele^]

They are exceedingly powerful, and have been a staple of competitors like RenderMan and Arnold for a while now.

This is a known fact.
It's also because those softwares had a *very* different approach to multi-layer rendering and compositing through AoVs (which are not exactly like the REs in V-Ray.)

This to say, they have historically not been used outside of big VFX studios, as very few other kind of user cases will find themselves needing this level of control.

AoVs allow the output of *any* variable type, as the name suggests.
So in shows i could store in a single AoV object IDs, materials and layer of all the objects in the scene, for compositors to be able to select it by, f.e. name or material type, or simply by picking it in the rendered view.
A decade before cryptomatte made its appearance.
The method has however drawbacks: selections aren't perfect, the passes for these need double sized rendering, AoVs often have to be specifically coded from a software's API to fit a specific pipeline's needs, and the same has to be done on the compositing side to create UIs for compers to be able to input values and get back results (I want the object "wheel*", from the layer "background cars", with the material "muddy tyre". Because it needs a lift of the blacks and a desaturation. Across a 500 frames sequence with a wildly moving camera.).

LPEs go a significant way into simplifying this, because there won't be a need for a coder to write a specific RE to output, and a specific gizmo (tool) to read and make sense of the incoming data in post.
You can simply stack up REs and split these kind of attributes from within the 3d app (f.e. objects can share a label. Materials can be selected by name. Layers can be Split by REs. ) so that compositing gets the precise result they'd like, without having to resort to circuitous loops, or double-sized rendering.
Requeueing a sequence to get LPEs out is *vastly* more economic than the setup described above, particularly, once again, for those realities with vast amounts of compute power sitting idly (f.e. during the day.).
You rendered your Temps, it gets picked up by your compositor which sends you notes. Build the LPEs they need, requeue for semi-final with low priority.
All this, because in VFX from a certain size up, the bulk of the work is very often done in post, not in 3d (i think joconnell may have more relevant, up-to-date info on this.), because of flexibility, iterability, color management, and so on.

Further to this, the same set of LPEs used in Clarisse, or Arnold, or RenderMan, or Houdini will work with V-Ray (likely, with minor syntax adjustments), which makes for vastly better workflow, and loads less head scratching from LnR and pipeline TDs.

There will be tools aimed at helping with the building of LPEs, of course.
It won't change the fact that dropping REs for LPEs is likely needless, and would be slower, for smaller realities.

I joked about making friends with black REs, but in production it's no joke at all: debugging the LPEs behaviour and ensuring the output you want is the one you get isn't trivial, and takes time even to the experienced ones.
You can ask, in other words, for that data which has been refracted exactly twice (because it's behind a thick glass), but there is no guarantee you'll get it, as that's determined by the camera and what it sees on a given frame.
At an angle, it may refract three times, or four, and you'd get black there (again, artificial example. But there are countless such ones.).

Much quicker, and effective, to drop a LightMix RE, a few multimattes, and take it from there.
At least until one needs precisely that type of matte which can't be created through the usual means.
Then one has the option to use LPEs.

A google search on "Light-Path Expressions" will provide you for countless tutorials, samples and documentation from everyone else but me.
Feel free to peruse them.

[fixeighted]

Thanks for that Lele. Concise and informative with just the example types I was suggesting. Your work here is done!

You're correct of course; LightMix and crypto and whatever else specific is more than enough for e.g. myself and so I'll leave those tutorials alone for the time being

[^Lele^]

There are very good reasons why that is so.
The framework to get, f.e., material selects, lightSelect, and so on are shared with LPEs.
You could consider them pre-baked, optimised LPEs, to all intents and purposes.
And, in most cases, the logic operations one can do with those REs in a Post program are identical to those one can write inside an LPE.

LPEs, thanks to their open-ended nature, just take things a bit further.
But with very high customisation, also comes high complexity, which is precisely the catch with LPEs.