What makes small file sizes?

(Loffy) #1

Hi!
When you map, you want to keep finished file size to a minimum. Noone likes to download huge files.

What will determine final file size (Enemy Territory)? Im not talking about custom sounds and textures, but level design, brush work and compiling. Is it as simple and uncomplicated as this: more brush work = larger file, and a larger number of leaf nodes = a larger file ? Or is it more complicated that that?

I guess what I am asking is: Is there something that I can do, when I start a new ET map project and work on this project, to keep file size to a minimum?

// Loffy

(fraco) #2

hehe,

nothing is that straightforward. Obviously Ydnar can answer this best, but I’ll give it a try, so he doesn’t have to answer all the questions.

.bsp size = mainly determined by: (in order of importance)

  • number of lightmaps: (ab)using _lightmapscale, texturing unseen faces that end up being lit (e.g. because they are only hidden by detail brushes)
  • bad vis: if you have too little (or none at all) detail brushes (actually, to many leaf nodes), the vis data will be large
  • misc_model: i believe misc_model models are directly included in the bsp, if you have a lot of those -> maybe expensive

what you can do: only texture stuff that can be seen, consider using vertex lighting where it doesn’t matter, avoid using _lightmapscale when not needed, ask yourself if you really need lightmapped terrain. Make sure your vis is efficient.

fraco

(chavo_one) #3

ET uses external lightmaps, so you don’t have to worry about them in your bsp, Loffy.

(ydnar) #4

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

(Loffy) #5

Thank you for your replies!
// L.

(fraco) #6

that info switch is interesting. I believe it tells me that lightmaps are the biggest contributors in my map. Should i be worried???

Abstracted BSP file components (*actual sizes may differ)
35 models 1400
228 shaders 16416
12811 brushes 153732
133768 brushsides 1605216 *
0 fogs 0
89180 planes 1426880
370 entdata 33102

 2942 nodes            105912
 2978 leafs            142944
15342 leafsurfaces      61368
30688 leafbrushes      122752

 6629 drawsurfaces     981092 *
59785 drawverts       4782800 *
38919 drawindexes      155676

  152 lightmaps       7471104

293664 lightgrid 8809920 *
visibility 319408

      total          18411220
                        17979 KB
                           17 MB

    6 seconds elapsed

fraco

(ydnar) #7

Well, 152 lightmaps is quite a bit. What’s the map look like?

y

(fraco) #8

What’s the map look like?

looks gr8 of course…for a first map release that is. I’ll drop some screenies later…

large lightmapped terrain, half of the terrain lightmapscale 0.5 :-D. I also have -nocollapse (needed that, cfr. other thread). Had a few _lightmapscale 0.125 for lightleaks and for impressive shadows…

fraco

(SCDS_reyalP) #9

If I’m reading that right, your lightgrid is nearly at the max too, taking about 8MB.

(ydnar) #10

Well, I’d scale back some of your ambitious lightmapping. Only use it on the parts of the map where it’ll be most noticable.

Also, the lightgrid sizes are much larger than they actually are. Internally it represents each lightgrid cell as 8 colors rather than 2, plus direction for a total of 36 bytes per cell rather than 12. So the lightgrid is actually about 2.5MB or so.

y

(fraco) #11

:smiley:

top down view of the map:

Half of the surface of the terrain is with _lightmapscale 0.25. It’s surrounded by a fence. The outer part of the terrain (unreachable, outside the fence) is not

I couldn’t help myself, but I love those smooth shadows on the terrain:

I actually have this high contrast light vs. dark all round my map:



Also, there is a large roof section i felt needed more detailed shadows (_lightmapscale 0.25 again)

but looking back at the screenie, that definately wasn’t necessary.

The large lightgrid is probably because my skybox is high and empty to allow space for the cooling tower (which i feel actually should have been much bigger)

some more screenies

I had a lot of trouble hinting to give decent fps round this mirror (its visible from quite some spots…)

And some ppl might recognise a model of theirs (properly credited in the readme, hope you don’t mind my borrowing it…)

So, I feel reluctant to reduce the lightmap count, coz i like the way it looks. For the lightgrid, I suppose i could increase the _blocksize (blocksize, gridsize, whatisitagain). Not sure about the effect.

I actually sent the map as final for inclusion in the sof2 mod ICS2, so I’m not sure if I’ll have time to change stuff before the release of that mod.

I was planning on dropping some screenies in here around the release time of ICS2 anyways along with a big

Thank You

:clap:

for all the patience and the help.

greetz

fraco

(LordDaimos) #12

That map looks awsome :).

/LordDaimos

(ydnar) #13

You should make the coke machine shader light-emitting. It’d be a bit more realistic.

What are you using for your sky shader? It looks like you’ve got a high ambient or _minlight.

y

(fraco) #14

erm, good point, rep and 5thhorseman provided a whole set of different shaders with it, and i managed to take the dullest. The machine also has a lightstyles shader (really neat), but that is incredibly expensive :-). Just a simple surfacelight would be way better yes.

Erm, usually screenies look darker on other ppl’s monitor than on mine, I manually brightened them some in photoshop… That’s all…
no minlight…


textures/nuclear/nuclear_sky
{
	q3map_lightimage	textures/colors/blue_light
	qer_editorimage	textures/tools/editor_images/qer_sky
	sun 0.47 0.57 1 60 0 65
	surfaceparm	sky
	surfaceparm	noimpact
	surfaceparm	nomarks
	notc
	q3map_nolightmap
	skyParms	textures/skies/pra6 256 -
}

regarding the amount of lightinfo:
I reduced the lightmapscales quite a bit (doubled the value) to see what it looks like (compiling…). Maybe (just maybe) I overdid it.
I also wanted to change the gridsize, but i think i can’t. The default being 64 64 128], and I’ve got multiple floors, so I can’t scale the z value up. I’ve got quite narrow hallways inside the building, so I think i better keep x and y values too. The lightgrid is wasted on the empty sky of course, but there is no way to scale it only in one specific region is there?

thnx
fraco

(SCDS_reyalP) #15

You can use a common/lightgrid brush to keep it from extending up into the sky, assuming there is no way for your palyers to get up there. The lightgrid brush should define the area in which you want the grid defined. If players can’t go outside the fence, you could exclude the whole area with the trees too.

(fraco) #16

that’s a really interesting bit of help.

SOF2 doesnt have the shader
i got this from the GTKradiant cvs for wolf:

textures/common/lightgrid
{
	qer_trans 0.5
	surfaceparm nodraw
	surfaceparm nolightmap
	surfaceparm nonsolid
	surfaceparm detail
	surfaceparm nomarks
	surfaceparm trans
	surfaceparm lightgrid
}

I suppose thats the one? I definately should be able to save a lot of bsp size. Can it be a complex area, like not just one brush?

thnx

fraco

(ydnar) #17

It could be as complex as you like, but the total box volume of the lightgrid brushes determines its size.

y

(gynec) #18

apropos ‘light-emitting’

i played Splinter Cell and saw the genius light coronas.
It seems to be an OpenGL effect cause my geforce2 :smiley: is able to present it.
Is such a thing realizable per q3map2 ydnar?

http://free.pages.at/gynec/SPLINTERCELL 1.jpg
http://free.pages.at/gynec/SPLINTERCELL 2.jpg
http://free.pages.at/gynec/SPLINTERCELL 3.jpg

(chavo_one) #19

whitespace and the web don’t mix.

http://free.pages.at/gynec/SPLINTERCELL%201.jpg
http://free.pages.at/gynec/SPLINTERCELL%202.jpg
http://free.pages.at/gynec/SPLINTERCELL%203.jpg

(ydnar) #20

No. I answered this before. It’s not a compiler related effect. It’s done entirely in the renderer.

y