From an outside perspective it seems unlikely. I doubt they’d turn down a good implementation from the community but the work involved in that is monumental and the number of people capable and willing to do it are very few.
2 Likes
So I asked Dade (LuxCore main dev) about Light tracing, I won’t post his answer here directly.
However I learned a pair of things regarding from dade’s answer.
-
Light Tracing is a simplified BiDir algo created by him
-
For Light Tracing to work under Cycles, Cycles would need to support BiDir in shaders / lights / cameras / film and that’s a big amount of work just to support Light Tracing.
-
The actual Light Tracing algo is fairly “simple” to implement for someone with rendering programming knowledge and Dade could explain it to anyone with knowledge in 15 minutes but without BiDir support it’s not possible to implement in Cycles.
So before we can have something like that it seems we actually need Cycles to support BiDir no matter what 
P.S. If anyone is interested in Dade’s actual answer here is the link:
10 Likes
So… Light Tracing is not really a simplified alternative to BiDir, but rather, something you can do after you have BiDir? Like roller coaster is not a simplified version of amusement park, but rather, something you can do after you enter the amusement park.
I guess that means it is out of the qustion for Cycles then.
Also it is scary to think that BiDir would break Light Path node. I still haven’t found a way to turn off an object’s shadow in LuxCore. It just sounds scary.
Not exactly, you don’t need bidir, but you need shaders/lights/cameras/film to be prepared for bidir, after that Light Tracing is an intelligently simplified version of BiDir
To follow your roller coaster simil, you need the cart, the rail and the electricity, but you don’t need a single curve or looping, just a plain 10 meter long rail 
2 Likes
Oh okay. But my concern is mostly about breaking the Light Path node.
However this is true because materials, light sources, cameras and film infrastructures support tracing light backward and forward
I am not sure if this process would break the Light Path node or not. If this doesn’t break it, it surely looks like it is nice to have if someone shows up and take the job. But if it still breaks some existing features in current Cycles, I am just not sure if it is worthy to work on.
Ah I see. But it would still be useful even in an experimental branch because if somehow bi directional or any form of new rendering system were to come then cycles might be left behind and could take time to catch up since as you said it has to change the shaders to accept bi directional. And if blender keeps adding new nodes then the chances of getting bi directional keeps getting smaller and smaller. I honestly think bi directional would be good in the long run but I think there are alot of points I’m missing because I do not code so I’m in uncharted territory and I have no clue if what I said is relevant to some extent. So if someone can understand/correct my statements it would be greatly appreciated.
I believe it necessarily would. The light paths currently only look a single bounce into the past, right? And that’s rather efficient.
To get the same sort of light paths on a light-traced ray, you need to look one bounce “into the future”. So you need to do an extra bounce. And then, based on the light path property, you might decide to throw that away regardless and have to start over, picking a different one. I think that’s how it works anyways.
Though if you could somehow make this efficient, it’d also open the door for new ray types. Ones that depend on the next thing you hit instead of the previous one. (Since that’s the “natural” thing to consider for light-traced paths - they exchange what’s previous and what’s next relative to camera-traced paths)
1 Like