Calculating memory requirements

(G0-Gerbil) #1

I’m trying to work out what and how memory is used when I load a map.
Yes, it no longer fits in the default hunkmegs (helmsdeep here).

I’m going to convert a great deal of the models that get compiled into the BSP into normal models which is almost enough to work, but not quite.

Now rather than blindly guess at what else I can save memory on, I was wondering if anyone knew a way to find out specifically what gets used and how much?

So far the only commands I know of for calculating usage are:

/com_hunkused
/imagelist
/meminfo

But meminfo info is a bit gibberish to me, no idea how to read it.
com_hunkused shows a single value (naturally just over the default hunkmeg).

Also, do multiple players increase the hunkmeg requirements, IE testing alone may be fine, but if near the limit, running on a fuller server would go over the limit and potentially crash?

funfunfun :slight_smile:

(CooperHawkes) #2

i guess that’s a question for “the ydnar” :slight_smile:

(SCDS_reyalP) #3

So far the only commands I know of for calculating usage are:

/com_hunkused
/imagelist
/meminfo

But meminfo info is a bit gibberish to me, no idea how to read it.
com_hunkused shows a single value (naturally just over the default hunkmeg).

Rain made some commentary on meminfo here http://bani.anime.net/banimod/forums/viewtopic.php?t=3335&postdays=0&postorder=asc&start=60

Also, do multiple players increase the hunkmeg requirements, IE testing alone may be fine, but if near the limit, running on a fuller server would go over the limit and potentially crash?

I’m suspect that is the case. (I know for certain it happens with the entity limit, not completely certain about hunk).

you can use q3map2 -game et -info filename.bsp to get the sizes of various parts of the .bsp, which may give you a hint as to what to trim down.

(G0-Gerbil) #4

Thanks for that, I’ll see what I need to chop out and see how it goes (box map here I come!).

(G0-Gerbil) #5

OK that all helped, as did shifting a lot of my misc_models to misc_gamemodels (thanks for converting them Detoeni, I owe you!), but then I hit the entity limit.
From what I recall, 1024 is the in-game limit, but that leads me to ask:

  • How many of those entity ‘slots’ should I leave free for a normal game? 100? 200? etc. etc.
  • What obvious entities in radiant DON’T count towards that in-game entity limit? EG I naturally need to delete entities, but will deleting lights etc do it, or not really?

Cheers.

(Ifurita) #6

AFAIK, lights, misc_models, func_groups, info_nulls do not count towards game-time entity count

(G0-Gerbil) #7

Drat had that feeling!
OK 200 or so misc_gamemodels and various other entities deleted, but I still dunno how many I should leave for the game itself.

Is there a way of finding out how many entities are in use at a given time? Then I could just go to a spammy server and find the difference between full game-play and empty map entity count.

(SCDS_reyalP) #8

/entitylist
but you need server console or rcon for that, AFAIK. There was a rule of thumb posted once, but I don’t remember what it was :confused:

(Ifurita) #9

Didn’t CTRL-M give you an entity count for your map?

(SCDS_reyalP) #10

Yes, but that includes both runtime and compiletime entities, and only those defined in the map. compiletime limit is 2048, runtime limit is 1024, and many runtime entities are created by the engine (players, bodies, explosions etc) and so aren’t counted in radiant.

(Ifurita) #11

ah

(G0-Gerbil) #12

Cheers guys - I’ll see if there are any friendly server admins out there that can help - at least this way I can find out how many my maps use when empty, which is a start.
I can probably also do some tests with just me in the server to see what adds entities and how many, maybe do a really really poor extrapolation from that.

Which leads me to - what happens if you go over the entity limit at runtime - is it a server crash or do things start mysteriously vanishing?

You know, this makes me wonder if that was responsible for the vanishing mines in forum - if that were the case I could fix that too!

(SCDS_reyalP) #13

Which leads me to - what happens if you go over the entity limit at runtime - is it a server crash or do things start mysteriously vanishing?

From what I call in RTCW not exactly either. Things start to go weird, like the wrong entity being displayed and stuff like that.

(G0-Gerbil) #14

OK did /entitylist in the console of the official maps and the results are:

Radar - 557
Railgun - 480
Fueldump - 622
Oasis - 343
Battery - 756
Goldrush - 772

Goldrush is in bold since it’s got the most, and one would assume it’s the upper limit anyone would want to use (suprised Battery came in second though).

After pruning, Helmsdeep is now down to 728, although things are still going a bit screwy, so probably need to look elsewhere now, since the entity limit appears to be fine.

cheers for that reyalP - nice to know that’s one area I don’t have to worry about right this second!

