the visualizationframe is more in analogy to a canvas. we segregate
info on this class.
although i liked the idea of renaming it to more apt. VisualizationManager

On 6/23/13, Christopher Dembia <notifications@github.com> wrote:
>> +
>> +right_hand_side = code_generator(kane,params)
>> +
>> +#setting initial conditions ..
>> +init_conditions = [radians(45),radians(45),radians(30),\
>> +                   radians(30),radians(15),radians(15),\
>> +                           0,           0,         0,\
>> +                           0,           0,          0]
>> +t = [0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0]
>> +
>> +numerical_vals = odeint(right_hand_side, init_conditions, t)
>> +
>> +#Now for each t, we have numerical vals of coordinates ..
>> +#Now we set up a visualization frame,
>> +
>> +frame1 = VisualizationFrame('frame1',I , O)
>
> Cool. So in my mind I was thinking that VisualizationFrame's would be in the
> background. One would use them explicitly if they were doing some general
> animation, but if you were doing an animation with a rigid body system, when
> you initialize a visualization/animation, these could be created
> automatically.
>
> It seems that we are thinking about VisualizationFrame different, since you
> are adding bodies and particles to a single VisualizationFrame. Maybe you
> are thinking of VisualizationFrame the way I'm thinking about
> MultiBodySystem, or as a manager class for visualization
> ("VisualizationManager")? In which case, I'm not sure how it differs from
> Scene. I hope to understand better what you're thinking of.
>
> This might be easier if all rigid bodies, particles, were part of a manager
> class like MultiBodySystem.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/PythonDynamics/pydy_examples/pull/11/files#r4833822
>