I know it is a bit late in the day to ask. But I never got round to it.

I understand Max Level: but not the relevance of Smpls/Pxl:

Ray—>Shape Intersection and Shadow Ray Tests:

What if anything, are they telling me?

I have a mesh that when rendered using Blender's Pov exporter. Renders 
so much slower than when rendered using PoseRay. I cut it down a bit and 
the Max Level: was 1/5. So that shot down one theory. :-(

-- 

Regards
     Stephen

Post a reply to this message

Le 18-02-22 à 07:45, Stephen a écrit :
> I know it is a bit late in the day to ask. But I never got round to it.
> 
> I understand Max Level: but not the relevance of Smpls/Pxl:
> 
> Ray—>Shape Intersection and Shadow Ray Tests:
> 
> What if anything, are they telling me?
> 
> I have a mesh that when rendered using Blender's Pov exporter. Renders 
> so much slower than when rendered using PoseRay. I cut it down a bit and 
> the Max Level: was 1/5. So that shot down one theory. :-(
> 

Max level 1/5 mean that no ray got reflected not refracted.

Smpls/Pxl is a ratio that inform you about how much over-sampling was 
done during the render.
If it's close to 1, then, most pixel needed only a single sample to get 
the final result. If it's somehing like 10 or more, that mean that, on 
average, at least 10 subsamples where needed to compute every pixel of 
the image. This don't take into acount partial reflection or chromatic 
dispersion associated with refraction.
A large value may indicate that your antialiasing is to agressive, 
probably from a threshold that is to low or set to zero. If you use 
focal blur, then, that value can only be somewhere between the minimum 
blur samples and the maximum, and can get pushed higher if also using 
antialiasing or blured reflection, that you set in the camera.

Post a reply to this message

On 22/02/2018 21:58, Alain wrote:
> Le 18-02-22 à 07:45, Stephen a écrit :
>> I know it is a bit late in the day to ask. But I never got round to it.
>>
>> I understand Max Level: but not the relevance of Smpls/Pxl:
>>
>> Ray—>Shape Intersection and Shadow Ray Tests:
>>
>> What if anything, are they telling me?
>>
>> I have a mesh that when rendered using Blender's Pov exporter. Renders 
>> so much slower than when rendered using PoseRay. I cut it down a bit 
>> and the Max Level: was 1/5. So that shot down one theory. :-(
>>
> 
> Max level 1/5 mean that no ray got reflected not refracted.
> 
> Smpls/Pxl is a ratio that inform you about how much over-sampling was 
> done during the render.
> If it's close to 1, then, most pixel needed only a single sample to get 
> the final result. If it's somehing like 10 or more, that mean that, on 
> average, at least 10 subsamples where needed to compute every pixel of 
> the image. This don't take into acount partial reflection or chromatic 
> dispersion associated with refraction.
> A large value may indicate that your antialiasing is to agressive, 
> probably from a threshold that is to low or set to zero. If you use 
> focal blur, then, that value can only be somewhere between the minimum 
> blur samples and the maximum, and can get pushed higher if also using 
> antialiasing or blured reflection, that you set in the camera.

Thanks. I have a troublesome mesh that is taking ages to render and I am 
looking for reasons.
What would a Smpls/Pxl = 0.04 signify?

-- 

Regards
     Stephen

Post a reply to this message

On 02/23/2018 03:04 AM, Stephen wrote:
> On 22/02/2018 21:58, Alain wrote:
>> Le 18-02-22 à 07:45, Stephen a écrit :
> 
> Thanks. I have a troublesome mesh that is taking ages to render and I am 
> looking for reasons.
> What would a Smpls/Pxl = 0.04 signify?
> 

I sometimes look at Max Level results, but little else in that section 
of output...

My understanding is Smpls/Pxl is usually 0.0 if anti-aliasing is off. If 
AA is on it goes up, but can still be quite small for the overall image 
- if not much super-sampling was needed for the image in total.

Are you asking about those particular outputs because you see a 
significant difference in those particular results between the two 
methods? If so, what are the values returned?

When you say 'mesh' do you mean just a single mesh as rendered to some 
plain color via both tools? Or are you talking about a complete scene 
via Blender vs PoseRay with textures and 'everything'?

If the former I'd look at the mesh file size as a first clue. Perhaps 
too if a really simple scene whether bounding is on in both and what 
those stats are. Should somewhere see the output :

Bounding boxes.......On
...
Bounding Box  <tests> <succeeded> <percentage>


If working with complete scenes from both tools, the render time 
difference could be a great many things. Suppose I'd start by looking at 
both sets of files looking for differences. Are there ini files where 
one might have some expensive option on by default and the other not for 
example?

Bill P.

Post a reply to this message

On 23/02/2018 13:22, William F Pokorny wrote:
> On 02/23/2018 03:04 AM, Stephen wrote:
>> On 22/02/2018 21:58, Alain wrote:
>>> Le 18-02-22 à 07:45, Stephen a écrit :
>>
>> Thanks. I have a troublesome mesh that is taking ages to render and I 
>> am looking for reasons.
>> What would a Smpls/Pxl = 0.04 signify?
>>
> 
> I sometimes look at Max Level results, but little else in that section 
> of output...
> 

Me to. I've never really understood the significance of them.


> My understanding is Smpls/Pxl is usually 0.0 if anti-aliasing is off. If 
> AA is on it goes up, but can still be quite small for the overall image 
> - if not much super-sampling was needed for the image in total.
> 

In that case this scene is not doing much super-sampling.

> Are you asking about those particular outputs because you see a 
> significant difference in those particular results between the two 
> methods? If so, what are the values returned?
> 

Minuscule. 0.0 Vs 0.04


> When you say 'mesh' do you mean just a single mesh as rendered to some 
> plain color via both tools? Or are you talking about a complete scene 
> via Blender vs PoseRay with textures and 'everything'?
> 

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.

BTW Thanks for thinking about this.

> If the former I'd look at the mesh file size as a first clue. Perhaps 
> too if a really simple scene whether bounding is on in both and what 
> those stats are. Should somewhere see the output :
> 
> Bounding boxes.......On
> ...
> Bounding Box  <tests> <succeeded> <percentage>
> 
> 

Yes Bonding boxed were on:
Ray->Shape Intersection Tests      Succeeded        Percentage
Mesh            10030736            4135877           41. 23
Bounding Box    252706844           86379467          34. 18


> If working with complete scenes from both tools, the render time 
> difference could be a great many things. Suppose I'd start by looking at 
> both sets of files looking for differences. 

I've started doing that. The files are large and I've had to butcher the 
Mesh in Blender to get it to a state where I can see what is inside it.
I really need to get some better tools


Are there ini files where
> one might have some expensive option on by default and the other not for 
> example?
> 

I can't see much here:

Version=3.7
All_File=1
Input_File_Name='F:\Graphics\Poser\Blender 
tests\BugReport\Cutdown\Cutdown01a3a1.pov'
Output_File_Name='F:\Graphics\Poser\Blender 
tests\BugReport\Cutdown\Cutdown01a3a1.png'
Width=960
Height=540
Bounding_Method=2
Display=1
Pause_When_Done=0
Output_File_Type=N
Output_Alpha=1
Antialias=on
Antialias_Depth=3
Antialias_Threshold=0.3
Sampling_Method=2
Antialias_Gamma=2.5
Jitter=off


There are two methods I know of to import an Obj file into Blender.
The first is to use the standard import module which is what I have been 
using. I don't have 100% confidence in it since I found a couple of 
small bugs in the material importing side.
The other is to convert it to a Mesh2 with PoseRay and import it using 
the PovRay importer. Unfortunately that is buggy to although I have put 
in a bug report for that one.
I just wanted a clue from the stats to what was happening.


-- 

Regards
     Stephen

Post a reply to this message

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

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

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

On 24/02/2018 03:08, Alain wrote:
> 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.

Food for thought. Thanks Alain


-- 

Regards
     Stephen

Post a reply to this message

On 02/23/2018 10:08 PM, Alain wrote:
> Le 18-02-23 à 14:00, William F Pokorny a écrit :
...
> 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.
> 
> 
Thanks! Three good ideas I'd not tried when getting stuck with run-away 
rays.

I'll add another that once worked for me - ever so slightly changing the 
camera position.

Aside: The camera change idea has a variant I've used not with run-away 
rays, but rather with solver artifacts. It works with occasional success 
and better on lower resolution images. Namely, rendering with an odd 
number of pixels in the direction perpendicular to an artifact 
directionally aligned with a row or column of pixels. You can sometimes 
move rays so the artifact / solver issue is 'hiding' between pixel rows 
or columns.

Bill P.

Post a reply to this message