The following code fails with the following message:
Picture index out of range.
Picture index out of range.
Fatal error in renderer: Uncategorized error.
Render failed

The texture scale is relevant.

It does not fail in Pov 3.62
The image map can be downloaded from:
http://www.mmedia.is/~bjj/data/s_rings/sat_ring_color.png

////////////

#version 3.7;

global_settings {
  adc_bailout       0.0039
  ambient_light     rgb <1.000,1.000,1.000>
  assumed_gamma     1.00
  irid_wavelength   rgb <0.250,0.180,0.140>
  max_trace_level   5
  number_of_waves   10
  noise_generator   3
  charset           ascii
}

background { colour rgb <0.000,0.000,0.000> }



#declare Ring_Texture1 =
texture {
  uv_mapping
  pigment {
   image_map{
    png "sat_ring_color.png"
    interpolate 2
    map_type 0
   }
   rotate    <90.000,90.000,0.000>
  }

  finish {
   ambient     rgb <0.100,0.100,0.100>
   brilliance  1.000
   crand       0.000
   diffuse     0.600
   metallic    0.000
   phong       0.000
   phong_size  40.000
   specular    0.000
   roughness   0.050
  }

}

#declare Camera0 =
camera {
  perspective
  location <3843.816,38.892,-2660.667>
  up y
  right 1.333*x
  angle 33.000
  sky <-0.004,1.000,0.002>
  look_at < 0.449, 18.943, 0.102 >
}  // end Camera0




disc {  // Disc0
  0,y,4.400000,2.500000
  texture{ Ring_Texture1 }
     scale     <750.000000,750.000000,750.000000>      // Fails 32 bit
//  scale     <800.000000,800.000000,800.000000>      // Fails 64 bit
  // scale     <600.000000,600.000000,600.000000>     // does not fail
  rotate    <0.000000,0.000000,-20.000000>
  translate <-3500.000000,900.000000,900.000000>
}  // end Disc0


camera{ Camera0 }

/////////

-- 
Regards
     Stephen

Post a reply to this message

On 01/14/2012 09:06 AM, Stephen wrote:
> The following code fails with the following message:
> Picture index out of range.
> Picture index out of range.
> Fatal error in renderer: Uncategorized error.
> Render failed
>
> The texture scale is relevant.
>
> It does not fail in Pov 3.62
> The image map can be downloaded from:
> http://www.mmedia.is/~bjj/data/s_rings/sat_ring_color.png

Don't know why it passes 3.6 but not 3.7 ... I can verify that it DOES 
indeed happen with 3.7. Here's what else I've discovered ... on a lark 
since disc primitive doesn't support uv_mapping I commented it out in 
texture definition and OK fine. Added uv_mapping statement back in and 
changed disc to sphere and it worked ... so it appears to be related to 
uv_mapping and disc????

Post a reply to this message

On 01/14/2012 02:06 PM, Stephen wrote:
> The following code fails with the following message:
> Picture index out of range.
> Picture index out of range.
> Fatal error in renderer: Uncategorized error.
> Render failed
>
> The texture scale is relevant.
>
> It does not fail in Pov 3.62

I can confirm too, it happens with 3.7 binary (win7-64), even when 
version is set to 3.6, but not with 3.6.
A tiny shift in the rotation

rotate    <90.000,90.000,0.000> + <0, 1e-14, 0>

fixes this. Perhaps it's something to do with tangents somehow?

Post a reply to this message

On 14/01/2012 3:02 PM, Jim Holsenback wrote:
> Don't know why it passes 3.6 but not 3.7 ... I can verify that it DOES
> indeed happen with 3.7. Here's what else I've discovered ... on a lark
> since disc primitive doesn't support uv_mapping

Oops! I did not check that.

> I commented it out in
> texture definition and OK fine. Added uv_mapping statement back in and
> changed disc to sphere and it worked ... so it appears to be related to
> uv_mapping and disc????

I get an image if I change the map_type to 1, 2 or 5. At least with 
these settings. Incidentally, Bishop3D has a map_type 8 which Hugo 
called Parametric. I can see no mention of it in the docs.

-- 
Regards
     Stephen

Post a reply to this message

On 14.01.12 15:06, Stephen wrote:
> The following code fails with the following message:
> Picture index out of range.
> Picture index out of range.
> Fatal error in renderer: Uncategorized error.
> Render failed

