Jump to content

What exactly makes framerate so bad?


Message added by TopicLocker3000

This topic was automatically locked after 6 months of inactivity. If you are the topic owner, please contact a moderator to have it unlocked.

Recommended Posts

As im trying to find ways to improve performance, I would like to know what makes you get the biggest hit on framerate?

By the time I have set a schematic, load up some characters (not even overly complicated rigs) and start adding keyframes, the framerate is already so unpleasant to work with, and I have an expensive computer.

Anyway, what I have found in my experience:

1) Opening the Active Camera window kills framerate pretty much in half

2) Having the "controls, wireframes and highlights" setting enabled makes it worse

3) Keyframes, as you add keyframes, it gets worse

By the time you've done 3 minutes of animation it gets really bad.

Hidding pieces of the schematic im not using makes it better, however, the Active Camera window makes it unsmooth again.

There is something very specific going on considering the simplicity of what's on screen, framerate should stay 60fps in non-render mode but it doesn't.

Stats for my project right now are 1.8 GB RAM, 4% CPU,  GPU 3% yet the FPS is so bad (again, in non-render mode). Something is going on. Why is the FPS so bad if the CPU and the GPU are barely doing anything?

 

Edited by moniker
Link to post
Share on other sites

6 hours ago, Zyn said:

MI was made in GameMaker so i guess its poorly optimized?

Nimi has announced frustum culling for 1.3.0

 

5d2ccd7a5c131.gif

 

 

This should increase FPS. However even without FC active, what's on screen is so simple that it doesn't make much sense that the framerate is so low. I have a 3950X with a 3090 RTX and 32GB RAM so hardware limitations are out of the question, and I like said stats show that resources are barely being used.

Edited by moniker
Link to post
Share on other sites

@Nimi would Occlusion culling be possible? on the gif I posted above you can see how frustum renders everything on the camera angle eyesight while occlusion also saves resources by not rendering pieces of scenario which are hidden by other pieces of the scenario.

 

10-Figure5-1.png

Left: FPS rendering performance only with Frustum Culling and then with Occlusion Culling activated, at the eight different selected View Points. Right: Discarded mesh percent, first with only Frustum Culling and then activating Occlusion Culling, at the eight different selected View Point.

Edited by moniker
Link to post
Share on other sites

3 hours ago, moniker said:

@Nimi would Occlusion culling be possible? on the gif I posted above you can see how frustum renders everything on the camera angle eyesight while occlusion also saves resources by not rendering pieces of scenario which are hidden by other pieces of the scenario.

 

10-Figure5-1.png

Left: FPS rendering performance only with Frustum Culling and then with Occlusion Culling activated, at the eight different selected View Points. Right: Discarded mesh percent, first with only Frustum Culling and then activating Occlusion Culling, at the eight different selected View Point.

Not sure, frustum culling is a pretty straightforward optimization. Not sure if occlusion mapping requires rendering techniques I don't have access to through the engine.

Link to post
Share on other sites

On 4/6/2021 at 9:36 PM, moniker said:

Nimi has announced frustum culling for 1.3.0

 

5d2ccd7a5c131.gif

 

 

This should increase FPS. However even without FC active, what's on screen is so simple that it doesn't make much sense that the framerate is so low. I have a 3950X with a 3090 RTX and 32GB RAM so hardware limitations are out of the question, and I like said stats show that resources are barely being used.

WAIT!? is that Blender? or C4D?

Link to post
Share on other sites

I have realized something doing some testing that further points to how one of the biggest problems is how the program handles keyframes.

On this project the only thing going on is Steve walking for 4 minutes. As I copy and paste the walking cycle the FPS keep going down from 60 to 25 ish:

minekey1.png

Now look what happens when I zoom in:

minekey2.png

The FPS go back to normal.

As discussed before, having the Work camera open, wireframes etc enabled also lower FPS. And we are talking about an empty project with steve walking. The moment you start adding in more stuff and animating, after 5 minutes the program is pretty much unusable. And at only 2 minutes in the program is already unsatistactory to use (the FPS go lower but still not insanely slow, but still annoying to use because animating at less than 60 fps is not fun).

