The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Opened by Roland Mösl - 2011-12-27
Last edited by William F Pokorny - 2017-01-23
FS#230 - Improved handling of animations
October to middle November, I prodduced a 5 minutes video mainly py POVRAY.
Here a part of the video.ini file
#
# szenes based on games.pov
#
#game-pat
#Initial_Frame=450 - time scale 1000 - 30 seconds
#Final_Frame=899
#Initial_Clock=-12500
#Final_Clock=17500
#game-lost - time scale 1000 - 22 seconds
#Initial_Frame=0
#Final_Frame=659
#Initial_Clock=2000
#Final_Clock=24000
#game-lost - time scale 3000 - 12 seconds - fast through the night
#Initial_Frame=0
#Final_Frame=359
#Initial_Clock=24000
#Final_Clock=60000
#book-cover
#clock=64000
#game-sunrise - time scale 1000 - 35 seconds
#Initial_Frame=0
#Final_Frame=1049
#Initial_Clock=60000
#Final_Clock=95000
Now imagine all the problems:
One computer crashes often because of thermal problems.
Last picture rendere 487.
Now calculate the setings, that this computer continues the task at 487
Or 2 computers should render a scene.
Sounds very easy. Something like computer 1 makes 0..499 computer 2 makes 500..999.
But the computers are different in speed and the pictures are
very different in computation time.
So it would be best
computer 1: 0 to 999
computer 2: 999 to 0
They would meet in the middle, where ever this middle is.
So it would be much easier with
#game-sunrise - time scale 1000 - 35 seconds
Initial_Frame=0
Final_Frame=1049
Initial_Clock=60000
Final_Clock=95000
Initial_Task=487
Final_Task=1049
So I have not to calculate the exact clock seting,
when a computer sould continue a task after crashing at picture 487
#game-sunrise - time scale 1000 - 35 seconds
Initial_Frame=0
Final_Frame=1049
Initial_Clock=60000
Final_Clock=95000
Initial_Task=1049
Final_Task=0
This would be the reverse calcualtion order.
Starting with picture 1049 and going down 1048..1047
Summary of request: allow frameStep to be negative.
This impact animationprocessing.cpp, and is not as obvious as it might sound, due to assertion with +KC (cyclic animation) and computation of next frame.
(the stop criteria must be updated for both direction too).
Additional investigation: effect on clock delta of an initial frame == final frame ?
Now tracked on github as issue #213.