Animation Frame Count and Size

I've been using a really powerful animation system to apply bones to tree models, create realistic 'swaying in the wind' animations, and then export them as PNG files to later import to Construct. After testing out the animation with just one tree though, I've noticed a huge difference to load times when clicking 'run layout' to test things. This could be down to two factors, and is probably a combination of both.

1) I'm using a total of 20 frames for a swaying animation, at an animation speed of 10 (10 frames per second?) so it looks pretty smooth for an atmospheric effect. Is that going to cause a lot of slowdown? Knowing that every tree on a map will have at least one 20 frame animation, and possible a second 20-30 frame animation for stronger winds? I'm using big maps. Maps with over 100 trees are going to be common.

2) The size of the trees in pixels are 512x512, and 1024x1024. I remember reading that some GPUs find large image sizes difficult to render, and that performance is significantly improved if you break the images up into smaller tiles, then piece them back together in the editor. Would images of this size cause slowdown? Or is this just concerning tiled backgrounds on large maps? I have a GPU with 1GB of VRAM, but I'd like it to run on cards with 256mb smoothly enough.

Any feedback on improving performance would be greatly appreciated. It's frustrating having to wait upwards of 60 seconds with a 'Construct is not responding' message every time I want to test my layout. Clearly, i'm doing something stupid

Thanks for reading! ^^

One and two, yes.

Most lower end systems will gag at the bottleneck that will create.

Check "fps in caption", and that will tell you how much ram your taking.

Id say more than a few megs for an object will probably be an issue.

An animated 512 or 1024 sprite is huge and the 1024 especially is going to use a ton of VRAM - probably about 80MB. Large images (512 and up) are a huge bottleneck when compiling, though they are cached and don't need to be recompiled until you change them or reload the project.

I got around it by loading large images at runtime, but I'm not sure how well that will work for animations concerning hotspots, etc.

As far as I know, larger textures aren't a problem for GPUs to render (as long as they support them - stick to 1024 and under), though it will take longer to transfer all those textures to the GPU at the start of the frame. That's generally not an issue, though. The bigger concern is a GPU not having enough VRAM - then it will have to swap textures every frame. Your main problems are compile time and VRAM use.

If you're aiming for 256MB cards (which doesn't mean you have 256mb to work with - the OS uses some, etc.) it might be okay depending on amount of other stuff in the scene, and you could leave the trees animations out and put them back in as the last step before exporting to an exe.

You sure you can't use that animation system in real time on only the onscreen trees? It would be smoother, use less VRAM, load faster and could be dynamic as well. Unless it requires a ton of cpu time, obviously.

It's frustrating having to wait upwards of 60 seconds with a 'Construct is not responding' message every time I want to test my layout.

I hear that. Mine does too.

One and two, yes.

Most lower end systems will gag at the bottleneck that will create.

Check "fps in caption", and that will tell you how much ram your taking.

Id say more than a few megs for an object will probably be an issue.

Thanks for the quick reply. Each animation frame of the tree is 4mb, leading to a total of 80mb per tree with the swaying animation. I'm assuming that's crazy, and total overkill. I'll start playing around with chopping down the amount of frames I have for the animation.

Any tips and tricks I should know about cutting up the image? Such as ideal sizes to cut it into? It's going to be a pain putting them all back together, and setting up the animations for several parts of each tree...

Also, I'm using PNG images at the moment for the transparency info. Is there another file type I should be considering for lower ram usage?

Any tips and tricks I should know about cutting up the image?

Maybe make the branches objects and place them on a trunk?

Also, it doesn't matter what format you use, it all gets converted to PNGs.

An animated 512 or 1024 sprite is huge and the 1024 especially is going to use a ton of VRAM - probably about 80MB. Large images (512 and up) are a huge bottleneck when compiling, though they are cached and don't need to be recompiled until you change them or reload the project.

Hmmm, okay. I was hoping to use them at that image size so that I could use a zoomed-in 'vanity-cam', allowing the player to zoom in for a closer look at his character, and not have to put up with blurred textures all around. It could also be used to get a closer look at the environment, either for purely aesthetic reasons, or for quests involving tracking for example, and looking for signs of vegetation disturbance or footprints. I may have to drop this idea, and stick to a static camera distance if larger textures are an issue.

As far as I know, larger textures aren't a problem for GPUs to render (as long as they support them - stick to 1024 and under), though it will take longer to transfer all those textures to the GPU at the start of the frame. That's generally not an issue, though. The bigger concern is a GPU not having enough VRAM - then it will have to swap textures every frame. Your main problems are compile time and VRAM use.

If you're aiming for 256MB cards (which doesn't mean you have 256mb to work with - the OS uses some, etc.) it might be okay depending on amount of other stuff in the scene, and you could leave the trees animations out and put them back in as the last step before exporting to an exe.

Without having a 256mb card myself, how would I know whether the game is suitable for them? Is there a MB or VRAM usage I should be aiming to stay under, or would I have to test the game on a 256mb system?

You sure you can't use that animation system in real time on only the onscreen trees? It would be smoother, use less VRAM, load faster and could be dynamic as well. Unless it requires a ton of cpu time, obviously.

That's the idea. When a breeze blows across the screen, it animates the trees, shrubs, and long grasses as it passes over them. But I imagine that every tree and object that can be animated would be a problem regardless of whether the animation is playing, since the images used in the animation would still need to be loaded up. Is that right, or are the images only loaded up when they are needed?

Many thanks for the feedback! ^^

[quote:13btzf5j]Without having a 256mb card myself, how would I know whether the game is suitable for them? Is there a MB or VRAM usage I should be aiming to stay under, or would I have to test the game on a 256mb system?

AFAIK, there's no exact science. What if a user is running something else needing VRAM concurrently? Best to simply use as little as you can manage.

[quote:13btzf5j]But I imagine that every tree and object that can be animated would be a problem regardless of whether the animation is playing, since the images used in the animation would still need to be loaded up. Is that right, or are the images only loaded up when they are needed?

All frames in a sprite are loaded when the object is loaded. Dynamic stuff will take up less VRAM because you can bend or rotate one image instead of loading a ton of them. That's also why you'd check what trees are onscreen first, and only animate those. I don't know what you're doing though, so optimization is up to you to experiment with.

A pretty good indicator is your vram. If the 20 frames — was 80 megs then half size, and frames would be half the vram.

As far as cutting stuff up goes.... its still cumulative, and may even use more if the images aren't pow^2

Obviously less frames will give you the best optimization.

Dynamic stuff as Arima said will allow you to use just one frame. Bones, and the sine behavior are a good place to start.

Actually, 512x512 is 1/4 of 1024x1024, so a 512x512x10 animation would be 1/8th, 10MB.

Actually, 512x512 is 1/4 of 1024x1024, so a 512x512x10 animation would be 1/8th, 10MB.

Oh shoot, of course it would. And even sticking to a 20 frame animation would reduce the 80megs to 20. Ok, looks like that's how it has to be. Cutting down my VRAM usage by three quarters (at least as far as trees are concerned) in exchange for a pretty zoom-in function is going to be worth it.

Thanks for your help Newt and Arima. I appreciate it. <3