Compiling textures into the map.
BigD
[OldF] Join Date: 2002-10-25 Member: 1596Members
[OldF] Join Date: 2002-10-25 Member: 1596Members
<div class="IPBDescription">wad include stuffs.</div>I really hate to break up Skyforgers systematic takeover of this forum, but I need a bit of clarification.
My last compile of my map has the size up to a whopping 9,235 KB! I'm about ready to throw it all into a zip file, and I noticed that it's freakin' twice the size of most other maps! (Only hera is bigger at 10,sumthin, and shiva is 100 KB behind me now) Daimos is the only co map that's close at 7megs. I've got a bunch of custom textures, but I can't have that many, in fact, my own two wads are barely 2 megs.
So what I'm thinking is that my use of wad Auto Detect in nems batch compiler is merging the textures I'm using in ns and ns2 wad into the map.
I have wadincluded my custom wads. This is simply so that I don't have to have a bunch of them floating around in cyberland, conflicting with each version of my map (since I keep adding, and replacing textures as I go along) So, I want those compiled in the map. But, I'm guessing I've got the ns/ns2 textures also being included in, though they aren't specified. I thought that by using auto detect, of the wads that are being included, only the ones being used would be compiled into the map.
So, if I disable autodetect for my next compile, would I get the desired effect then? Is -wadautodetect AND a -wadinclude redundant? Have I confused myself somewhere?
My last compile of my map has the size up to a whopping 9,235 KB! I'm about ready to throw it all into a zip file, and I noticed that it's freakin' twice the size of most other maps! (Only hera is bigger at 10,sumthin, and shiva is 100 KB behind me now) Daimos is the only co map that's close at 7megs. I've got a bunch of custom textures, but I can't have that many, in fact, my own two wads are barely 2 megs.
So what I'm thinking is that my use of wad Auto Detect in nems batch compiler is merging the textures I'm using in ns and ns2 wad into the map.
I have wadincluded my custom wads. This is simply so that I don't have to have a bunch of them floating around in cyberland, conflicting with each version of my map (since I keep adding, and replacing textures as I go along) So, I want those compiled in the map. But, I'm guessing I've got the ns/ns2 textures also being included in, though they aren't specified. I thought that by using auto detect, of the wads that are being included, only the ones being used would be compiled into the map.
So, if I disable autodetect for my next compile, would I get the desired effect then? Is -wadautodetect AND a -wadinclude redundant? Have I confused myself somewhere?
Comments
Its intended function seems to be to not mark .wads are required to play the map if they aren't in use by the map.
(A single bright dynamic light can add a over a megabyte to your light data. To reduce this you can selectively disable bounce for dynamic lights with nodynbounce)
<!--quoteo(post=1632336:date=Jun 7 2007, 10:49 PM:name=Soylent_green)--><div class='quotetop'>QUOTE(Soylent_green @ Jun 7 2007, 10:49 PM) [snapback]1632336[/snapback]</div><div class='quotemain'><!--quotec-->
(A single bright dynamic light can add a over a megabyte to your light data. To reduce this you can selectively disable bounce for dynamic lights with nodynbounce)
<!--QuoteEnd--></div><!--QuoteEEnd-->
Really? Well, then, some more investigation!
co_moirad20 (the last released version)
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 199/400 12736/25600 (49.8%)
planes 9254/32768 185080/655360 (28.2%)
vertexes 17163/65535 205956/786420 (26.2%)
nodes 9029/32767 216696/786408 (27.6%)
texinfos 8531/32767 341240/1310680 (26.0%)
faces 12503/65535 250060/1310700 (19.1%)
clipnodes 20459/32767 163672/262136 (62.4%)
leaves 5206/8192 145768/229376 (63.5%)
marksurfaces 17150/65535 34300/131070 (26.2%)
surfedges 56641/512000 226564/2048000 (11.1%)
edges 29996/256000 119984/1024000 (11.7%)
texdata [variable] 1071024/4194304 (25.5%)
lightdata [variable] 4717893/6291456 (75.0%)
visdata [variable] 217849/2097152 (10.4%)
entdata [variable] 55839/524288 (10.7%)
86 textures referenced
<!--c2--></div><!--ec2-->
Texture usage is at <b>2.76</b> mb (of 4.00 mb MAX)
co_moirad3 (soon to be released version)
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 200/400 12800/25600 (50.0%)
planes 9907/32768 198140/655360 (30.2%)
vertexes 18952/65535 227424/786420 (28.9%)
nodes 9768/32767 234432/786408 (29.8%)
texinfos 9050/32767 362000/1310680 (27.6%)
faces 13857/65535 277140/1310700 (21.1%)
clipnodes 21021/32767 168168/262136 (64.2%)
leaves 5460/8192 152880/229376 (66.7%)
marksurfaces 18979/65535 37958/131070 (29.0%)
surfedges 62817/512000 251268/2048000 (12.3%)
edges 33417/256000 133668/1024000 (13.1%)
texdata [variable] 1811808/4194304 (43.2%)
lightdata [variable] 5297139/6291456 (84.2%)
visdata [variable] 228362/2097152 (10.9%)
entdata [variable] 63214/524288 (12.1%)
97 textures referenced<!--c2--></div><!--ec2-->
Texture usage is at <b>3.76 mb</b> (of 4.00 mb MAX)
Huh... feature creep! My light data increased by around half a meg, and my texture data increased by about a meg. The fact that they are up doesn't surprise me (I've added more lights and textures) and fortunately, I've removed a "bright dynamic light" since last version. (nodynbounce isn't an option since my dynamic lights are fairly important to the areas they are in.)
The entirety of ns_machina can almost fit in my lightdata! I'm willing to guess that texture lights probably use more light data as well? Scratch that, I forget, I'm using -bounce 2... so there's a pile more data there alone in all likeliness.
Still... texture usage is over the size of my personal wads. Or is that number the amount that is expected to be accessed in game? If texdata, which now that I look at it, is my texture data in the map, perhaps it's less than my personal wads. Hmm....
Well, I won't worry too much about it then, if my light data alone is the biggest piece of the pie.
Lighting in HL is handled with light maps; this is like a tiny texture for each w_poly that stores the light that hits it from all light sources. If you use only static light sources you will never need more than one of these "light textures", but if you use dynamic lights you must use two or more lightmaps for the surfaces affected by them so that they can be independently toggled on and off.
I really hate to break up Skyforgers systematic takeover of this forum<!--QuoteEnd--></div><!--QuoteEEnd-->
Now that's FUNY <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" /> <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
Now that's FUNY <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" /> <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
<!--QuoteEnd--></div><!--QuoteEEnd-->
We are the borg. Your mapping knowledge and skillz will be added to our own. Resistance is futile; you will be assimilated. <img src="style_emoticons/<#EMO_DIR#>/marine.gif" style="vertical-align:middle" emoid="::marine::" border="0" alt="marine.gif" /> <img src="style_emoticons/<#EMO_DIR#>/biggrin-fix.gif" style="vertical-align:middle" emoid=":D" border="0" alt="biggrin-fix.gif" />
Lighting in HL is handled with light maps; this is like a tiny texture for each w_poly that stores the light that hits it from all light sources. If you use only static light sources you will never need more than one of these "light textures", but if you use dynamic lights you must use two or more lightmaps for the surfaces affected by them so that they can be independently toggled on and off.
<!--QuoteEnd--></div><!--QuoteEEnd-->
Okay, yeah, yeah, this makes sense now. The texture lights take a few more calculations during rad (spread over an area instead of a point) but should use the same memory as a static point light, since the end effect is still one light map. Dynamic lights are simply as you say, more light maps. This is a tangent I've had to give a lot of thought to while making this map due to my use of dynamic lighting, which, is modeled after hera's use of dynamic lights... and it too uses a pile of memory as mentioned! It's all becoming more clear in my head now. Thanks!