Has there been a change on how media is rendered, how it behaves when
it is scaled or how f_noise3d() works?

  This is a scene rendered with POV-Ray 3.6.1:

http://www.cs.tut.fi/~warp/images/MediaFire_pov36.jpg

  The exact same scene rendered with POV-Ray 3.7 beta 1:

http://www.cs.tut.fi/~warp/images/MediaFire_pov37.jpg

  (Besides the most obvious difference, the media, notice also how
the gamma correction is way off.)

  I can provide the scene if needed.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Has there been a change on how media is rendered, how it behaves when
> it is scaled or how f_noise3d() works?
> 
>   This is a scene rendered with POV-Ray 3.6.1:
> 
> http://www.cs.tut.fi/~warp/images/MediaFire_pov36.jpg
> 
>   The exact same scene rendered with POV-Ray 3.7 beta 1:
> 
> http://www.cs.tut.fi/~warp/images/MediaFire_pov37.jpg
> 
>   (Besides the most obvious difference, the media, notice also how
> the gamma correction is way off.)

Actually it isn't gamma.  there is indeed an odd bug in media that I have 
been ttrying to track down but could never find a simple enough test case to 
step through the two code versions andd compare.  If you couldd reduce the 
scene to a single image filling object that ideally shows the problem on the 
upper left corner pixel, it would be very helpful.  BTW, note that this only 
happens with some media, not all.

	Thorsten

Post a reply to this message

It seems that the problem was not with media after all (at least not
in this case), sorry.

  I had used 'clock' in the media definition (so that the media is usable
in an animation). It assumes that 'clock' gets values between 0 and 1
(0 by default, when not rendering an animation). Seemingly in this
beta version 'clock' has something completely different (I can't check
what since #debug doesn't seem to be working).
  When I substitute each instance of 'clock' with '0' it renders ok.

  I didn't notice this behaviour until I started to strip down the
code to its minimum. Sorry if this thing with 'clock' was known. :)

  (By the way, what *is* the default value of 'clock' in this beta
version anyways? And why isn't it 0?)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   (By the way, what *is* the default value of 'clock' in this beta
> version anyways? And why isn't it 0?)

It might be "undefined"...

	Thorsten

Post a reply to this message