[PATCH] CModelDef slow/memory intensive load

[Jorma Rebane]

Check original Ticket: #1995

CModelDef fixes uploaded. This patch addresses two problems: 1) CModelDef loading performance

In order to make loading faster, had to change the format of cached binary model data. The new model cache files take a tiny bit more disk space, but in return they load several times faster and the loaded data takes less memory.

2) Complex dynamic objects in structs

One of the main perf hitters was a per-vertex (yes, per each vertex!) std::vector<float> for multiple UV's. This was replaced with 2x CVector2D UV0 & UV1. Another one was an std::string for model prop points, which was replaced with a fixed size buffer m_Name[20] and with an additional m_NameLength.

The result: much better memory performance and usage for model loading.

In order for this to work, I had to change the version of the PMD (binary model cache) format to 4 and change the way models are saved to PMD. This may invalidate any existing model cache. Backwards compatibility for versions 1, 2, 3 is there.

[Jorma Rebane]

Updated patch. Removed size_t 32/64-bit bug.

[wraitii]

Some comments, though generally this sounds good to me, and looking at the patch I see nothing outlandish:

• 20 characters for the prop point name might be a bit too small. "horse_rider_projectile" is already above. I'd say 30/40 would be safe enough. Such a hard limitations also needs to be very explicit. I'm assuming it would throw an error with a longer name, and I think there should be an easy to understand error message
• your patch as a "no newline at end of file" bit at the end of "ps/filelo.cpp"

(also, this is fairly random, but most patches use the "trunk" directory as the root, yours uses "Source").

However, I'm getting "EXC_BAD_ACCESS" crashes on many maps with it applied, apparently caused by "unpacker.UnpackRaw(vertices, sizeof(SModelVertex) * numVertices);" in ModelDef.cpp. Belgian Bog loads, but not other maps such as Acropolis.

Edit: is there a chance this could be caused by not cleaning my cache?

edit2: indeed it was. So forget about the mem bad acess, it works.

[historic_bruno]

Closing these tickets as no further active development is expected. See Philip's megapatch-split git branch for an attempt at splitting megapatch into it's separate parts: ​http://git.wildfiregames.com/gitweb/?p=0ad.git;a=shortlog;h=refs/heads/projects/philip/megapatch-split