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

Le 15/01/2012 22:20, clipka a écrit :
> 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.

I guess it's yet another case of computer ending with mathematically
impossible result, like computing the dot product of two unit vectors
and being aware that the result might indeed be bigger than 1, before
trying to compute the arccos of the result to get the value of the
angle. It should not happen... and yet it does in a very few cases.

Good detective work then, dear Clipka!

Post a reply to this message

On 15/01/2012 9:20 PM, clipka wrote:
>
> 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.

After installing RC6 I am still getting the same error.
Below is a link to the scene rendered with one thread. You can see that 
the render fails before the block reaches the image border. For 
comparison I have included a link to the scene rendered with eight threads.

1 thread
http://imgur.com/8BG0X

8 threads
http://imgur.com/HTldu

Code:

#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> *5
   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>

  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

Am 22.06.2012 14:35, schrieb Stephen:
> On 15/01/2012 9:20 PM, clipka wrote:
>>
>> 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.
>
> After installing RC6 I am still getting the same error.

Yes; this issue accidently "fell off the bench" and didn't get picked up 
again until just after RC6 had been built. Sorry for that, my bad.

Post a reply to this message

On 22/06/2012 4:01 PM, clipka wrote:
> Sorry for that, my bad.

No worries on my part. I made up a colour map that looks better imo.

-- 
Regards
     Stephen

Post a reply to this message