> On 9/25/19 7:03 PM, Alain Martel wrote:

>>
>>> Aside: Since you have multiple lights... Christoph added some 
>>> parallelism when shooting photons based upon each light source. Long 
>>> wondered how much we might speed up photon generation on a large 
>>> machines like yours by creating multiple, near duplicate light 
>>> sources where each light source sits today. My bet is it would speed 
>>> up the photon shooting step quite a bit if you have the cores - and 
>>> slight offsets in the near duplicates might help the deposited 
>>> distribution some. Would have to manage/adjust intensities for the 
>>> multiples. If your interested in some experimentation, I'd be 
>>> interested in what you find.
>>>
>>> Bill P.
>>
>> It's not a good idea to duplicate lights. It's even worst in a photons 
>> scene as the photons from the duplicated lights will be shot in the 
>> same pattern and end up in the same locations = more photons, but same 
>> end result.
>>
>> It would be better to use area_light and add photons{area_light} to 
>> it's definition.
>>
>> This also tend to make photons more fuzzy, which may help hide the 
>> graininess.
>>
> 
> Thanks for bringing up area lights with photons! Something I forgot in 
> the moment was available with photon shooting. I've also got in my head 
> there are some limitations when used with photons and I do not believe 
> area lights will help much with photon shooting speed. The results as 
> you say though are perhaps better / more fuzzy.
> 
> I did a poor job describing my aside about creating more light sources. 
> Given how many photons are getting shot for a good result, my bet is 
> photon shooting dominates the render time. The parallelism added was 
> primarily by light source IIRC. To maximally use this photon shooting 
> parallelism you need more light sources up to the number of effective 
> cores you've got(1).

The parallelism come in effect every time you have more than a single 
target or light sources.
The potential threads count is (NumberOfLight * NumberOfTargets)

Two light and four targets mean that you can use up to 8 threads.

> 
> Yes, you must split lights smartly - which is what I was trying to hint 
> at with the 'near duplicate' / 'slight offsets' wording.
> 
> Part of what I think is driving the need for so many photons in 
> Norbert's scene is there are long vertical cylinders or cylinder-like 
> portions of sors(2). The spiral shooting pattern crosses those only 
> occasionally so it's likely going to generate bursts of deposited 
> photons at each crossing - this likely effect is a candidate contributor 
> for the graininess of the deposited photons.

In that case, it may be interesting to split those long objects into a 
string of shorter cylinders, or avoid shooting any photons at them.

> 
> So, my thinking for creating additional light sources would be say to 
> split each of the existing 4 light sources into 4 each for a total of 16 
> sources. Each set of 4 would be spaced vertically so the spiral patterns 
> of each are offset; the intensities/4; the global photon spacing/4. It 
> might make sense to do area lights on top of this - but there is already 
> jitter as we spiral and shoot.

An area_ligh of 1 by 4 would be better as you'll benefit from area_light 
optimisation.

> 
> Aside: Something else which can create fuzzier results is to override 
> the automatic gathering radius - make them larger. There are too some 
> sampling counts that can be adjusted but I don't remember details. I 
> think you can specify values for the target specification too other than 
> 1.0 though never played with it.
> 
>  > Also, avoid using sor with the open option. This is particularly
>  > important with any object with an ior.
>  > When you encounter a single surface, light get bent once. If you
>  > encounter two surfaces, it is like the object is solid thorough.
>  > You need to actually model the inner side of your object by backtracking
>  > to the start point and shift your points slightly inward.
>  >
>  > The open option should never be used with any transparent object, no
>  > matter what primitive is used.
> 
> I go along with what you've said up to this last 'never' rule. Never 
> using open with media containers is a good rule. If we are just talking 
> about transparency and want a visual effect and not physical accuracy, I 
> think using opens are OK. What matters is whether the shape supports an 
> inside-test/interior where the ior is tracked, and sors do.

Ok. Never UNLESs you actually want to create some special effect.
Insert a comment in your code if you do that to explitely tel your intent.

> 
> You can use open objects with a defined inside / interior in csg and 
> that single surface can create refracted rays. Might not correspond to 
> any real world thing, but for effects, why not. You can also put such 
> single surfaces together to form other 'complete/closed surface' 
> transparent/ior/media supporting objects.

You can have a single polygon or triangle that is transparent and have 
an ior. It will refract light.

> 
> Lastly, if we want to go deeper, 'open' with sors is itself fuzzy. The 
> user with their point list can effectively close a specified 'open' 
> shape by taking the curve at one, or both, ends back to the origin. In 
> such cases any 'open' gets ignored though having it might help 
> performance as the cap tests can be avoided immediately. Further, rays 
> which intersect only with the sor's sides are effectively sor-closed no 
> matter the sor having actual ends or not.
> 
> Bill P.
> 
> (1) - Might there be a place for photon shooting only light sources. 
> Used only to deposit photons and not after..?
> 
> (2) - There are other ways to increase the photon shooting densities on 
> such shapes - breaking them more box or sphere like parts and not 
> turning off split_unions(3)
> 
> (3) - Spot lights / cylinder lights can still largely miss when doing 
> this kind of thing. Gets complicated to optimize. In the long term might 
> other photon shooting methods / patterns help? Something like the 
> user_defined camera / pigment capability but in a light source with 
> respect to shooting photons. Letting the user specify the shooting 
> patterns they want.
>

Post a reply to this message