Memory use of models

1

I have acquired a number of low poly animated and rigged animals. They work great except some use dramatically more memory than others. With my free horse, cow, sheep, pig that have no texture maps and about 6 animations each… I can place about 60 animals on the 100x100 wyrd forest terrain tile before running out of heap. But with a commercial set of forest animals that have similar polycount and about 20 animations each… I can only place about 10 animals before running out of heap. Is it the animations that are the difference?! The filesizes are similar. Is there a way to gauge the memory usage of a TCastleScene that it is loaded?
Here are 54 of the light animals:

wyrd-forest_screen_133
wyrd-forest_screen_1331920×1200 232 KB

2

This pushed me to start on level of detail. I have made a reduced model of the pig that uses 3 faces with image of top, side and front of pig. It looks ok, especialy in the distance. Here are 2000 pigs in 100x100 area.

wyrd-forest_screen_134
wyrd-forest_screen_1341920×1200 234 KB

3

  1. We don’t have a single function that breaks down the memory usage of whole TCastleScene. It would be a good idea to add it, indeed.

  2. There are a few ways to profile memory, Optimization and profiling | Manual | Castle Game Engine , in particular you can use TextureMemoryProfiler, Castle Game Engine: CastleGLImages .

    But from your description, the textures are likely not a problem. The same texture will be cached across all TCastleScene using it.

  3. Most likely your memory issues come from our unoptimal treatment of glTF animations. Right now we “bake” at loading glTF skinned animations, which can take a lot of memory, and you may see logs like this:

    glTF: Memory occupied by precalculating "%s" animation: %s

    We want to fix this by performing glTF skinned animation on GPU, see this roadmap point: “5. Load and animate glTF more efficiently”, Roadmap | Manual | Castle Game Engine .

    There is no easy way to avoid this problem until we fix it good.

    …Unless you’re fine to have multiple animals always play the same point of the same animation, then you can use Castle Game Engine: CastleTransform: Class TCastleTransformReference . TCastleTransformReference can yield a big memory save (one TCastleScene is just reused multiple times in the viewport) but comes with a big limit: it’s really only one TCastleScene, with the same time in the same animation.

    Another roadmap point that will help in this is “29. Allow animating selected node graph properties, without changing the graph, to be able to reuse graphs” on Roadmap | Manual | Castle Game Engine . This will make TCastleSceneCore.Cache more powerful, internally using one scene, but each instance will be able to play different animation.

    Either “29. Allow animating selected node graph properties, without changing the graph, to be able to reuse graphs” or “5. Load and animate glTF more efficiently” will help in case of animation memory usage, and they both are planned, they attack the problem from a different side.

  4. It is also possible that just X3D nodes memory usage is problematic, we have ongoing memory optimization around this, mentioned in Optimizing memory usage, part 1: efficient step animation, using component system in X3D nodes (no interfaces), less memory used by sprite sheets – Castle Game Engine .

My bet is that animations are problematic in your case. If you can submit a testcase I would be able to judge it better :slight_smile: If you cannot share the models publicly, but are OK to send them to me privately, you’re welcome to send them through email to me.

4

Thanks for the detailed response. For now the farm animals work well for testing and getting things working. Maybe by the time I need the fancy forest animals (the moose is really cool) memory use will have improved. My Low LOD works okay when the animals are distant. Currently they are labor intensive to make the top, side and front and back images. That would be something I should be able to automate. When you get to roadmap point 5, I can test for you.

Also I now have slices and stacks exposed on my custom castle cone so can control LOD on the trees.