Please report this at bugs.povray.org. The mapping falls out of range 
internally, which should not happen (or be handled better). It seems like a 
coincidence that it occurs only in 3.7 though.

     Thorsten, POV-Team

Post a reply to this message

On 01/15/2012 03:38 AM, Stephen wrote:
> On 14/01/2012 3:02 PM, Jim Holsenback wrote:
>> Don't know why it passes 3.6 but not 3.7 ... I can verify that it DOES
>> indeed happen with 3.7. Here's what else I've discovered ... on a lark
>> since disc primitive doesn't support uv_mapping
>
> Oops! I did not check that.
>
>> I commented it out in
>> texture definition and OK fine. Added uv_mapping statement back in and
>> changed disc to sphere and it worked ... so it appears to be related to
>> uv_mapping and disc????
>
> I get an image if I change the map_type to 1, 2 or 5. At least with
> these settings. Incidentally, Bishop3D has a map_type 8 which Hugo
> called Parametric. I can see no mention of it in the docs.
>
the parametric object is mentioned in the uv_mapping section of the docs:

http://wiki.povray.org/content/Documentation:Reference_Section_5.2#Supported_Objects

however in the map_type section is does not:
http://wiki.povray.org/content/Documentation:Reference_Section_5.6#The_map_type_Option

I tried map_type 8 and it parsed ok fine ... but get this I also tried 
map_type 10 then map_type 100 and those BOTH parsed as well!!!

A separate bug from what you've uncovered???

Also if someone else on the team could provide a clue as to what the 
map_type 8 narrative should say, I'll make that change.

On a separate note ... Christoph posted a fix for parametric uv_mapping 
back in June of last year, that will roll with RC4

http://bugs.povray.org/task/210?project=2&order=id&sort=desc

Post a reply to this message

On 01/15/2012 09:19 AM, Jim Holsenback wrote:
> I tried map_type 8 and it parsed ok fine ... but get this I also tried
> map_type 10 then map_type 100 and those BOTH parsed as well!!!
>
> A separate bug from what you've uncovered???

added bug report for this:
http://bugs.povray.org/task/232?project=2&order=id&sort=desc

@Stephen: I'll leave the other bug report for you to follow up

Post a reply to this message

On 15/01/2012 9:02 AM, Thorsten Froehlich wrote:
> On 14.01.12 15:06, Stephen wrote:
>> The following code fails with the following message:
>> Picture index out of range.
>> Picture index out of range.
>> Fatal error in renderer: Uncategorized error.
>> Render failed
>
> Please report this at bugs.povray.org. The mapping falls out of range
> internally, which should not happen (or be handled better). It seems
> like a coincidence that it occurs only in 3.7 though.
>
> Thorsten, POV-Team
>

Thanks and done:

FS#233 - Picture index out of range. - Fatal error in renderer: 
Uncategorized error.

There seems to be a formatting error, comment "//" has been removed and 
there are two scales in the texture not commented out.

-- 
Regards
     Stephen

Post a reply to this message

On 15/01/2012 3:00 PM, Jim Holsenback wrote:
> On 01/15/2012 09:19 AM, Jim Holsenback wrote:
>> I tried map_type 8 and it parsed ok fine ... but get this I also tried
>> map_type 10 then map_type 100 and those BOTH parsed as well!!!
>>
>> A separate bug from what you've uncovered???
>
> added bug report for this:
> http://bugs.povray.org/task/232?project=2&order=id&sort=desc
>
> @Stephen: I'll leave the other bug report for you to follow up
>

Done after a struggle :-)

-- 
Regards
     Stephen

Post a reply to this message

Am 15.01.2012 20:13, schrieb bart:
> On 01/14/2012 02:06 PM, Stephen wrote:
>> The following code fails with the following message:
>> Picture index out of range.
>> Picture index out of range.
>> Fatal error in renderer: Uncategorized error.
>> Render failed
>>
>> The texture scale is relevant.
>>
>> It does not fail in Pov 3.62
>
> I can confirm too, it happens with 3.7 binary (win7-64), even when
> version is set to 3.6, but not with 3.6.
> A tiny shift in the rotation
>
> rotate <90.000,90.000,0.000> + <0, 1e-14, 0>
>
> fixes this. Perhaps it's something to do with tangents somehow?

The root cause has been identified by now; it only shows when a ray 
happens to hit the image map extremely close to the image border (about 
a trillionth (1e-12) of a pixel off in this case), and is due to 
precision issues apparently not considered by the original code author.

Post a reply to this message