Le 18-02-23 à 14:00, William F Pokorny a écrit :
> On 02/23/2018 10:58 AM, Stephen wrote:
>> Almost the latter. It is one Poser hair mesh. The type that uses 
>> transparency maps.
>> It renders in seconds via PoseRay but when the obj file is imported to 
>> blender. The Pov script took 17 hours and there were still 3 blocks 
>> unfinished.
> 
> Do the results look more or less the same for what is done? Might be 
> interesting if you can hack the Blender version so it is using opaque 
> textures.
> 
> Guessing you didn't get a final 'Max Level' report if it didn't finish?
> 
> A shot in the dark, but one thing I've had happen occasionally since the 
> 3.7 change to not count rays through transparent surfaces toward the 
> 'Max Level' limit is get run-away rays/blocks that take a VERY long time 
> to render. I recall a blob scene in particular - one of the blob-flat 
> arrangements with negative blob texturing for the visible results.
> 
> My best guess as to what was happening was a that small number of rays 
> ended up running right along the 'flat surface threshold' so as to be 
> bouncing in and out of the transparent shape a very large number of 
> times. If I added even the slightest tint/transparency<1.0, render times 
> improved dramatically. I believe with the surface not completely clear 
> the adc_bailout kicked in at some point to stop the run away rays.
> 
> I suspect we got rid of the black spots from such ray/shape skimming 
> situations at the expense of rays potentially bouncing about a long time 
> where the ray / surface relationship is unfortunate and the surface is 
> completely clear. Given what folks usually ran into with the black spots 
> it was a good trade off I think.
> 
> Aside: There was too an old (<3.7) scene that turned run-away as I 
> remember - where previously the scene had counted on the max_trace_level 
> kicking in on the clear transitions for the result. Barbell media sort 
> of thing.
> 
> I did think some about another kind of max_trace_level which would count 
> rays continued through a transparent surfaces at a lessor weight 
> (instead of a weight of zero as in 3.7) so there would still be some 
> limit. Just an untried idea though. I'm unsure whether it would offer 
> better run-away control in practice and it wouldn't come free CPU wise 
> in the general case as underneath we'd effectively have to maintain two 
> counters with the new one for transparent surfaces occasionally adding 
> to the main limiting one.
> 
> Bill P.

For plain, transparent surfaces, where there is no refection nor 
refraction, then, trace_level don't increase. I did not check with irid. 
Don't mather if it's filter or transmit, and the actual colour don't mather.
In all other cases, trace_level increase by 1 each times the ray 
encounter the surface.
So, interior{ior 1.000000001} will force the trace count to increase.
So will reflection{e-12}.
Also, I found that, apparently, adding any colour fading into the 
interior or some media to the object will also cause the trace count to 
increase.

Another way to controll run away rays is to change adc_bailout to a 
slightly larger value than the default. Keep that increase small. Be 
carefull with that one as, in some cases, it may cause some unwanted 
defects.

Post a reply to this message