Several problems with ftime and the time feature

If you're having trouble using Context Free or don't understand the language, ask for help here.

Moderators: MtnViewJohn, chris, mtnviewmark

Post Reply
nihil
Posts: 3
Joined: Mon Mar 20, 2017 9:25 am

Several problems with ftime and the time feature

Post by nihil »

Heyo!

In the following code:

Code: Select all

startshape bug[timescale 0.1]

CF::Time = [time 0 1]
CF::Background =[b 1]

shape bug
{
	SQUARE[x ftime()]
}
Timescale does not speed up or decrease the speed of the shape bug.
Perhaps this is intended so, I can just multiply ftime after all, but I really think it should behave otherwise: For timescale to impact the overall behavior of the object means more composability with other objects, and it means tweaking is more effective.

I think this stems from the fact ftime() and frame() are two external functions that does not correlate with the environment they're in.
This poses another problem as there is no way to test what the animation will look like in one frame (if I do

Code: Select all

startshape bug[time 0.2 0]
for instance)

I've also come accross another problem: CFDG computes all shapes on one frame, be they alive yet or not.
This doesn't sound so much as a problem, but I had to wait three hours for the program to compile three seconds, while all the first frames were near to blank.

Finally, I don't get why rendering is necessary before animating a movie. This can be a hussle when one deals with huge animations. also some time, even though I have rendered, the program will compile an erroneous movie with respect to time and timescale, and I have to close it and open it again for it to render it properly.

Thank you very much, and really thanks for your program, I really love it!

User avatar
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Re: Several problems with ftime and the time feature

Post by MtnViewJohn »

timescale scales the time translations in child shapes. It is the temporal equivalent to the size adjustment scaling the x, y, and z translations of child shapes. So it has no effect on the speed of animation.

Code: Select all

startshape bug[time 0.2 0]
This just changes the lifetime span of the bug shape by adding 0.2 to the birth time. So the first 20% of your frames will be blank. If you want to render a specific animation time then you should set CF::Frame and CF::FrameTime in your cfdg file:
CF::Frame = number & CF::FrameTime = number

The frame() and ftime() functions only return useful information during animation, not when performing a normal render. Setting CF::Frame tells Context Free what to return from frame() when not animating. Setting CF::FrameTime tells Context Free what to return from ftime() when not animating. This allows the designer to test different frames.
That said, if you specify CF::Time and either CF::Frame or CF::FrameTime, then CFDG should be able to compute the other.
CFDG computes all shapes on one frame, be they alive yet or not.
When CFDG is animating a frame it cannot drop unfinished shapes that do not display for that frame. This is because a descendent shape may translate temporally into the frame. I think CFDG fails to drop finished shapes that are outside the frame. There is no reason to not drop these shapes. I can fix that.
Finally, I don't get why rendering is necessary before animating a movie.
CFDG requires rendering before animating because it needs to know the range of lifetimes of all the finished shapes so that it can properly scale the animation frames. But since you are explicitly specifying the time span for the animation by setting CF::Time I think that the pre-rendering requirement can be dropped.

nihil
Posts: 3
Joined: Mon Mar 20, 2017 9:25 am

Re: Several problems with ftime and the time feature

Post by nihil »

