Check this out:

* Start beta.33 (make sure you really start it fresh)

* Enqueue the following sample scenes:

   - scenes\textures\finishes\arches.pov
   - scenes\textures\normals\normavg.pov
   - scenes\textures\finishes\arches.pov (again!)

* Go for it, paying close attention to the direction and frequency of 
the waves in the arches.pov shot (easiest to see at bottom left).

Duh! Shouldn't the scene render identical in both runs?! Looks like 
something doesn't get properly initialized.

(Tested with the 64-bit release here.)

Post a reply to this message

clipka wrote:
> * Go for it, paying close attention to the direction and frequency of 
> the waves in the arches.pov shot (easiest to see at bottom left).
> 
> Duh! Shouldn't the scene render identical in both runs?! Looks like 
> something doesn't get properly initialized.

Well, what is the wave pattern in arches? There is a (global) method that 
initiates all waves, but that would not be much different from 3.6. Is the 
bug visible there, too?

	Thorsten

Post a reply to this message

Thorsten Froehlich schrieb:
> clipka wrote:
> Well, what is the wave pattern in arches? There is a (global) method 
> that initiates all waves, but that would not be much different from 3.6. 
> Is the bug visible there, too?
> 
>     Thorsten

Same thing in 3.6.2, yes - I just checked.

In 3.7, I can track down the bug to a global variable "Number_Of_Waves", 
which is initialized to its default value (10) once at startup of the 
whole app, and then no more (I guess the same mechanism applies to 3.6). 
Any scene having a "number_of_waves" parameter will sort of change the 
default for the next scene to be rendered.

There's another potential problem with the waves initialization: The 
wave pattern data will always be initialized for 10 waves, no matter how 
high or low it is set by the user; for smaller values set in the scene 
this is no real problem, because it just accesses the first N waves; but 
higher values will lead to accesses beyond the actually allocated data 
block.

For the time being I'll change that to impose a maximum limit of 10 on 
number_of_waves (higher values were useless anyway), and store the 
actual number of waves in the scene data. But I guess it's worth 
thinking about moving the waves data into the thread completely. Global 
variables are ugly, and it's not really a huge amount of data.


(BTW, the problem should be reproducible in Unix as well, by setting up 
an animation that explicitly defines "number of waves" to something 
other than 10, but leaves it at the default for later frames; rendering 
the whole animation would then cause different results than rendering 
just the later frames.)

Post a reply to this message

clipka wrote:
> Thorsten Froehlich schrieb:
>> clipka wrote:
>> Well, what is the wave pattern in arches? There is a (global) method 
>> that initiates all waves, but that would not be much different from 
>> 3.6. Is the bug visible there, too?
>>
>>     Thorsten
> 
> Same thing in 3.6.2, yes - I just checked.
> 
> In 3.7, I can track down the bug to a global variable "Number_Of_Waves", 

Ah, yes, one of the old dead bodies in the code. Should be one of the last 
ones. We did mark all globals years ago, so the few remaining ones are easy 
to find :-)

> For the time being I'll change that to impose a maximum limit of 10 on 
> number_of_waves (higher values were useless anyway), and store the 
> actual number of waves in the scene data. But I guess it's worth 
> thinking about moving the waves data into the thread completely. Global 
> variables are ugly, and it's not really a huge amount of data.

The question is if it is really needed or maybe just generating like 100 and 
setting the limit there would be more than enough...

	Thorsten

Post a reply to this message