Ren'Py Movie formats (Quality vs Size vs Compatibility)

[nrogers]

Hey everyone,

I've started development on a game (Ren'Py with Daz3d content) in my free time, and before I get too far along, I was hoping to get some input from people more experienced in this world than I am. Right now, I'm mostly looking for information/opinions on the best way to show animation in Ren'Py.

• Is it better to have pre-made video files? or is it better to have a series of images? Is this true in all cases, or only when an animation is short/long?
  • If it's better to have a pre-made video file, which format/codec is the most compatible (looking at you, Android) while still providing decent compression without a notable loss of quality?
  • If it's better to have a series of images, does the compression or size of the images affect the ability of the Ren'Py engine to play them as a fluid animation?
• I've read that Ren'Py is better at fullscreen movies than it is at playing movies/animation over smaller sections of the screen. Does this still hold true, or have your experiences show this not to be the case?
  • If it's better to have full screen movies, what resolution would you recommend for the movie? HD? UHD?

I've also been reading some posts here regarding images and image compression for games. In your experience, which formats (WebM, PNG, JPG, etc..) have proven to be the most reliable across devices/platforms? Ideally I'd be using smaller renders with static backgrounds for most characters and interact-able objects in scenes, so transparency would be key... probably making JPG a non-starter.

Thanks!

 

[Porcus Dev]

Without a doubt, in animations, use a series of images and forget to create the video directly.
This way if the render fails in half, at least you will have some images done and you can start again the rendering of the anmation from there.
If you search in the forum, "animation", you will find several threads in which talk about how to optimize them and make them take less time to render; I recommend you to look for it, there are very interesting tips.
As for the format, MP4 (h.264+mp3) or WEBM (VP9+ogg) are the most used (there is a free program, "Shotcut", which allows you to convert the format if you need to... since you may use one format for editing and then another for the final file of the game, or a bitrate for the PC version and another lower for the Android version).
The resolution...FullHD, both rendering and for the game file (sometimes with individual images a higher rendering resolution is used to get more detail and then downscaled... in animations, being in motion, that isn't necessary, it will not be appreciated).

And for the format of the images, if you need transparency, definitely WEBP; JPG doesn't support it and PNG occupies too much.
You can use the free program xnConvert to convert images from PNG to WEBP (since with DAZ the best thing is to generate a lossless PNG); in terms of compression, you can use "lossless" or if you want them to occupy a bit less, lower the quality to 95%, the file will occupy less and there will be no appreciable loss of quality.

 

[nrogers]

Thanks mgomez0077, lots of good information there, I'll do some searching for animation tips on the forums.

Without a doubt, in animations, use a series of images and forget to create the video directly.
This way if the render fails in half, at least you will have some images done and you can start again the rendering of the anmation from there.

Here, I was actually asking specifically if it was better to use movie files inside of Ren'Py or if it was better to use a series of images (or if that was dependent on the length of the animation). Based on the rest of your answer, I'm guessing it's better to use a movie file (but obviously render as a series of images and convert that into a movie file).

I've noticed in some games that I've played from here that sometimes when an animation loops there's a hiccup or a black frame whenever the animation cycles. Is this a result of a poorly made video file? Or is there a gotcha that I should be looking out for?

Thanks again!

 

[mickydoo]

Thanks mgomez0077, lots of good information there, I'll do some searching for animation tips on the forums.



Here, I was actually asking specifically if it was better to use movie files inside of Ren'Py or if it was better to use a series of images (or if that was dependent on the length of the animation). Based on the rest of your answer, I'm guessing it's better to use a movie file (but obviously render as a series of images and convert that into a movie file).

I've noticed in some games that I've played from here that sometimes when an animation loops there's a hiccup or a black frame whenever the animation cycles. Is this a result of a poorly made video file? Or is there a gotcha that I should be looking out for?

Thanks again!

There are two ways you can display a movie

$ renpy.movie_cutscene("awesome_movie.webm") and make it loop, I can't remember exactly how you make it loop though, but that is the issue anyway when you display a movie like that, hiccups when it loops.

The other way where it won't hiccup is to define the movie as an image.

image name_whatever = Movie(play="awesome_movie.webm")
show name_whatever

That will play the movie looping fine forever until you click on it

 

[NoesisAndNoema]

It is ALWAYS better to use a "movie format", which, incidentally uses sequential images...

Why? Because a movie format has compression encoding, unless it is RAW-KEYFRAME only.

How videos work...
1: A series of RAW, uncompressed, images are fed into the video program.
2: A time-frame is determined and used to set "Key-frames". (A key-frame is an image that is used to "sustain quality", often by being used with as little compression as possible. Frames between key-frames will be compressed the most.)
3: After the first key-frame, the second image is loaded and only portions of the second image are used, displayed over the first image. The more the second image has changed from the first, the less compression you get. However, if 90% of the second image is exactly the same as the first, then only the parts that changed are "saved" and "compressed" and "over-laid" on top of the prior image. (DVD and DIVX use a cool trick called "slipping", which can allow things like eyes, noses, mouths, heads, etc... to be "pushed around the scene", uncompressed, if the angles don't change much. Done across multiple frames.)
4: This continues until the next "Key-Frame", where the compression stops and the new "whole image" is loaded, normally forced... And then the next series of compressed images are used, plastered across that new key-frame image.

If you use only RAW images, then you essentially have a "RAW Uncompressed" video, which will lag most peoples computers and consume tons of space that doesn't need to be used. Even a video with the minimum compression, but NOT "none"... Will offer large savings of space and provide better play-back for an animation.

Just don't set key-frames for less than 1 second, and don't make stupid crazy "Frames per second", like 60+FPS. The standard for video is about 14-27 FPS, or 15-30 if you want to use the "gaming standards". 60-FPS is for actual video-games, where you are trying to reduce screen-chop in high-speed motion movements. Most "videos" don't use that high-speed motion. If you want to be extra careful, setup your encoder to "AUTO FPS" and "AUTO KEY-FRAMES". It will give you more, or less, depending on what it sees as it evaluates the RAW-Video frames.

Animations, unlike still images, don't normally require uber-high detail. When things are in motion, they get blurry in our minds/eyes. If they stand still, we compound that detail into a singular HD image. That is why there is no sense in having RAW-Uncompressed HD images shown in every frame of an animation, we just can't see them!

HOWEVER... If your animation is only 3-10 images, shown at 1 to 5 frames per second... The final outcome may be exactly the same as a video or as raw images, in both looks and file-size. There is just nothing there to compress if you are hitting every key-frame or too much is changing between key-frames.