• Editor

  • How does FPS work with Spine?

    inglés

Hi,

Apologies! I suspect this is a stupid question but I'm not finding much by searching at the moment. Essentially, we export the atlas and binary for our animations and set them up in Unreal Engine using the UE Runtime. We're building an animation with 80 frames at 24 FPS at the moment (3.33 seconds per animation). However, I believe we want animations to run at 60 FPS minimum, and likely more.

  • Should we create the animation in Spine at 60 FPS, with 200 frames (80 frames at 24 FPS scaled up to 60 FPS) or higher?
  • How would 60 FPS with 200 frames look if the performance of the hardware was degraded when playing the game and the game were running at only 40 FPS?
  • Are frames dropped to maintain the speed of the animation (i.e. would it still be 3.33 seconds but at 40 FPS, so 133 Frames?), or is the animation delayed to render all frames? What determines which frames are dropped? (I'm assuming frames are dropped to maintain the duration of the animation)
  • Should we be creating animations at high FPS (120, 240, 5000)? Where is the "sweet spot" of FPS in Spine so to speak?

These are likely pretty basic questions, so apologies for my lack of understanding (I'm on the code side of things in UE and I'm trying to wrap my head around..well..animating!) For context, we might have six or seven simple animations on screen at any given time (e.g. a 50x50 pixel section of a bush rustling, a 50x50 pixel animation of grass blowing in the wind), and then two big animations on screen (30-80 bones per big animation, constantly in motion). I think the number of animations will impact performance, so we're aiming "small(ish)" for now and scaling up once we've found our baseline.

    Related Discussions
    ...

    In Spine, the FPS (frames per second) setting determines how many frames are displayed per second in the timeline. Here are the key points to understand how FPS works in Spine and how it affects your animations:

    1. Creating Animations at Different FPS:

      • If you create an animation at 24 FPS with 80 frames, it will last 3.33 seconds.
      • If you want to create the same animation at 60 FPS, you would need to scale up the number of frames to maintain the same duration. This means you would need 200 frames (80 frames at 24 FPS scaled up to 60 FPS).

    2. Performance and Frame Dropping:

      • When the game runs at a lower FPS than the animation's FPS (e.g., the game runs at 40 FPS while the animation is at 60 FPS), the animation will still play for the same duration (3.33 seconds). However, some frames will be dropped to maintain the animation's speed.
      • Spine interpolates between frames, so even if frames are dropped, the animation will still appear smooth. The exact frames that are dropped are determined by the runtime, which ensures the animation duration remains consistent.

    3. Optimal FPS for Animations:

      • Creating animations at very high FPS (e.g., 120, 240, 5000) is generally unnecessary and can be overkill. The "sweet spot" for FPS in Spine is typically around 30 to 60 FPS. This range provides a good balance between smoothness and performance.
      • Higher FPS can be useful for very fast movements or when you need very precise control over the animation, but it also increases the workload on the hardware.

    4. Impact of Multiple Animations:

      • Having multiple animations on screen can impact performance, especially if they are complex. It's important to find a balance between the number of animations and the FPS to ensure smooth performance.
      • For simple animations (e.g., small sections of a bush rustling), lower FPS might be sufficient, while more complex animations (e.g., with many bones) might benefit from higher FPS.

    In summary, for your use case, creating animations at 60 FPS should be sufficient. If the game runs at a lower FPS, the runtime will drop frames to maintain the animation duration, ensuring smooth playback. Aim for 30 to 60 FPS for most animations, and adjust based on the complexity and performance requirements.

    nwarner Are frames dropped to maintain the speed of the animation (i.e. would it still be 3.33 seconds but at 40 FPS, so 133 Frames?), or is the animation delayed to render all frames?

    I assume that you are talking of Timeline FPS (see also this setting) and not Physics Constraint FPS settings.

    At runtime, keys are placed at second-based float timepoints, there is no "integer-based" discrete FPS-based playback. When your game's framerate is e.g. 60 FPS, it will e.g. advance the animation time by 1/60 seconds for that frame, applying whatever keys it has just passed for e.g. attachment visibility keys, and interpolating e.g. bone positions accordingly when between two keys. When animation time increment leads to passing two attachment visibility keys in one frame, the last change wins, so you can call that "dropping the first of the two changes", but nothing relevant like events will ever be skipped or dropped, regardless of framerate.

    If you are using frame-by-frame (see sequence attachments) animation, it's a bit of a different topic. Then you might perhaps want to keep the animation's image-changing keys at certain fractions (or multiples) of the game's framerate. E.g. when your game runs at 30 FPS and your attachment images change at 24 FPS, it might look a bit less smooth due to the nature of sampling artifacts.

    • A Nate le gusta esto.