Skip to content

Conversation

@MisterCalvin
Copy link

Previously, every animation frame would rebuild and re-upload all visible model geometry to the GPU, causing significant FPS drops when viewing maps with many animated models loaded from FGDs. Now caches skinned frames by (sequence, body, skin, frame) and reuses GPU buffers. Frame cache invalidates on state changes. Converted StudioMesh to use shared_ptr and implemented move semantics for VertexBuffer to support the caching implementation

Uncached (I did not want to make the video too long, but we slowly drop to between 5-10 FPS):

uncached.mp4

Cached:

cached.mp4

For anyone wanting to test, you can find a release over on my fork (the release says it is built from newbspguy_master HEAD, but that's incorrect - you can see the artifacts were built from the HEAD commit on my fix branch)

…ilds

Cache skinned animation frames by sequence/body/skin/frame to avoid rebuilding
and re-uploading geometry every tick. Converted StudioMesh to use shared_ptr
for vertex buffers and added proper move semantics to VertexBuffer for MSVC
compatibility.
@Qwertyus3D
Copy link

@MisterCalvin Hello, I tested your update on heavy maps from Sven Co-op (like polar_resque) and got significantly better fps with "Animate models" enabled, than with original version. Good job! Though without animations there are no such advantages, even a bit better fps in original version (5%>10%). From what I see, your version gives more stable fps in overall, almost no fps drops between animations enabled or disabled.

@MisterCalvin
Copy link
Author

Thanks for testing @Qwertyus3D, although I will say that my solution is simply masking a bigger problem which is a memory leak somewhere in the application, can you check this for me when you have a chance? After I finished opening the PR I noticed memory usage for newbspguy slowly climbing, and testing older versions exhibited the same behavior. My "fix" just slowed the leak down which made me believe I had fixed it, but it's definitely still there. Will try to address this in a separate PR

@Qwertyus3D
Copy link

Qwertyus3D commented Oct 27, 2025

@MisterCalvin No, I can't confirm memory leak, at least from plain running app. I don't know, maybe it's about working with program, but while I use it for map viewing everything is OK. Moreover, your version consumes around 200 Mb more memory (770+ vs 570+), than original app on the same map (polar_resque). I used Windows 10 Task manager to track changes, and both versions are pretty stable for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants