Animation frame rate

[gentlegiantJGC]

Looking through the running code it is depending on the delay of the show method to do frame delay.

Is there a known frame rate that the tree will run at? It looks like this will vary based on hardware speed.

I can look into submitting code to at least making it a known frame rate (less than the hardware max)

I could also look into making the frame rate configurable but I don't know how you would want this done. Perhaps as an extra optional column that defaults to 1/60th of a second. Is the tree capable of running at this speed?

[melroy89]

The code says:

sleep_time = 0.017  # approx 60fps

So I guess 60 FPS?

That being said, this sleep_time is not used. It's commented out!?

[gentlegiantJGC]

Yes this is why I was asking.

I think there is a fairly large delay in the show method that slows it down quite a lot.

The better way of doing it is getting the time at the start of the frame, processing the frame and at the end calculating the amount of time needed to sleep to make it up to the end of that frame.

[gentlegiantJGC]

I have modified the run.py file to make these changes and a bunch of cleanup and other improvements.

I need to have another look over it but the code is here. I will open a pull request when it is ready.
https://github.com/gentlegiantJGC/XmasTree/blob/main/03_execution/run.py

[PhilippDahlinger]

I approve the changes from gentlegiantJGC, I especially like the idea of varying delay between frames, this will help making animations simpler. Really hope this pull request will be accepted!

[BoostCookie]

The problem still is that the framerate info is not part of the csv-file. But better to have a hardcoded standard than no standard at all.

[gentlegiantJGC]

My suggested changes adds support for an optional FRAME_TIME column which specifies how long that frame should be displayed for.

If that column is not defined it will default to 1/60th of a second

The code that extracts frame time from the CSV is here
https://github.com/gentlegiantJGC/XmasTree/blob/main/03_execution/run.py#L69

[garciadelcastillo]

Hi there!

We looked into the issue of framerate but, as it turns out, any form of introduced pause via sleep_time would also introduce a very noticeable "lag" on the tree that would make make the animation not fluid at all. So, even though theoretically it would be great to control the fps, we hadn't found a good way of doing it hardware-wise.

Our experience is that my RPi 4 could run animations at roughly 60 fps.

I support adding a FRAME_RATE column in the CSV. Just put it all the way as the last column, to maintain compatibility with older code that reads columns by order, not by header name.

You may want to submit a PR with changes added to run-folder.py as well

[gentlegiantJGC]

Yeh I was planning to modify that one as well.

Could you elaborate on what you mean by lag?
In the original run code it looked like you were experimenting with delay but you were just hard coding the sleep time in addition to the unknown delay in calling the neopixel show method.
I am getting the time at the start and end of frame processing how long to sleep for to make it up to the full frame time.

You should probably add an official document outlining the format. The best I could see was in the description of Matt's video and based on the examples. Only upon reading the code did I realise the order limitations.

Edit: just seen you called it FRAME_RATE not FRAME_TIME. I was expecting that column to store the time in seconds that that frame would be displayed before moving to the next frame

[Diggsey]

@garciadelcastillo is there video of Matt running an example CSV on his tree using the "player" program? That way we can figure out exactly how long each frame is.

[garciadelcastillo]

@gentlegiantJGC yup, documentation is nice, you are welcome to submit a draft with your PR if you fancy :)

@Diggsey there is a video of sample code ran on the tree in the ParametricCamp mini series linked on the README.

[garciadelcastillo]

@gentlegiantJGC feel free to add a column in position [1] (we start counting with zero) named FRAME_TIME that indicates the length of that frame in milliseconds. This would also be nice if people start making "variable rate" animations. Also, please make sure the code is updated to reflect this new column or the absence thereof (for legacy files).

[gentlegiantJGC]

feel free to add a column in position [1]

Do you mean to the right of the FRAME_ID column or replacing that column?

I think if it was added in addition to the FRAME_ID column it would break the old code since the old code assumes that the colours start in the second column.

Replacing the FRAME_ID would work because it isn't used by the old code but that would remove an old feature which I don't like.

I think adding it to the end would be the best bet.

[garciadelcastillo]

Whatever you decide for the PR, it should leave the code working.

[Diggsey]

@garciadelcastillo Based on the video from https://youtu.be/ma4JF6b4Dqk?t=246 to https://youtu.be/ma4JF6b4Dqk?t=322 you run through 2638 frames in 76 seconds, meaning you get about 34.7 frames per second.

No idea if Matt will get the same framerate, but I guess it shouldn't be too far off.

[garciadelcastillo]

Hahaha, that's very awesome @Diggsey , thanks for the timer lol. I guess it is about 30fps then!

I believe Matt uses a RPi Zero, so maybe he has more latency? No idea.