Thanks for your answer!
MtnViewJohn wrote:
Fri Mar 24, 2017 10:21 am
timescale scales the time translations in child shapes. It is the temporal equivalent to the size adjustment scaling the x, y, and z translations of child shapes. So it has no effect on the speed of animation.
I do understand that, however it just semt very weird that you could slow down the way an object grows, but not reliably slow down its speed overall. (I do understand I can use parameters or have local variable for time, it's just that it seems a bit redundant, and might behave weirdly if I forget one and not the other)
So I was just asking if this wouldn't be more coherent/a good feature to implement?
If you want to render a specific animation time then you should set CF::Frame and CF::FrameTime in your cfdg file:
I think I wasn't clear on this one. I just meant that if I have an animation using time translation, then no matter what CF::Frame or CF::Time are, CFDG will render all the shapes at once on the image preview. That is what I meant by the fact that one cannot peak at an image without rendering the movie, sorry for the confusion.
I think CFDG fails to drop finished shapes that are outside the frame
I can confirm that, if you have concentric circles and zoom a thousandfold in it, CFDG will be very slow and eventually crash (I wanted to have an animation where I zoomed expenentially, but to no avail).

As for rendering, I just think that warning the user when they did not CTRL-R before exporting to a .mov might be a good idea, as I often lost quite some time before it became an habit.

User avatar
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Re: Several problems with ftime and the time feature

Post by MtnViewJohn »

So animation needs a few changes to be more useful:
  1. The requirement to render first should be dropped.
  2. CF::Frame and CF::FrameTime are not enough, there needs to be a way to render a specific animation frame.
  3. Finished shapes that are outside the current frame should be dropped.
  4. Finished shapes that are off-canvas should be dropped too.

nihil
Posts: 3
Joined: Mon Mar 20, 2017 9:25 am

Re: Several problems with ftime and the time feature

Post by nihil »

Thanks for your answer, I think this covers it quite well.

About my specific question (On how to have a scalable movement), since you didn't add an innertime in your list, I had an idea to paleate this and avoid parameters: instead of directly modifying the shape with ftime(), what if I created another shape when this one dies:

Code: Select all

startshape bug[timescale 0.001]

CF::Time = [time 0 1]
CF::Background =[b 1]

shape bug
{
	SQUARE[x 0]
	bug[time 1 0 x 0.1]
}
This however, gives me a plethora of cube that appears in a straight line. I am confused, I thought that since I configured CF::time, objects would have a lifespan of 0 to 1 internally, but the objects do not even die.
I suppose this is an expected behaviour, that the child only live while the parents do, but then if I neither can use an innertime function nor this I do not see an elegant way to solve it.
I did try to use a superclass that spawns all the bugs at their right positions, even though it is less readable, but I couldn't see a solution there either.
Is there a proper way that avoids redundancy and parameters to solve this?

User avatar
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Re: Several problems with ftime and the time feature

Post by MtnViewJohn »

The first iteration of bug has a lifetime of [0,1], the 2nd has [0.001,1], the 3rd has [0.002,1]. This goes on until you get a bug shape with lifetime [1.001,1]. Unfinished shapes with birth times after their death times are discarded, which is what stops this infinite loop. Then you are left with 1000 SQUARES all with a death time of 1 and with birth times that slew from 0 to 1 as the SQUARES slew from left to right. This is why you have a line that grows from left to right. Are you trying to have a single square moving from left to right? This would do it:

Code: Select all

startshape bug

CF::Time = [time 0 1000]
CF::Background =[b 1]

shape bug
{
    loop 1000 [x 0.1 time 1 1]
        SQUARE[]
}

User avatar
MtnViewJohn
Site Admin
Posts: 882
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Re: Several problems with ftime and the time feature

Post by MtnViewJohn »

Another user interface change that I think would improve things would be to refactor the Render menu. It currently has these commands:

Render
Repeat Render
Render with Dimensions... (Render to Size on Windows?)
Stop Rendering
--------------------
Save Image...
Save as SVG...
Save as Animation...

It was split up this way because the animation feature used to be very basic. It just animated the rendering process. But when time adjustments and the ftime() and frame() functions were added it became possible to have context free grammars that vary in time as well as space/color. So it is time for animation to be on par with rendering and not just an aspect of saving. The Render menu should look like this:

Render
Repeat Render
Render with Dimensions... (Render to Size on Windows?)
Animate...
Animate a frame...
Stop Rendering
--------------------
Save output...

The Animate menu would bring up a dialog window where you specify the dimensions, frame information, and codec, but not the file name. The cfdg would then get animated into a movie file in the temporary directory. You could then preview this movie directly in Context Free, instead of tediously having to save it, locate it in the file explorer, and view it using some other program.

Animate a frame... would look like the Animate... dialog except you would specify a desired frame number instead of a codec.

Save Output... would save Render or Animate a frame output as PNG or SVG files. For movies it would let you provide a permanent location for the temporary movie file.

Post Reply