POV-Ray

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.

Tasklist

FS#230 - Improved handling of animations

Attached to Project: POV-Ray
Opened by Roland Mösl (founder) - Tuesday, 27 December 2011, 11:51 GMT
Last edited by William F Pokorny (wfpokorny) - Monday, 23 January 2017, 11:24 GMT
Task Type Feature Request
Category Frontend → User interface
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 RC3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

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

This task depends upon

Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 03 January 2012, 21:25 GMT

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 ?

Comment by William F Pokorny (wfpokorny) - Monday, 23 January 2017, 11:24 GMT
  • Field changed: Status (Unconfirmed → Tracked on GitHub)

Now tracked on github as issue #213.

Loading...