There isn't anything going on on the screen that would make a $3000 computer choke half of the framerate. The program is using 4% of my CPU power and 1% of GPU, 2,145MB of RAM for this project, yet as the screenshots show, it shows a massive fps drop.

Edited by moniker
Link to post
Share on other sites

1 hour ago, moniker said:

On this project the only thing going on is Steve walking for 4 minutes. As I copy and paste the walking cycle the FPS keep going down from 60 to 25 ish:

Now look what happens when I zoom in:

The FPS go back to normal.

That's due to the program needing to display thousands of sprites to display all those keyframes. When you zoom in, less of them will be visible, obviously resulting in higher FPS. There needs to be some way to display the keyframes to the user, so I'm not sure how this could be fixed.

1 hour ago, moniker said:

There isn't anything going on on the screen that would make a $3000 computer choke half of the framerate. The program is using 4% of my CPU power and 1% of GPU, 2,145MB of RAM for this project, yet as the screenshots show, it shows a massive fps drop.

Nimi has already told you that your ultra-high-end PC is ineffective in terms of performance because of the limitations of GameMaker.

On 4/22/2020 at 8:56 AM, Nimi said:

Mine-imator a single-threaded x32 application, as with almost all games made with GameMaker. Rendering all but one core on your CPU and anymore than 4GB of RAM useless in terms of performance.

I'd recommend taking this particular complaint to YoYo Games instead, since AFAIK there's not much - if anything - that Nimi can do about this.

Link to post
Share on other sites

On 6/28/2021 at 6:50 PM, __Mine__ said:

That's due to the program needing to display thousands of sprites to display all those keyframes. When you zoom in, less of them will be visible, obviously resulting in higher FPS. There needs to be some way to display the keyframes to the user, so I'm not sure how this could be fixed.

Nimi has already told you that your ultra-high-end PC is ineffective in terms of performance because of the limitations of GameMaker.

I'd recommend taking this particular complaint to YoYo Games instead, since AFAIK there's not much - if anything - that Nimi can do about this.

Not sure how justified is that showing tiny diamond shaped 2d sprites takes half of your FPS even if there's a bunch. There should be a way around this. I mean we are talking about an empty project with a character walking consuming 30 fps. That's a problem.

Link to post
Share on other sites

12 hours ago, moniker said:

Not sure how justified is that showing tiny diamond shaped 2d sprites takes half of your FPS even if there's a bunch. There should be a way around this. I mean we are talking about an empty project with a character walking consuming 30 fps. That's a problem.

Looking at the zoomed-in image the timeline appears to have roughly 6 keyframes every 3 frames, so that's about 2 keyframe sprites per frame on average.
The zoomed-out image shows the keyframes stretching from 0 to a little over the 5,000-frame mark. Assuming the average of 2 keyframes per frame, that's roughly 10,000 keyframes. Not too surprising that the FPS is going to drop when it has to render 10,000 sprites on your screen. Far more than "a bunch", I'd say.

Don't get me wrong, I'm not disagreeing in regards to this being a problem; it definitely is. I'm just not sure how it could be fixed. After all, the program needs to display something to let the user know there's a keyframe belonging to object X at frame Y that, when clicked, allows you to edit it. Displaying thousands of those will, inevitably, cause an FPS drop.
The only decent solution I can really think of would be to perhaps "cluster" the keyframes if they get too close together while zoomed out? That would definitely reduce the amount of sprites being rendered on-screen... but I have no idea how that could be implemented properly without causing any odd behaviour (which keyframe would take priority for selection if you clicked on a cluster, for example).
Other possible solutions could be to either limit how far the user can zoom out or limit how many keyframes are rendered on-screen at any one time, but of course they're somewhat less ideal, especially that last one.

Edited by __Mine__
Link to post
Share on other sites

11 hours ago, __Mine__ said:

Other possible solutions could be to either limit how far the user can zoom out or limit how many keyframes are rendered on-screen at any one time, but of course they're somewhat less ideal, especially that last one.

Being able to zoom out as far as possible is needed to know where you are at in the project and easily find stuff, not a solution. Not sure how to go about this.

Enabling "toggle controls, wireframes and highlights" option kills a bunch of fps too when it shouldn't.

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...