Overcoming my hunkmeg problem.

[hummer]

As some of you may know, I had an issue with my map taking up too much memory. My BSP was around 22-23 megs. Appearently, ET loads the BSP twice, and, coupling this with the interface, textures, etc. This can eat up the default hunk space (56) quickly.

So, I saw I had a model as misc_gamemodel that should have been misc_model. I switched it to misc_model and the size of the BSP jumped up a bit.

My thought was, why not just change the misc_models into misc_gamemodels? I mean, at least some of them. So, I did. I ended up shrinking the BSP from 23 megs to about 17.

Also, turning off autoclipping on complex models, and doing it by hand helps quite a bit. While autoclipping is precise, it makes a lot of extra unique surfaces and verts. I hand clipped 3 rocks and haved about 200-300kb or so.

So, if you need the space and can live without fancy lightmapped models in some places, use misc_gamemodel. Since they don’t get baked into the BSP, they don’t get loaded twice, and don’t use up much hunk space. Just be sure to inlcude them with the pk3.

Oh, so yeah. It’s right at 56 megs of hunkspace now, down from 72.

[S.S.Heirpie]

You wouldnt happen to have that new map out would you???Id love to put that into rotation!!!

PIE

[hummer]

You wouldnt happen to have that new map out would you???Id love to put that into rotation!!!

PIE

Final will be out soon hopefully.

/me thwaps duke’ku for the updated command map.

[Loffy]

So, if I understand it right:
misc_models: look cool in game, with shadows and all. Bigger file size.
misc_gamemodels: looks ok, but without shadows. Smaller file size.
// Loffy

[hummer]

So, if I understand it right:
misc_models: look cool in game, with shadows and all. Bigger file size.
misc_gamemodels: looks ok, but without shadows. Smaller file size.
// Loffy

I think that’s a safe assumtion for most cases.

misc_models can be lightmapped, so they have nice shadows. However, they add to the BSP size for each instance of the model.

misc_gamemodels are vertex lit (crappy shadows) but still add to the pk3 size, since they have to be included in the PK3. However, they only have to be included once, which means they take up less space.

The trade off in size really comes when you have a reoccuring model, say, a rock. The rock has lots sides, verts, etc. Now, you can use it as a misc_model over and over, and your BSP size will grow because of all the polys being added to the BSP for each instance of the rock.

However, you could use the same rock, in the same places, but change them to misc_gamemodels. Now, that rock doesn’t take up all that space in the BSP. Your BSP is quite smaller, since the model is loaded on start up, rather than baked into the BSP. The only thing taking up space is that one rock model included in the PK3.

Granted, the rock won’t look as cool as a misc_gamemodel. You could play with the shader and such, but it won’t look as good as a lightmapped misc_model.

[kat]

you might now run into (ingame) entity count problems as I think misc_gamemodels count towards that where as misc_models don’t (I’m not 100% sure about this mind - I know misc_models don’t… just not sure about misc_gamemodels). Be aware also that misc_gamemodels get loaded at runtime (iirc) but I don’t know whether this makes any significant difference if you use a lot of them in any given area.

Is the map physically big or complex that it should have a BSP that size??

[hummer]

you might now run into (ingame) entity count problems… ??

I’m using quite a few, and haven’t had any problems yet… although I suppose it could be potentially.

Is the map physically big or complex that it should have a BSP that size??

Yep. Lots of detail, and a fairly large map. Lots of people said it’s three maps in one, which is why I’m going to split it into campaign version later.

[FireFly]

I just had a quick look at all the pk3’s I’ve downloaded these past months and noticed that “Raiders_b2.pk3” is 17.7 MB. Now there’s also a map in my ET Main-directory called “mp_pow”, wich is 16.8 Mb in size and runs fine without any hunk_megs problems… and I was really wondering why…

This quote was stolen from the q3map2 forum:

Actually, lightmaps aren’t the biggest contributor to BSP size.

It’s the surface & vertex counts.

Lots of tiny brush faces (or just lots of complex brushwork in general) will blow out the BSP size.

Try Q3Map2 -info sometime on a BSP. It will show you exactly what’s taking up the space.

y

So like ydnar stated you might wanna try this switch to figure out what’s eating up your space.
Still, that doesn’t explain why another map (“mp_pow”) with almost the same size doesn’t encounter any hunk_megs problems while raiders does… :???:

[chavo_one]

Hummer explained why. It’s because the actual bsp file was so large. bsp files compress extremely well, so a 22MB bsp can compress into a 6MB file. Therefore the pk3 filesize is not a good gauge of whether or not you will have hunkmeg problems.

[kat]

[quote=kat]you might now run into (ingame) entity count problems… ??

I’m using quite a few, and haven’t had any problems yet… although I suppose it could be potentially.

Is the map physically big or complex that it should have a BSP that size??

Yep. Lots of detail, and a fairly large map. Lots of people said it’s three maps in one, which is why I’m going to split it into campaign version later.[/quote]hmmm ok. I know you know how to map so I won’t say anything you don’t already know. You may have to go through the map again and just be very mercanary with it. Ask youself how long a player is going to be in any given area, if the a couple of minutes then leave those areas detailed… if it’s a couple of seconds then cut back on the detailing there as players arn’t necessarily in a position to take note… you might loose a few pounds… er… I mean ‘megabites’ on the BSP that way as well.

I’m not sure what the entity limit is for ET but RtCW MP was around 600 before you started having map problems - I know you know this btw… ;O)

[FireFly]

Therefore the pk3 filesize is not a good gauge of whether or not you will have hunkmeg problems.

