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.

Post a reply to this message