Experiments About Memory Eaten by DIF vs DTS
by Huan Li · 03/19/2009 (6:52 am) · 8 comments
I have some experiments done, and i got some results, but i don't know why.
Exp1)
I create a box of size 1by1by1 in TC and export it as "smallbox.dif".I place 100 such boxes in mission "smallbox_100.mis".The following results are got in the procedure from mission loading to mission playing.They are Memory eaten when lighting mission, playing and mission file size:
A box of size 100by100by100 is created in TC and exported as "bigbox.dif".It is also placed in a mission 100 copies, but scaled with "0.01 0.01 0.01", the mission name is "bigbox.mis".So you can image that "bigbox.mis" looks as absolutely same as "smallbox.mis",but the memory costs are.....my god, why?
results for exp2 are here:
Exp1)
I create a box of size 1by1by1 in TC and export it as "smallbox.dif".I place 100 such boxes in mission "smallbox_100.mis".The following results are got in the procedure from mission loading to mission playing.They are Memory eaten when lighting mission, playing and mission file size:
box[size:1*1*1, tex:16*16, cnt:100] lighting mem: 290 m runtime mem: 199 m ml file : 686 kExp2)
A box of size 100by100by100 is created in TC and exported as "bigbox.dif".It is also placed in a mission 100 copies, but scaled with "0.01 0.01 0.01", the mission name is "bigbox.mis".So you can image that "bigbox.mis" looks as absolutely same as "smallbox.mis",but the memory costs are.....my god, why?
results for exp2 are here:
box[size:100*100*100, tex:16*16, cnt:100, scale:0.01] lighting mem: 1,069 m runtim mem: 722 m ml file : 1,517 kExp3) and Exp4) are same as Exp1 and Exp2, just replace dif to dts.below is the results:
===================== box[size:1*1*1, tex:16*16, cnt:100] lighting mem: 134m runtim mem: 94m ml file : 547k
===================== box[size:100*100*100, tex:16*16, cnt:100, scale:0.01] lighting mem: 127m runtim mem: 94m ml file : 547k
About the author
#2
03/19/2009 (7:37 am)
Jaimi is correct. DIFs uses consistent lexel density. This means that lightmap textures and UV coordinates are generated in a way so that lightmap texels (lexels) are always the same "size" (relative to the world) in all surfaces. TC has a lighting scale setting that allows you to change the lexel density per brush, so you can have different lighting resolution for different elements (example: a massive building that is to be used as a background prop can use less lexels, since the user will never get close to it). 
#3
why make a comparison of dif vs dts with 2 different models ?
They look the same ingame, yeah, but only because of the .1 .1 .1 scaling.... My logic is telling me surely you should have 10 of the DTS cube sets in the mission for every 1 Dif so that checking the lighting times and ram usage would be comparible, because even though its scaled, its still lighting a dif that has 10x the physical area of the dts... or else its like comparing weights of a brick and a feather and slamming down the brick because its so much heavier... or is my logic totally off ? Oo
03/19/2009 (8:40 am)
erm...why make a comparison of dif vs dts with 2 different models ?
They look the same ingame, yeah, but only because of the .1 .1 .1 scaling.... My logic is telling me surely you should have 10 of the DTS cube sets in the mission for every 1 Dif so that checking the lighting times and ram usage would be comparible, because even though its scaled, its still lighting a dif that has 10x the physical area of the dts... or else its like comparing weights of a brick and a feather and slamming down the brick because its so much heavier... or is my logic totally off ? Oo
#4
It's like comparing a block of cheese with a gallon of milk in some ways to me.
03/19/2009 (12:00 pm)
I believe this is an inaccurate comparison as well esp. because .dts use lod where as .dif can use zoning.It's like comparing a block of cheese with a gallon of milk in some ways to me.
#5
03/19/2009 (1:21 pm)
@Andy: resizing or duplicating the DTS cubes is still inaccurate: DTS models don't have lightmaps. Moreso, DIF instances duplicate the lightmaps for their exterior zones, while non-animated DTS models simply re-use everything. 
#6
03/19/2009 (1:42 pm)
@ Andy: he never said that the DIF was 10x larger then the DTS .. he just tried a secondary DIF that was 10x larger then the first DIF. And then did the same with the DTSes. 
#7
Comparing to DTS shapes is certainly relevant here. Based on the memory usage alone (and assuming the features that DIFs provide are not required) we can immediately see that you should be using DTS shapes instead of DIFs.
03/19/2009 (5:36 pm)
@Scott Wilson: DIFs can use LOD as well. And DIF portal zones are pretty much irrelevant here -- it's the DIF light maps that are the primary cause of the memory usage disparity.Comparing to DTS shapes is certainly relevant here. Based on the memory usage alone (and assuming the features that DIFs provide are not required) we can immediately see that you should be using DTS shapes instead of DIFs.
Associate Jaimi McEntire
King of Flapjacks