The real time raytracing runs within the frame's context and is 
therefore tangled with the animation mechanism.

The current animation related options:

+-k   clock
+-ki  initial_clock
+-kf  final_clock
+-kfi initial_frame
+-kff final_frame
+-kc  cyclic_animation
+-stp frame_step
+-sf  subset_start_frame
+-ef  subset_end_frame
       pre_frame_command
       pre_frame_return
       post_frame_command
       post_frame_return

become:

+-an      animation                        boolean  on|off    NEW
+-anm_    animation_method                 string   ValueOnly NEW
           (default|clock_only|frame_only|camera_list)
+-ancv    animation_clock_value            float    ValueOnly
+-anci    animation_clock_initial          float    ValueOnly
+-ancf    animation_clock_final            float    ValueOnly
+-anfv    animation_frame_value            integer  ValueOnly
+-anfi    animation_frame_initial          integer  ValueOnly
+-anff    animation_frame_final            integer  ValueOnly
+-anl     animation_loop                   boolean  on|off
+-anfs    animation_frame_step             integer  ValueOnly
+-ansfi   animation_subset_frame_initial   integer  ValueOnly
+-ansff   animation_subset_frame_final     integer  ValueOnly
+-anfprc_ animation_frame_pre_command      string   ValueOnly
+-anfprr_ animation_frame_pre_return       string   ValueOnly
+-anfpoc_ animation_frame_post_command     string   ValueOnly
+-anfpor_ animation_frame_post_return      string   ValueOnly

The current real time raytracing options:

+-rtr  real_time_raytracing
+-kla  clockless_animation
+-kc   cyclic_animation (As used too by yuqk's rtr)
+-rtc  real_time_capture

become:

+-ms   movieshow                bool   On|Off
+-msm_ movieshow_method         string valueonly
        (camera_list, image file list, etc)
+-msl  movieshow_loop           bool   On|Off
+-msfc movieshow_frame_capture  bool   On|Off
+-msfd movieshow_frame_delay    float  valueonly  NEW

Here too just the options parsing part is coded.

We have this thing called real time raytracing - and to a degree it is. 
Ours is purely camera list driven today. We are moving through a scene 
by changing cameras within a fixed scene->frame(*). Or in yuqk, it can 
be used to render and capture from say 6 different cameras within each 
frame of a running animation. The kinda thing where in video editing 
you'd finalize what camera views to paste together for a final video.

The camera list is created any time there are a list of camera{}s in a 
scene. In non-animations or regular animations you'll get a multiple 
cameras defined warning (and something about using the last one IIRC). 
If you turn on 'clockless_animation' you can flip to the first in the 
list an visa versa as a trick we can use today for command line 
switching between two cameras.

Part of the idea in adding in these changes is to flesh out this 
mechanism so that cameras from the list can be generally selected. And 
this relates to the idea of allowing the definition of camera lists 
prior to the parsing stage too.

Why 'movieshow'? Well the mechanism can, for example, be made to do flip 
book animations from a list of image files. Or if rendering animation 
frames, it could run a movieshow from the starting frame to the just 
finished one to provide a preview animation without having to encode 
anything as an animation.  I'd like to create some sort of ms specific 
clock value use-able with functions to enable more than just camera 
movement. I think the mechanism can be more than it is currently.

Bill P.

Post a reply to this message