Since the release of luxrender 1.6 I messed a lot with its Bidirectional Integrator. I wonder if Bidirectional Pathtracing would work with cycles. It would make scenes with complex Ligthing (Caustics, Interiors, etc) far easier to render Realistically.
Is that possible to Implement (with gpu rendering) or do people even want that since there are free alternatives like Luxrender or Yafray?
I would Welcome any Opinions on that 
Best regards,
Steffen
The issue with adding bidirectional tracing to Cycles is that it would be very difficult to make it work while maintaining the massive flexibility in shaders that Cycles is known for.
For instance, I have heard before that while Renderman and Arnold have bidirectional pathtracing now, the actual number of cases where you can use it is actually pretty limited.
Thats a pity. I assumed that it would only affect the light paths between the Shaders and not the interaction with the shader itself.
So rendering on the gpu itself is not a limitation? Because all the Renderers ive seen that use bidir are cpu only so i thougt that was the main reason.
would it work as a seperate mode with some dedicated ubershaders? I guess since probably most user wouldnt use it that often it would be a great waste of the developers time.
is it more like a âno thats not gonna happenâ or âmaybe some time in the future it will be addedâ ?
No, GPU is definitely not the issue. The main problem, as Ace already said, is that Cycles allows you to do things that just donât work with BiDir - such as e.g. ray visibility or changing your shader depending on the incoming direction. In general, for BiDir to work, everything has to be fully symmetric, tracing the same path from the other direction has to produce the same path - but if you have e.g. the path A<->B<->C, where A is diffuse, C is glossy and B is only visible to diffuse rays, tracing left to right would hit B, but tracing right to left wouldnât.
So, BiDir in Cycles would be possible, but only with a reduced feature set (no Ray Visibility, no Light Path node, probably even no OSL etc.). It might be introduced at some point, but fragmenting the feature set isnât really that great for usabilityâŚ
And for the record, Arnold doesnât have bidir and Renderman only supports a very small subset of bidirectional techniques, and when theyâre enabled the flexibility of the shot youâre creating immediately becomes very limited in terms of shading and lighting.
Bidirectional path tracing is great for photorealistic and scientific visualization. Itâs pretty dreadful for flexibility though, which is king in production.
Also, as Lukas points out, thereâs technically nothing fundamentally incompatible between bidir and GPUs, but bidirectional tracing is a memory hungry process. All BDPT tests Iâve seen on the GPU use very simple scenes and shading. Adding a ârealâ scene with complex shaders would likely overflow any existing GPU on the market, even more so than unidirectional path tracers do.
Thanks for the Clarification!
Photorealistic Visualization is exactly what Im doing so it would have been great. I will have to use Lux for that and Cycles for everything else.
Also looking for a solution which could make great benefits in realm of caustic and interior renderings with Blender Cycles, have stumbled on implementation of a âStochastic progressive photon mappingâ by Toshiya Hachisuka. For now it can be tested in Lux Classic API (so running only on CPU).
Basically what iâm questioning is, would it also be too dificult to work with Cycles?
Is it OK to continue here or should be made into another thread where all relevant solutions/engines could be exercised, examined and debated? Or is there such a thread already?
In my opinion BDPT is not worth it.
I think photon mapping and final gather would be a benefit for the field of your interest.
I actually donât agree with the obsession of path tracers as if it was the âmake a perfect renderâ button that every modern 3d tool should have. And thatâs why I donât agree with usual render engine comparisons such as âArnold (or others) has this so this is the wayâ.
actually I dont care if its Bidir Pathtracing, Photonmapping or whatever as long as it helps me with caustics and Getting rid of noise
The Reason why I asked about bidir is because it was the method that gave me superior results in Luxrender.
To my knowledge, thereâs only one thing thatâs holding bidirectional path tracing back in Cycles: it needs someone to do it, code doesnât write itself.
The only problem WHY most people would want BiDir, are Caustics most of the time not lightning.
Portals already exist for indoor, so lightning is not a big problem. Caustics still are.
If there would be a way to make caustics good without bidir, i would me more than happy. Has somebody any idea if there are some (good) solutions/papers for that, without bidir ?
Or could there be a pseudo-bidir approach only for the transmission/refraction part ?
Caustics can be separated out (in fact theyâre already separated in Cycles) and done via photon mapping, but then energy conservation and accuracy are very difficult to maintain. Youâd also have to build a photon mapping system inside of Cycles, which honestly wouldnât be that hard. But the uses of caustics in production animation are pretty much non-existent, and the photon mapping method would give questionable animation results anyway that go against the âset-it-and-forget-itâ philosophy of path tracing, and production animation is most certainly the stated goal of Cycles.
Quick overview of interesting Light transport algorithms:
My vote is for GPT to get some Cycles love ;D
Well, i agree to disagree on one thing, caustics are everywhere, from ocean waves, heat, reflections, water, glass, gold, metals, etc.,etcâŚ
Yes, NOW many dont do caustics, it ist true, but once somebody SEES what a good full caustics render looks like, nobody wants to go back.
Seeing the difference between a LuxMLT/PrmanVCM and pathtracing like Arnold/Cycles, and i have to say that once you get good caustics, its really a feeling of âOMG!â, you see all other images like âdry cat foodâ.
And i am not even talking spectral here (MLT), only good RGB caustics.
So, of course i want caustics, they are THE main part of energy transfer over any energy re/de/flecting/fracting surface, and the results are insanely great.
@lukas
wow, thanks for the overview!
i just read this paper: https://mediatech.aalto.fi/publications/graphics/GPT/kettunen2015siggraph_paper.pdf
the MSE is⌠just WOW
Do you thing GPT would be easy to implement, like, is it a big thing (deep rewrite), or only a render kernel âexpansionâ of the existing cycles ?
@ m9105826, lukasstockner97, enilnacs
Thank you all for insights and links. Also do concur, once you get fine caustics in render, is as another big step toward realistic CG imagery. After i saw it in renders (almost a decade ago) it became much easier to distinguish in photo-real quality among artists, scientists - developers and final works.
After reading the paper linked above, GPT does look great. Has there been any Cycles implementation experiment done?
Edit:
Last i worked with caustics on Cycles was experimenting with this scene:
Materials: glass and caustics by Olivier Vandecasteele (article)
Cycles: Caustics and the noise (paper, scene attached)
After a short extrapolation, I realized it would take three weeks of non-stop computing (21 days) to calculate this image with enough iterations to clean up the noise in the caustics. And it would be a compromise: the double having been better! ⌠42 day
:eyebrowlift:
exactly!
In my shed Iâve got some hammers. They all bash stuff but they are all suited to different jobs.
Luxrender is better suited to stills with caustics.
BF/BI has a different focus (for their rightful limits and preferences, just to be clear before an arsehl comes at me for this).
It is not a blasphemy to name it.
Cycles has no focuses since almost everything could be implemented with no conflicts of natures.
Even though Iâm a supporter of âthe right tool for the jobâ phylosophy, and an opposer of the âall in one packagesâ, in this case I donât find conflicts, cause adding GI methods wonât change the nature of cycles or what cycles does. It just gives an option to make cycles do what it usually does, but in a different way.
As for the fact that there are alternatives, Iâll use your example:
Some people find themself more confortable with the handgrip of one hammer and just want to understand if itâs possible to improve their fav hammer to expand its fields of use.
You know, more options, more happy people.
Thatâs not true. Not at all.
Every decision in renderer design has tradeoffs: Modular architecture vs. speed? GPU computing vs. faster development? OSL support or full compatibility with bidirectional algorithms? Huge amount of features vs. well-integrated features working well together? Production rendering or research? Full tweakability vs. user-friendly and fast to use? And so onâŚ
Caustics are not only technically, there is a TON of glass, metal and nearly all materials have a caustics transmission. The only material that has no caustics is a pure diffuse (but even that emits energy to form secondary caustics!)
The subtle but full bath of caustic light, when rendered properly, is encompassing the whole scene. Porcelain, cars, hell⌠even a simple plasic bag, not to mention jewelry and a TON of different opbjects and materials.
In short: EVERY material that has transmission produces caustics due to a IOR higher than 1 or a curvature higher than 0! Missing them is a big thing, that yes, many will put away in their heads, but will see the difference anytime once rendered.
Till MC PT, everything was scanline, many years, everything was âfineâ. But now, no one uses a scanliner if they can get the power of a pathtracer. But not so fast, we are still far, far away from a full light transport solution that is fast enough for the actual hardware (for mere mortals). But once the nexgen hw and renderer will drop in, nobody will step back to unidir PT (like with scanline).