I agree 100% chavo, but hummer says that his hunkmeg problems might be the fault of using too many misc_gamemodels instead of using misc_models.
All I wanted to do was to help: with the Q3Map2 -info switch he could find out what is using up his bsp filesize…
again I was only trying to help and trying , like KAt, to find a reason for his hunkmeg problem… :disgust:

[hummer]

The info switch is part of the reason why I started looking more closely at at my models. AKA, What is causing all the damn planes?

Old BSP, with misc_models:

C:\Documents and Settings\Jesse\Desktop>"C:\Program Files\q3map\q3map2.exe"  -in
fo -fs_basepath "C:\Program Files\Wolfenstein - Enemy Territory" -game et  "C:\P
rogram Files\Wolfenstein - Enemy Territory\etmain\maps\raiders_b1.map"
2.5.10
1 threads
Q3Map         - v1.0r (c) 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.10
GtkRadiant    - v1.3.12 Oct 22 2003 21:07:35
My kung fu was very weak
VFS Init: C:/Program Files/Wolfenstein - Enemy Territory/etmain/

---------------------------------
C:\Program Files\Wolfenstein - Enemy Territory\etmain\maps\raiders_b1.bsp
Abstracted BSP file components (*actual sizes may differ)
      139 models             5560
      334 shaders           24048
    24065 brushes          288780
   270426 brushsides      3245112 *
        0 fogs                  0
   274966 planes          4399456
      834 entdata          100559

     1783 nodes             64188
     1923 leafs             92304
    36515 leafsurfaces     146060
    41984 leafbrushes      167936

    26437 drawsurfaces    3912676 *
   270106 drawverts      21608480 *
   170766 drawindexes      683064

        0 lightmaps             0
    86564 lightgrid       2596920 *
          visibility        71048

          total          23533236
                            22981 KB
                               22 MB
---------------------------------
        1 seconds elapsed
Press any key to continue . . .

New BSP, with misc_gamemodels:

C:\Documents and Settings\Jesse\Desktop>"C:\Program Files\q3map\q3map2.exe"  -in
fo -fs_basepath "C:\Program Files\Wolfenstein - Enemy Territory" -game et  "C:\P
rogram Files\Wolfenstein - Enemy Territory\etmain\maps\raiders_b1.map"
2.5.10
1 threads
Q3Map         - v1.0r (c) 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.10
GtkRadiant    - v1.3.12 Oct 22 2003 21:07:35
My kung fu was very weak
VFS Init: C:/Program Files/Wolfenstein - Enemy Territory/etmain/

---------------------------------
C:\Program Files\Wolfenstein - Enemy Territory\etmain\maps\raiders_b1.bsp
Abstracted BSP file components (*actual sizes may differ)
      139 models             5560
      281 shaders           20232
    20909 brushes          250908
   220050 brushsides      2640600 *
        0 fogs                  0
   207022 planes          3312352
     1399 entdata          180415

     1788 nodes             64368
     1928 leafs             92544
    33369 leafsurfaces     133476
    38530 leafbrushes      154120

    23645 drawsurfaces    3499460 *
   189718 drawverts      15177440 *
   118176 drawindexes      472704

        0 lightmaps             0
    86564 lightgrid       2596920 *
          visibility        71912

          total          18018376
                            17596 KB
                               17 MB
---------------------------------
        1 seconds elapsed
Press any key to continue . . .

Keep in mind, I did make a few minor changes between the two besides the models, but not many.

Notice the brushsides, brushes and planes. Those decrease dramatically by swapping out models. However, the entdata does go up using gamemodels.

[Hewster]

misc_models can be lightmapped, so they have nice shadows. However, they add to the BSP size for each instance of the model.

misc_gamemodels are vertex lit (crappy shadows)

Err actually they can be lightmapped
ydnar included this feature since 2.5.2

• Shadows (casting and receiving) are now controllable per-entity
  New entity keys: “_castShadows” or “_cs” and “_receiveShadows” or “_rs”
  Values: 0 = no shadows, 1 = worldspawn shadows, > 1 explicit shadow group,
  negative values imply no worldspawn shadow interation.
  Entities, including model2 and RTCW misc_gamemodels can now cast shadows

http://www.splashdamage.com/forums/viewtopic.php?t=776&highlight=cast+shadows

I’m not sure what “explicit shadow group” means though

Hewster

[hummer]

I would have thought that too, but I’m using those flags (_rs and _cs), and I can guarantee that they are not lightmapped. Maybe I’m missing something.

[digibob]

misc_gamemodels will NOT contribute to ingame entity count in ET, so feel free to use as many of them as you wish, just watch your polycount obviously

The only reason why a misc_gamemodel WILL contribute to ingame entity count in ET is if it has a targetname, scriptname, or is marked as animating.

[Stektr33]

just curious, what happens if you do go over what your hunkmegs are set at? Wouldn’t ET just allocate more?

[SCDS_reyalP]

just curious, what happens if you do go over what your hunkmegs are set at? Wouldn’t ET just allocate more?

No, it will give you a hunk_alloc error and quit.

[gerby]

What´s the culling with misc_gamemodels though?
I´m thinking that maybe you´ll end up with lower FPS because they won´t get as accurately culled as if they were properly part of the BSP.

Just a thought really, can´t test to see

BTW Hummer, despite sorting this, does this mean your map will still come out as a 3 part campaign instead of 1 huge map?

[digibob]

Culling is PVS culling, then frustum culling on the bounding box, pretty much all you’d get with misc_models anyway.

[hummer]

BTW Hummer, despite sorting this, does this mean your map will still come out as a 3 part campaign instead of 1 huge map?

Yeah, eventually… I’m in the middle of moving right now… we move to LA in three days. I hope to get the full version out before then, then get the campaign out once I’m settled in.