PhotonGI cache

[happyboy]

No idea, maybe CodeXL helps? As a fallback: printf

haha. I'll try CodeXL, and printf works with GPUs???

The Update() part is used to (optionally) update the caustic cache during the rendering. You can ignore it because it shouldn't be affected by what you are doing.

Thanks! It'll be nice if you can (when you're near a PC with codes) look closer to what I found about the codes. My latest plan is:

1. Still have only one pgi cache (instead of one for each radiance group)
2. Change `Spectrum` into `vector<Spectrum>` for `Photon`, `RadiancePhoton` and `RadiancePhotonEntry`
3. Make sure every photon starts with correct initial vector<Spectrum> in`TracePhotonsThread::TracePhotonPath`
4. Fix every other place that doesn't compile (well, I think it'll include other render engines :-S)
5. Add a test to make sure the beauty channel doesn't change with or without my changes, and that sum of two radiance group channels equal to the beauty before denoising
6. [OCL] Change Photon/RadiancePhoton definitions in pgi_types.cl and changing CPU->GPU transfer codes
7. [OCL] Change pgi related functions in pathoclbase_kernels_micro.cl and probably other files
8. [OCL] Add a test for OCL

Does this sounds good? I hope I can find some time this week to start coding, and try to finish 1~5 this month. So please, if you find anything wrong/suspicious/dangerous, just tell me.

BTW: I should probably check other engines (like tiled, hybrid etc) when I finish all 1~8, but I need to make PathCPU/PathOCL work first

[Racleborg]

Hi

May I ask, is this Photon GI work by happyboy instead of or in support to the current methods for photon GI which Dade has been implementing? I thought that what had been implemented so far was working really well and that everyone was really excited about it.

Apologies if I have misunderstood the situation entirely.

Thank you

[happyboy]

May I ask, is this Photon GI work by happyboy instead of or in support to the current methods for photon GI which Dade has been implementing? I thought that what had been implemented so far was working really well and that everyone was really excited about it.

What I am trying to do, is to make PhotonGI support radiance groups. Before PhotonGI was implemented, you can get lighting from different radiance groups as separate AOVs, which makes post-processing more flexible (e.g. make SOME lights brighter without re-rendering). Many other renderers support this too (like VRay, Corona, Octane, Redshift etc).

Current, PhotonGI doesn't supporting this, I want to make it support radiance groups. I'm aware that many (most?) other users won't need this, so I'll try best to minimize the extra performance/memory cost, but since I'm new to LuxCore, it may take a lot of time to finish So don't worry.

[Racleborg]

get lighting from different radiance groups as separate AOVs, which makes post-processing more flexible

happyboy, thank you for explaining this to me; I think I have a better understanding now

[happyboy]

happyboy, thank you for explaining this to me; I think I have a better understanding now

You're welcome

[happyboy]

Is anyone experiencing PATHOCL crashes after seeing "PhotonGI evaluating best radius"? When manual testing, this happends occasionally, and re-run luxcore with the SAME scene usually fixed the problem. But now I'm running scripts to run luxcore automatically (i.e. batch rendering), this crash happens far more frequently before. However, it NEVER crashed (at least this way) when using PATHCPU.

[Dade]

Is anyone experiencing PATHOCL crashes after seeing "PhotonGI evaluating best radius"? When manual testing, this happends occasionally, and re-run luxcore with the SAME scene usually fixed the problem. But now I'm running scripts to run luxcore automatically (i.e. batch rendering), this crash happens far more frequently before. However, it NEVER crashed (at least this way) when using PATHCPU.

There is a known problem related best radius evaluation and border rendering explained here: viewtopic.php?f=5&t=1109&start=160#p14793

Are you using border rendering ?

The work around to this problem (and to your, if the problem is radius evaluation related) is explained here: viewtopic.php?f=5&t=1109&start=190#p14888

P.S. but are you using Blender or directly LuxCore ?

[happyboy]

Are you using border rendering ?

P.S. but are you using Blender or directly LuxCore ?

Thanks! But what is border rendering? I'm using a program which generates a .scn/.cfg pair and then launch "pyluxcoretool.exe console foo.cfg" with std::system()

And I don't know what do you mean by "run a full image rendering"

BTW: In PATHCPU it never crashed this way, and with PATHOCL is SOMETIMES crashed but sometimes doesn't crash, even with the same scene. Are we talking about the same isue?

[Dade]

Are you using border rendering ?

P.S. but are you using Blender or directly LuxCore ?

Thanks! But what is border rendering? I'm using a program which generates a .scn/.cfg pair and then launch "pyluxcoretool.exe console foo.cfg" with std::system()

And I don't know what do you mean by "run a full image rendering"

In Blender, it is the rendering of a sub-region of the full image.

BTW: In PATHCPU it never crashed this way, and with PATHOCL is SOMETIMES crashed but sometimes doesn't crash, even with the same scene. Are we talking about the same isue?

May be not, can you provide a way to reproduce the problem ? Something like a small python script with a test scene ?

[happyboy]

May be not, can you provide a way to reproduce the problem ? Something like a small python script with a test scene ?

Ok! But currently our scenes are big. I'll try to simplify it or make an artificial scene while still reproducing the issue. Please wait a moment.