What is photonGI and please create more mini tutorials for shaders.
3 Likes
Caching of indirect light. It is very similar to the VRay light cache.
Here’s an example:
50 samples without PhotonGI, rendered in 3min 5sec on my notebook CPU:
50 samples with PhotonGI enabled, rendered in 2min 21sec (including 47sec of building the cache):
You can see that at the same sample count, the render is faster and less noisy.
(and it even contains a few more light bounces, because photons are shot from lights, which makes this something like a render done with a bidirectional engine).
@marcoG_ita Thank you for the feedback.
7 Likes
Thankyou B.Y.O.B
I wait for principle/universal shader or similar.
When this change comes I do not have to continue using Corona and Max.
3 Likes
question out of the blue : i understand that you’re a developer of luxcore, i would like to know why not put your effort in a version of cycles with those upgrade ( different GI solution ). i understand that having a personal renderer will give you more freedom and that the BF have restriction but it would have been great to see all of this great things on cycles.
What makes you think that BF is even interested in features like that?
nothing, but i meant for another version of cycles not the cycles of blender, i know that the bf want a path tracer without “biased” techniques
As far as I know LuxCoreRender is not specifically being developed for Blender. If you need a faster Cycles, check out E-Cycles.
When I started working with LuxRender, there was no Cycles.
Now I am part of the team, I like my teammates and I think we work great together, so there’s no reason for me to take up the daunting task of writing patches for Cycles.
Anyway, the author of PhotonGI (and most other features in LuxCore) is @Dade. So you would have to redirect the question to him 
8 Likes
Will be done this month ! Was to busy recently !
1 Like
How about this: Some cycles devs come and help out with luxcore, especially with 2.8 port and new features… 
I think this could be much better solution
1 Like
Sounds good. 
LuxCore could then be fully integrated into Blender, without any third-party add-on restrictions. 
As an artist using Opensource solution you might think a bit differently from my POV. notice this :
How many very good commercial renderer do we have in CG industry ?
Vray / Corona / redshift / Octane /Fstorm / indigo /Maxwell / Thea / Arnold / E-Cycles etc …
How many Very well featured Opensource Renderer Do we have ?
Cycles ? Yafaray ? Applesseed ? Prorender ?
Wich one can better match they commercial counterparts ?
The idea is to not put all Your eggs in the same basket. opensource mean freedom. So let support What can give you more freedom in your Choice …
1 Like
TAO on Luxcore forum just start the bridge For Luxcore To Max. Follow the Development of Luxmax here :
the one thing i still miss in luxcore (and cycles) is a good proxy system.
Not by linking some blend files, but dedicated proxy files, optimally with pre-built bvh-trees as compact ‘physical’ files that can be referenced by a custom blender object and some kind of low-res preview.
This is the one crucial feature if one wants to populate a forest or furnish a high-rise… The viewport should not be the limiting factor for the complexity of a scene. I know there are linked libraries etc. but they are a bit too convoluted for a clean portable workflow + they are problematic with viewport / render visibility and realtime render previews.
I suspect vray uses pre-built acceleration structures inside their vrayMesh proxies. That would explain the near instant geometry preprocessing even with many unique proxy files in a scene.
2 Likes
LuxCore had already lights and materials support for bidirectional path tracing (i.e. adjoint BSDF, light particles emission, etc.). Something required by current “bidirectional” nature of PhotonGI implementation: light cache is built tracing paths both from camera and light sources.
As far as I know, Cycles lacks the support for this kind of stuff (for obvious reasons, they are not required for plain path tracing) so adding PhotonGI support to Cycles would require a lot of work on materials and light sources code (but it could be adapted avoiding is “bidirectional” nature).
In general, I’m against open source fragmentation and in favor on all working on the same project but, exactly for this reason, I could flip the question: Lux has done path tracing (and bidirectional path tracing, metropolis sampling, GPU acceleration, etc.) years before Cycles so why to work on Cycles when you could have adopted Lux, Yafaray, etc. ?
3 Likes
Well, somehow Lux is now ahead of Cycles in terms of speed, but at the time (around 2011) Luxrender was a slow behemot not good for production, while Cycles quickly got the features needed
We had proxies in the old LuxBlend addon, and I am planning to add them to the new addon eventually as well. neo2068 from our team has been working on it for a while, but unfortunately he could not finish it.
You can take a look at the planning in the corresponding issue and see if it would fit your needs - and if not, post your ideas: https://github.com/LuxCoreRender/BlendLuxCore/issues/110
Pre-built BVHs are an interesting idea.
1 Like
And let’s not forget that Lux has been completely redesigned long after Cycles maturity age.
Cycles came out as an engine for making easy and ehm… fast animations, Luxrender paradigm was something like “unbiased, uncompromised high fidelity renders” and its most iconic renders were prisms refracting white light