(G0-Gerbil) #15

ah-HAH!

I am an idiot :wink:

By changing the misc_models to misc_gamemodels I fell foul of the old ‘if the origin is in structural brush, the model doesn’t show’.
That’s why tons of my models went missing.
As Mr T would say: ‘Hey fool!’

:smiley:

(SCDS_reyalP) #16

If for some reason the origin needs to be in structure, you could probably work around that with misc_vis_dummy. Of course, that will add to your entity count :smiley:

Also, if I have understood correctly, adding a targetname to to a misc_gamemodel makes it a server side entity, while a misc_gamemodel without any targetname, script or spawnflags ends up being purely client.


	// Gordon: static gamemodels client side only now :D so server can just wave bye-bye
	if(!ent->scriptName && !ent->targetname && !ent->spawnflags) {
		G_FreeEntity( ent );
(LowLife) #17

Hey, just wanted to say that latest version of daybreak has 895 entities, counted by /entitylist, and is running fine on a full 55 slot server. We have been over limit, earlier resulting in server crashes.

(G0-Gerbil) #18

Cheers for that :slight_smile:
Fortunately I’m no longer worried about entity count (and they all show up now I moved them off the darned ground hurrah!) - although it’s reassuring to know I’ve got a bit of a safety margin now.

Memory savings now need to come from elsewhere. Here’s the latest build dump for both helmsdeep and oasis (the biggest BSP filesize of the officials - goldrush is second smallest, although it has the highest entity count)

---------------------------------
oasis.bsp
Abstracted BSP file components (*actual sizes may differ)
       57 models             2280
      150 shaders           10800
    21052 brushes          252624
   215724 brushsides      2588688 *
        1 fogs                 72
   147186 planes          2354976
      330 entdata           45947

     5578 nodes            200808
     5636 leafs            270528
    43200 leafsurfaces     172800
    58313 leafbrushes      233252

    20692 drawsurfaces    3062416 *
   154900 drawverts      12392000 *
   109530 drawindexes      438120

        0 lightmaps             0
    69300 lightgrid       2079000 *
          visibility       732040

          total          15962208
                            15588 KB
                               15 MB

---------------------------------
mml_helmsdeep.bsp
Abstracted BSP file components (*actual sizes may differ)
       97 models             3880
      133 shaders            9576
    28376 brushes          340512
   331019 brushsides      3972228 *
        0 fogs                  0
   292044 planes          4672704
     1031 entdata          129046

     4808 nodes            173088
     4906 leafs            235488
    32772 leafsurfaces     131088
    68750 leafbrushes      275000

    18333 drawsurfaces    2713284 *
   109147 drawverts       8731760 *
    59727 drawindexes      238908

        0 lightmaps             0
   252200 lightgrid       7566000 *
          visibility       575560

          total          18159904
                            17734 KB
                               17 MB

Oddly enough it shows HD is lower than Oasis in many areas - the only bits where my figures are higher than Oasis’ are:

  • Models - kinda irrelevant given their usage
  • Brushes and brushsides - definately down to the caves, which must be the stupidest way of increasing brush-count dramatically known to man.
  • Planes - Ties in to the higher number of brushes, although is seperate in some fashions (see below)
  • entdata - irrelevant, this is merely down to my individual entities having more key / value pairs
  • lightgrid - well, it does cover rather a huge area!

Now, my reading of this, is the important bits for me to work on are:

  • Planes. The non-drawn edges of the caves are a mess, and I can probably clip them all to share planes to a certain degree bringing this value down. Quite a lot of work, potentially I dunno if it will help much.
  • Lightgrid. Hurrah! I just reduce the accuracy of the lightgrid and this might help a lot. Definately going to try that now since it’s such a quick fix it’s gotta be worth a go.

Both of the above are do-able and both should result in a smaller BSP / hunkmeg usage. 1 is easy to do, the other a bit of a pain, given how ‘wiggly’ the back edges of my caves are:


I’m sure you can see there’s plenty I can do there to cut down on the unique planes!

But overall with you guys helping, I think I’ve been able to nail down where I need to improve things, and can get the map running on default hunkmegs with only the barest number of actual visual changes, which is what I was hoping for :drink:
As ever, my gratitude to those who give their time for free to help prevent me getting braindamage from :banghead:

(Ifurita) #19

\o/

Time for you to write up a tutorial on minimizing memory usage. You can post it at www.worldwidegaming.org

(G0-Gerbil) #20

We’ll see - I’ve got a different one to knock up to go with the release of HD final though, so I’ll bear your site in mind :slight_smile: