On 23/02/2018 19:00, William F Pokorny wrote:
> 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.
> 
Lighting and tinkering with the textures considered. Yes it looks similar.

When I switch off the transparency uv mapping. The scene renders in 2 
seconds. With transparency switched on. I stopped the render at 18% 
after 20 minutes.

> Guessing you didn't get a final 'Max Level' report if it didn't finish?
> 
Well, I cut down the mesh until it was just displaying the slowdown and 
PovRay returned a value of 1/5

Although looking at the actual mesh it looks like layers of curved 
planer meshes. 77, I counted them.



I don't understand the low Max Level.

> 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.
> 

For the adc_bailout to noticeably affect the time. I had to change it to 0.4
I did not expect it to go that high before having an effect.

> 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.
> 

I wouldn't start on that for this problem. I've read that Blender's OBJ 
importer has some problems with Poser meshes. And mr is looking at 
Blender's PovRay importer. If he can get that working the Blender 
importer can be bypassed. (No pressure MR :-) _

> Bill P.


-- 

Regards
     Stephen

Post a reply to this message