Hmkay 
Just to get the picture (and a chance to correct me if Im wrong), currently lighmass computes lighting, ignoring swarm here, like this:
- Take a list of all mesh objects to include (scene data)
- Each item is processed by an individual thread
The thread does:- Calculate the direct lighting.
- Calculate the contributed indirect lighing from other meshes in the scene
- Repeat previous step as per number of bounces
- Provide results for gathering
The problem is now that when a thread calculating lighting for mesh A and checks for indirect lighting data from another mesh B, it depends on how far other threads have progressed with their bounce calculations that indfluence mesh B.
Thus, mesh A nd B might be subjected to a similar environment and no seam is expected, but this kind of race condition makes the calculation off.
My idea would be to make the multi threading bounce based, not mesh based.
As a high level sketch:
- Take a list of all mesh objects to include (scene data, like above)
- Derive “Bounce lists”. One for each bounce, which just describes ray geometry in terms of surfaces, a bit like light transport notation (see below).
- The bounce lists are processed in sequence, starting with bounce zero (direct lighting) and then all subsequent bounces
- Each item of a bounce list is processed by a thread that uses the LTN data and surface information to calulate the lighting
The key point here is that all calculations for a specific bounce are completed before any next bounce is calculated.
The order in which the threads process the items of a particular bounce list is irrelevant, thus not creating artefacts
Just my 2 cents on this.
Keep in mind: Its a very high level description. There are some more details to work out.
Cheers,
Klaus