Jump to content

Issues regarding models and textures


Beelanda

Recommended Posts

Hi.

I'm working on some project:

TL;DR: custom models won't actually unload/free from memory when using correct engine* functions.

 

This project is a gamemode which requires a great amount of models and textures (for objects) to be loaded on client-side. In current state, MTA:SA does not provide any solution for low streaming memory issue as singleplayer GTA:SA (which has Stream Memory Fix, SA Limit Adjuster) - meaning there is only 256 MB streaming memory to work with. With this low amount of memory, I am unable to load all required models and textures at once when player-client joins the server. Loading model consists of requesting new model ID from engine (engineRequestModel) and replacing TXD and DFF with proper functions.

I noticed the issue when I was getting a lot of errors Error loading TXD @ engineLoadTXD. My guess is that game runs out of memory and isn't able to load any more TXDs so it shows this as error/warning.

 

However, I came with partly better solution - load models and textures on demand. When needed, some models will be loaded (engineLoadTXD/DFF, engineReplaceModel, ...) and all other models that are not currently needed will be unloaded (engineRestoreModel, engineFreeModel, ...) if there are some models loaded currently. Also if this can work, I require the models to be loaded truly on demand, and demand changes based some conditions - I need all of the models to be loaded and unloaded many times, not just once.

This should be sufficient solution and should work - because when tested, all required models in different situations loaded correctly then (when loaded for the first time).

But there is this catch. I need it to work many times, not just once. And it seems like the models aren't actually unloaded from memory when unloaded and stay in there even when used all existing engine functions properly. Checking the streaming memory status (engineStreamingGetUsedMemory; /showmemstat) gives me nothing, because everything seems okay when looking at streaming memory.

But eventually I will end up with literally the same result as the first solution, which is unacceptable.

 

I got idea to use IMG file instead using single files for each model (so maybe it works somehow better?), but the IMG file has >1 GB size and refuses to be loaded.

 

The next idea was to not use custom model IDs (engineRequestModel) but use existing San Andreas (object) models instead. Of course, this desperate idea did not work too and resulted same.

 

My question is how is this even possible that I cannot load the same model repeatedly (even when previously unloaded)? I believed that freeing model will also free up the memory, that I can load and unload model any time I want and how much often I want.

I will also be glad for any other ideas or solutions.

Loading models on demand looked very promising, but with the model unloading thing failing, I don't see any solution right now.

Link to comment
  • 2 weeks later...

From your description it's not really clear if you use all needed functions. You mentioned engineLoadTXD/DFF, but do you also call destroyElement? Those are elements so they remain in the memory until you destroy them.

I tried making loading on demand once (I ran into some bugs so it didn't work at all, but that was in 2010), and realizing that destroyElement needs to be called is one of the things I've had in mind since then. I had no trouble figuring it out, but it felt unintuitive. On one hand, it's the same as destroying objects, vehicles, markers and other elements, you destroy them when they're no longer needed. On the other hand, unlike those elements, TXD and DFF are not physical entities on their own that exist inside GTA world, so the need to destroy them is easy to miss. It's like destroying objects/vehicles/markers is a part of gameplay (the element is visible and interacts with other elements and the game world, then it disappears), while destroying TXD/DFF is a part of memory management (nothing changes gameplay-wise, it's just needed for technical reasons).

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...