Hmm im not sure cause i havent tried modeling yet. May not be the best way but just a thought... Could you break it into 2 models and have the part in question act as a diff. brush then just doing the good old glass,texture,low render fx?
Sorry i cant be of help, wish i could cause that thing looks really nice : )
Forum posts
If im compiling just to test something I raise the chop value so I dont get the max patches error (you arent too high above it so a chop value of say 80-90 should get you past the max patches problem) If I remember what i read correctly a chop value of 94 is when it starts looking crappy (Something you dont really need to worry about unless its a final compile imo) Come time to final compile it do as World Crafter suggested and run with a -sparse. The only reason i avoid using -sparse during non final compiles is because it makes hlrad's time waaaaaaaaaaaaaaaaaay f****n long ^^
GL sir
GL sir
- The fonz
the thing about that though is it would keep me from being able to have it in a map right? Im not good at all with modding or anything close to it. Not even that great at mapping. My creativity creates something and my mind fries figuring out how to get it to work. If its not something that i could implement into a tfc .bsp map then I'm not in the state of mind to take the time and get it worked out : /
sadly that is 20000 leagues over my sea o.O
Yes but the thing is if people were to race against eachother everyone could turn the speed to max and it would be the same thing as 2 func_trains with the same speed property going along a track together.
I had a breakthrough however if this isnt the only way to do it then its probably the hardest / most time consuming way to do it. I fooled around with a func_train more and had the buttons targeting a multimanager which manages 2 change targets. .1 sec ct1 activates switching track 5 to s1 (instead of track 6 which would be the default path if the button is not shot) 10 seconds ct2 activates switching track 5 to track 6.
Keep in mind i made this little test area in no more than 5 minutes and used numbers for the tracks to be as simple and fast as possible to see if this method worked out. If in the long run this pays off it will be more organized
Yet to test the slow downs however if my thinker is working correctly id do the same thing with a different button and different pathcorner and just decrease the speed. Probably gonna have to end up making it so that the pause corner on the track at teh starting line fires a mm that changes all the tracks back to normal. Reason being is so that the change targets for the slowdown will only work if the speed ups have been activated on that car. Which i believe would have to do with some how adding a goal in along with the speed boosts and setting the trigger changetarget on the slowdowns to only activate if said speed boost was shot at by the driver.
Anyone see any problems along the way with this method or does it sound like its safe to spend some hefty time making this puppy run smoothly ^^
Edit: Also im planning for the final project if i use this approach to have buttons in the starting section of each car. Player 1 and 2 both push the button and the car moves from the wait for retrigger corner to the starting like. Waits at starting like for a set number of seconds while a message is being displayed counting down the time till the cars move : )
Im stoked about this idea lol. This is my second map and i cant recall seeing a concept like this where the cars actually change speed based off conditions.
I had a breakthrough however if this isnt the only way to do it then its probably the hardest / most time consuming way to do it. I fooled around with a func_train more and had the buttons targeting a multimanager which manages 2 change targets. .1 sec ct1 activates switching track 5 to s1 (instead of track 6 which would be the default path if the button is not shot) 10 seconds ct2 activates switching track 5 to track 6.
Keep in mind i made this little test area in no more than 5 minutes and used numbers for the tracks to be as simple and fast as possible to see if this method worked out. If in the long run this pays off it will be more organized
Yet to test the slow downs however if my thinker is working correctly id do the same thing with a different button and different pathcorner and just decrease the speed. Probably gonna have to end up making it so that the pause corner on the track at teh starting line fires a mm that changes all the tracks back to normal. Reason being is so that the change targets for the slowdown will only work if the speed ups have been activated on that car. Which i believe would have to do with some how adding a goal in along with the speed boosts and setting the trigger changetarget on the slowdowns to only activate if said speed boost was shot at by the driver.Anyone see any problems along the way with this method or does it sound like its safe to spend some hefty time making this puppy run smoothly ^^
Edit: Also im planning for the final project if i use this approach to have buttons in the starting section of each car. Player 1 and 2 both push the button and the car moves from the wait for retrigger corner to the starting like. Waits at starting like for a set number of seconds while a message is being displayed counting down the time till the cars move : )
Im stoked about this idea lol. This is my second map and i cant recall seeing a concept like this where the cars actually change speed based off conditions.
...I came up with the idea to have a race track on my map. Now ive seen countless maps with racecar shaped solids tied to a fun tracktrain that go around in loops or what not, the thing I invision doing differently is adding a twist. That twist being buttons along the course which when shot at either Speed the train up (green buttons) or slow the train down (red buttons) the difference witht his method is that it allows users to "race" if you will. However after fooling around with the tracktrain and train entities im beginning to question the likelyhood of this being possible. It seems a track train cannot be sped up past what its speed in units is set to under its properties. And if the max track speed i want is lets say 500 I believe i have to set the tracktrains speed to 500 correct? the problem with this is that the user can reach max speed off the get go. If this is correct and you cannot have a track go faster than the trains speed in units I am left with 1 option. A train that is set to say 500 speed however the first track reduces it to 200, and then use future tracks to increase the speed back to 500. I have not tested this specific way of controlling the tracktrains speed ingame out of frustration stemming from the amount of time i tried testing other methods which did not turn out to be what im looking for.
Im posting this to see if A. The last method is what im looking at needing to do in order to achieve my goal. or worse B. If the engine isnt even possible of producing something like the racetrack idea.
Any help is much appreciated and if you have any other ideas that may work but you are not sure if it will i would love to hear them.
PS- Hopefully some one has thought of doing this/has and just hasnt posted to map vault / tutorials. I wouldnt be suprised if one of the creative mappers here on twhl has had similar ideas.
PPS- I tried going by Tetsu0's map where you grab the gun and shoot the button to get on the 2nd track however the speed changing aspect im looking to work with seems to make things more complicated
<3 The Fonz
Im posting this to see if A. The last method is what im looking at needing to do in order to achieve my goal. or worse B. If the engine isnt even possible of producing something like the racetrack idea.
Any help is much appreciated and if you have any other ideas that may work but you are not sure if it will i would love to hear them.
PS- Hopefully some one has thought of doing this/has and just hasnt posted to map vault / tutorials. I wouldnt be suprised if one of the creative mappers here on twhl has had similar ideas.
PPS- I tried going by Tetsu0's map where you grab the gun and shoot the button to get on the 2nd track however the speed changing aspect im looking to work with seems to make things more complicated
<3 The Fonz
Im also just now noticing a difference in the information reported by hammer and information reported from zoners compile logs.
Example: Hammer -> Map -> Show Information: 3574
Create Patches : 85371 base patches
added 11 additional animating textures.
Texture usage is at 1.57 mb (of 4.00 mb MAX)
2.44 seconds elapsed
Obvious statement of the day - Mapping is confusing -_-
Example: Hammer -> Map -> Show Information: 3574
Texture Memory 2.7MBCreate Patches : 85371 base patches
added 11 additional animating textures.
Texture usage is at 1.57 mb (of 4.00 mb MAX)
2.44 seconds elapsed
Obvious statement of the day - Mapping is confusing -_-
Eh i appologize if it came across as mocking. That was my way of expressing my disbelief at the situation. 1 things for sure though if leader wants to be secretive about the mod id assume its either a really BA idea oder nicht sehr gut. But you guys all know how it is, some one who has the patience / skills to do something wether the product be good/bad (in quality) is > than he who doesnt take the time all ; )
I have been told by an inside source that this is a Hello kitty mod zomg!
I've exhausted every lead i can think of trying to fix this error. i added 3 map versions that i was using trying to fix the error to the zip file. Concmapfonz is the original map that first saw the allocblock error. Concmapfonzfixing is the most recent where i gave my last shot and retextured the map. And the third Concmapfonzallocfix is a version where i was able to get the map to compile although i still cant find out what it is that is causing the error on the other 2 .rmf versions.
Rather frustrating when you spend so much time on something only for it to take a shit at the finish line. (Or in this maps case near finish line )
I can add more SS's, compile logs, hammer setup or w/e is needed to help out so just let me know, any help is very much appreciated.
http://www.twhl.co.za/vault.php?map=5257
Rather frustrating when you spend so much time on something only for it to take a shit at the finish line. (Or in this maps case near finish line
)I can add more SS's, compile logs, hammer setup or w/e is needed to help out so just let me know, any help is very much appreciated.
http://www.twhl.co.za/vault.php?map=5257
I am getting the Allocblock full error when i load the game. I switched to software video mode and the map loaded fine which from what ive read means its an error caused by the rendering of textures done in the opengl mode. Sadly everything I have read is very frank and doesnt really give me a good idea of what to look at in order to fix the problem. I am also finding that the .bsp is alot larger than I would expect it to be. I mean i've played maps that have got to be larger than mine, yet the .bsp is half the size. Since this is my first map and i was learning the ropes on clipping and everything there are alot of brushes that look fine ingame but im sure would give experienced mappers a heart attack if they saw. I will admit I am not good at knowing the textures and the do's and dont's of textures (what textures not to put on what brush/entity or w/e) so originally i thought my problem was a func_conveyor with a ! texture on it however i still got allocblock full even after retexturing the conveyor with a scrolling texture on top and a normal texture on the rest of the sides (maybe i need to switch all other sides to transparant?)
Anyways I decided to take a ss of my map view in hammer for reference and ill also paste my most recent compile log (the one for the .bsp with the ingame allockblock full error)
Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]
151 brushes (totalling 986 sides) discarded from clipping hulls
CreateBrush:
(1.56 seconds)
SetModelCenters:
(0.02 seconds)
CSGBrush:
(1.64 seconds)
Using Wadfile: \documents and settings\jon\desktop\wads\halflife.wad
Texture usage is at 2.67 mb (of 4.00 mb MAX)
4.48 seconds elapsed
--- END hlcsg ---
hlbsp v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlbsp ---
Command line: "C:\Documents and Settings\Jon\My Documents\Zoners\hlbsp.exe"-es
mate -high "C:\Program Files\Valve Hammer Editor\maps\concmapfonz"
Current hlbsp Settings
Name | Setting | Default
------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ High ] [ Normal ]
noclip [ off ] [ off ]
nofill [ off ] [ off ]
noopt [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 8192)
SolidBSP [hull 0] 500...1000...1500...2000...2500...2829 (0.30 seconds)
BSP generation successful, writing portal file 'C:\Program Files\Valve Hammer
itor\maps\concmapfonz.prt'
SolidBSP [hull 1] 500...1000...1500...2000...2500...2961 (0.25 seconds)
SolidBSP [hull 2] 500...1000...1500...2000...2500...2699 (0.22 seconds)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3146 (0.42 seconds)
5.64 seconds elapsed
--- END hlbsp ---
hlvis v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlvis ---
Command line: "C:\Documents and Settings\Jon\My Documents\Zoners\hlvis.exe"-es
mate -high "C:\Program Files\Valve Hammer Editor\maps\concmapfonz"
880 portalleafs
2127 numportals
= Current hlvis Settings =
Name | Setting | Default
------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max vis distance [ 0 ] [ 0 ]
priority [ High ] [ Normal ]
fast vis [ off ] [ off ]
full vis [ off ] [ off ]
BasePortalVis:
(0.55 seconds)
LeafThread:
(0.84 seconds)
average leafs visible: 37
g_visdatasize:20114 compressed from 96800
1.45 seconds elapsed
--- END hlvis ---
hlrad v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlrad ---
Command line: "C:\Documents and Settings\Jon\My Documents\Zoners\hlrad.exe"-no
nbounce -nopaque -chop 100 -nomatrix -estimate -high "C:\Program Files\Valve H
mer Editor\maps\concmapfonz"
= Current hlrad Settings =
Name | Setting | Default
-------------------|---------------------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ High ] [ Normal ]
vismatrix algorithm [ NoMatrix ] [ Original ]
oversampling (-extra)[ off ] [ off ]
bounces [ 1 ] [ 1 ]
bounce dynamic light [ off ] [ on ]
ambient light [ 0.000 0.000 0.000 ] [ 0.000 0.000 0.000 ]
maximum light [ 255.000 ] [ 256.000 ]
circus mode [ off ] [ off ]
smoothing threshold [ 50.000 ] [ 50.000 ]
direct threshold [ 25.000 ] [ 25.000 ]
direct light scale [ 2.000 ] [ 2.000 ]
coring threshold [ 1.000 ] [ 1.000 ]
patch interpolation [ on ] [ on ]
texscale [ on ] [ on ]
patch subdividing [ on ] [ on ]
chop value [ 100.000 ] [ 64.000 ]
texchop value [ 32.000 ] [ 32.000 ]
global fade [ 1.000 ] [ 1.000 ]
global falloff [ 2 ] [ 2 ]
global light scale [ 1.000 1.000 1.000 ] [ 1.000 1.000 1.000 ]
global gamma [ 0.500 0.500 0.500 ] [ 0.500 0.500 0.500 ]
global light scale [ 1.000 ] [ 1.000 ]
global sky diffusion [ 1.000 ] [ 1.000 ]
opaque entities [ off ] [ on ]
sky lighting fix [ on ] [ on ]
incremental [ off ] [ off ]
dump [ off ] [ off ]
colour jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
monochromatic jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
softlight hack [ 0.0 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 0.0 ]
diffuse hack [ on ] [ on ]
spotlight points [ on ] [ on ]
custom shadows with bounce light
[ off ] [ off ]
rgb transfers [ off ] [ off ]
[Reading texlights from 'C:\Documents and Settings\Jon\My Documents\Zoners\lig
s.rad']
[60 texlights parsed from 'C:\Documents and Settings\Jon\My Documents\Zoners\l
hts.rad']
13915 faces
Create Patches : 100865 base patches
0 opaque faces
3500688 square feet [504099104.00 square inches]
74 direct lights
BuildFacelights:
(85.67 seconds)
MakeScales:
(1993.48 seconds)
SwapTransfers:
(540.03 seconds)
Transfer Lists : 235849208 : 235.85M transfers
Indices : 45597140 : 43.48M bytes
Data : 943396832 : 899.69M bytes
Bounce 1 GatherLight:
(137.09 seconds)
FinalLightFace:
(28.34 seconds)
2796.86 seconds elapsed [46m 36s]
--- END hlrad ---
[URL=http://img117.imageshack.us/my.php?image=concmaphammerss.png]
Anyways I decided to take a ss of my map view in hammer for reference and ill also paste my most recent compile log (the one for the .bsp with the ingame allockblock full error)
Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]
151 brushes (totalling 986 sides) discarded from clipping hulls
CreateBrush:
(1.56 seconds)
SetModelCenters:
(0.02 seconds)
CSGBrush:
(1.64 seconds)
Using Wadfile: \documents and settings\jon\desktop\wads\halflife.wad
- Contains 80 used textures, 73.39 percent of map (3116 textures in wad)
- Contains 2 used textures, 1.83 percent of map (32 textures in wad)
- Contains 17 used textures, 15.60 percent of map (395 textures in wad)
- Contains 10 used textures, 9.17 percent of map (279 textures in wad)
Texture usage is at 2.67 mb (of 4.00 mb MAX)
4.48 seconds elapsed
--- END hlcsg ---
hlbsp v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlbsp ---
Command line: "C:\Documents and Settings\Jon\My Documents\Zoners\hlbsp.exe"-es
mate -high "C:\Program Files\Valve Hammer Editor\maps\concmapfonz"
Current hlbsp Settings
Name | Setting | Default
------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ High ] [ Normal ]
noclip [ off ] [ off ]
nofill [ off ] [ off ]
noopt [ off ] [ off ]
null tex. stripping [ on ] [ on ]
notjunc [ off ] [ off ]
subdivide size [ 240 ] [ 240 ] (Min 64) (Max 512)
max node size [ 1024 ] [ 1024 ] (Min 64) (Max 8192)
SolidBSP [hull 0] 500...1000...1500...2000...2500...2829 (0.30 seconds)
BSP generation successful, writing portal file 'C:\Program Files\Valve Hammer
itor\maps\concmapfonz.prt'
SolidBSP [hull 1] 500...1000...1500...2000...2500...2961 (0.25 seconds)
SolidBSP [hull 2] 500...1000...1500...2000...2500...2699 (0.22 seconds)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3146 (0.42 seconds)
5.64 seconds elapsed
--- END hlbsp ---
hlvis v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlvis ---
Command line: "C:\Documents and Settings\Jon\My Documents\Zoners\hlvis.exe"-es
mate -high "C:\Program Files\Valve Hammer Editor\maps\concmapfonz"
880 portalleafs
2127 numportals
= Current hlvis Settings =
Name | Setting | Default
------------------|-----------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max vis distance [ 0 ] [ 0 ]
priority [ High ] [ Normal ]
fast vis [ off ] [ off ]
full vis [ off ] [ off ]
BasePortalVis:
(0.55 seconds)
LeafThread:
(0.84 seconds)
average leafs visible: 37
g_visdatasize:20114 compressed from 96800
1.45 seconds elapsed
--- END hlvis ---
hlrad v3.4 Final (Feb 25 2006)
Zoner's Half-Life Compilation Tools -- Custom Build
Based on code modifications by Sean 'Zoner' Cavanaugh
Based on Valve's version, modified with permission.
Submit detailed bug reports to (amckern@yahoo.com)
--- BEGIN hlrad ---
Command line: "C:\Documents and Settings\Jon\My Documents\Zoners\hlrad.exe"-no
nbounce -nopaque -chop 100 -nomatrix -estimate -high "C:\Program Files\Valve H
mer Editor\maps\concmapfonz"
= Current hlrad Settings =
Name | Setting | Default
-------------------|---------------------|------------------------
threads [ 2 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ High ] [ Normal ]
vismatrix algorithm [ NoMatrix ] [ Original ]
oversampling (-extra)[ off ] [ off ]
bounces [ 1 ] [ 1 ]
bounce dynamic light [ off ] [ on ]
ambient light [ 0.000 0.000 0.000 ] [ 0.000 0.000 0.000 ]
maximum light [ 255.000 ] [ 256.000 ]
circus mode [ off ] [ off ]
smoothing threshold [ 50.000 ] [ 50.000 ]
direct threshold [ 25.000 ] [ 25.000 ]
direct light scale [ 2.000 ] [ 2.000 ]
coring threshold [ 1.000 ] [ 1.000 ]
patch interpolation [ on ] [ on ]
texscale [ on ] [ on ]
patch subdividing [ on ] [ on ]
chop value [ 100.000 ] [ 64.000 ]
texchop value [ 32.000 ] [ 32.000 ]
global fade [ 1.000 ] [ 1.000 ]
global falloff [ 2 ] [ 2 ]
global light scale [ 1.000 1.000 1.000 ] [ 1.000 1.000 1.000 ]
global gamma [ 0.500 0.500 0.500 ] [ 0.500 0.500 0.500 ]
global light scale [ 1.000 ] [ 1.000 ]
global sky diffusion [ 1.000 ] [ 1.000 ]
opaque entities [ off ] [ on ]
sky lighting fix [ on ] [ on ]
incremental [ off ] [ off ]
dump [ off ] [ off ]
colour jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
monochromatic jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
softlight hack [ 0.0 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 0.0 ]
diffuse hack [ on ] [ on ]
spotlight points [ on ] [ on ]
custom shadows with bounce light
[ off ] [ off ]
rgb transfers [ off ] [ off ]
[Reading texlights from 'C:\Documents and Settings\Jon\My Documents\Zoners\lig
s.rad']
[60 texlights parsed from 'C:\Documents and Settings\Jon\My Documents\Zoners\l
hts.rad']
13915 faces
Create Patches : 100865 base patches
0 opaque faces
3500688 square feet [504099104.00 square inches]
74 direct lights
BuildFacelights:
(85.67 seconds)
MakeScales:
(1993.48 seconds)
SwapTransfers:
(540.03 seconds)
Transfer Lists : 235849208 : 235.85M transfers
Indices : 45597140 : 43.48M bytes
Data : 943396832 : 899.69M bytes
Bounce 1 GatherLight:
(137.09 seconds)
FinalLightFace:
(28.34 seconds)
2796.86 seconds elapsed [46m 36s]
--- END hlrad ---
[URL=http://img117.imageshack.us/my.php?image=concmaphammerss.png]
Well the map in question is a conc map for TFC so yes some of the rooms are very large. I know its not a leak issue since there is no fullbright nor does the compile log have the leak leak leak error. I did compile csg/bsp before vis and rad aswell. No switchable lights. I just set up zhlt and am currently compiling the map for the first time over it. So far it seems alot smoother however I cannot find the lightdata being used on the compile log for zhlt : /
First I would like to state that I have been compiling out of hammer and not zoners tools.
My issue is im seeing a rediculous % of lightdata when I compile and I am wondering what is causing the lightdata to increase so drastically every time I create a new room.
vis.exe v1.3 (Dec 30 1998)
-- vis --
2 thread(s)
346 portalleafs
980 numportals
BasePortalVis: 0...1...2...3...4...5...6...7...8...9... (0)
LeafThread: 0...1...2...3...4...5...6...7...8...9... (2)
average leafs visible: 58
visdatasize:6571 compressed from 15224
3.0 seconds elapsed
qrad.exe v 1.5 (Apr 6 2000)
--- Radiosity --
2 threads
[Reading texlights from 'C:\PROGRA~1\VALVEH~1\tools\lights.rad']
[1 texlights parsed from 'C:\PROGRA~1\VALVEH~1\tools\lights.rad']
3765 faces
532318 square feet [76653792.00 square inches]
34602 patches after subdivision
13 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9... (3)
visibility matrix: 71.4 megs
BuildVisLeafs: 0...1...2...3...4...5...6...7...8...9... (55)
MakeScales: 0...1...2...3...4...5...6...7...8...9... (46)
transfer lists: 204.5 megs
SwapTransfersTask: 0...1...2...3...4...5...6...7...8...9... (10)
GatherLight: 0...1...2...3...4...5...6...7...8...9... (0)
Object names Objects/Maxobjs Memory / Maxmem Fullness
---------- ------------- ------------- ------
models 102/400 6528/25600 (25.5%)
planes 4072/32767 81440/655340 (12.4%)
vertexes 4789/65535 57468/786420 ( 7.3%)
nodes 1367/32767 32808/786408 ( 4.2%)
texinfos 339/8192 13560/327680 ( 4.1%)
faces 3765/65535 75300/1310700 ( 5.7%)
clipnodes 3765/32767 30120/262136 (11.5%)
leaves 992/8192 27776/229376 (12.1%)
marksurfaces 4196/65535 8392/131070 ( 6.4%)
surfedges 16881/512000 67524/2048000 ( 3.3%)
edges 8462/256000 33848/1024000 ( 3.3%)
texdata [variable] 3788/2097152 ( 0.2%)
lightdata [variable] 1325562/2097152 (63.2%)
visdata [variable] 6571/2097152 ( 0.3%)
entdata [variable] 22326/131072 (17.0%)
What is causing this to happen & what will the reprocussions be if nothing is done about it?
TY for your time&Help
-Fonzie
My issue is im seeing a rediculous % of lightdata when I compile and I am wondering what is causing the lightdata to increase so drastically every time I create a new room.
vis.exe v1.3 (Dec 30 1998)
-- vis --
2 thread(s)
346 portalleafs
980 numportals
BasePortalVis: 0...1...2...3...4...5...6...7...8...9... (0)
LeafThread: 0...1...2...3...4...5...6...7...8...9... (2)
average leafs visible: 58
visdatasize:6571 compressed from 15224
3.0 seconds elapsed
qrad.exe v 1.5 (Apr 6 2000)
--- Radiosity --
2 threads
[Reading texlights from 'C:\PROGRA~1\VALVEH~1\tools\lights.rad']
[1 texlights parsed from 'C:\PROGRA~1\VALVEH~1\tools\lights.rad']
3765 faces
532318 square feet [76653792.00 square inches]
34602 patches after subdivision
13 direct lights
BuildFacelights: 0...1...2...3...4...5...6...7...8...9... (3)
visibility matrix: 71.4 megs
BuildVisLeafs: 0...1...2...3...4...5...6...7...8...9... (55)
MakeScales: 0...1...2...3...4...5...6...7...8...9... (46)
transfer lists: 204.5 megs
SwapTransfersTask: 0...1...2...3...4...5...6...7...8...9... (10)
GatherLight: 0...1...2...3...4...5...6...7...8...9... (0)
Bounce #1 added RGB(112202, 112202, 56321)Object names Objects/Maxobjs Memory / Maxmem Fullness
---------- ------------- ------------- ------
models 102/400 6528/25600 (25.5%)
planes 4072/32767 81440/655340 (12.4%)
vertexes 4789/65535 57468/786420 ( 7.3%)
nodes 1367/32767 32808/786408 ( 4.2%)
texinfos 339/8192 13560/327680 ( 4.1%)
faces 3765/65535 75300/1310700 ( 5.7%)
clipnodes 3765/32767 30120/262136 (11.5%)
leaves 992/8192 27776/229376 (12.1%)
marksurfaces 4196/65535 8392/131070 ( 6.4%)
surfedges 16881/512000 67524/2048000 ( 3.3%)
edges 8462/256000 33848/1024000 ( 3.3%)
texdata [variable] 3788/2097152 ( 0.2%)
lightdata [variable] 1325562/2097152 (63.2%)
visdata [variable] 6571/2097152 ( 0.3%)
entdata [variable] 22326/131072 (17.0%)
Total BSP file data space used: 1793011 bytes
118 seconds elapsedWhat is causing this to happen & what will the reprocussions be if nothing is done about it?
TY for your time&Help
-Fonzie