Running out of memory while running rad..
Kehldon
05-22-2003, 02:29 AM
I keep getting strange problems noone else gets all the time I think. WHen I compile my map it takes up huge amounts of memory and lately I have had some problems running rad. I got 256 Mb ram and at first I used swap file 700Mb as virtual memory. Well, I run out of memory at the first try so I increase it swap file to 1400Mb but yet I run out of memory. Now I got like 2.7 Gb free but I think we are talking absured memory amounts here considering the engine is 5 year old and the hardware back then wasnt that great...
Is there anyway I can get the memory usage down while running rad ? My map is quiet big, sure, but I dont have that many lightsources in it, its mostly the sky...
you should make a simple test map (you know, small box map with a sky and light_environemt). When you don't have the problem on this small map.
The problem indeed is specific your map.
Anyway, we'd like to know if you get any errors? If yes, could you post the log file generated when you compile your map??
Kehldon
05-22-2003, 05:18 AM
The problem isnt really rad specifik but win2specifik. Rad takes up so much memory while running that windows first warns and the sais no no, you cant have more memory and automaticly stops rad.
Since rad isnt run complete but stopped, it doesnt generate any logs and the last entries in the logfile is from hlvis:
---------------------------
average leafs visible: 356
g_visdatasize:393943 compressed from 1046542
27519.14 seconds elapsed [7h 38m 39s]
----- END hlvis -----
---------------------------
I know that enableing more memory will solve the problem so I kind of wondered if this is a normal behavior of rad to use that much memory?
Otherwise the rad runs fine on most maps but now that Im closing on the final compiles of my new map, its get extremely large. I found the sparse option and Ill try another compile tonight with a even bigger swapfile enabled.
uh buddy. I had the same problem. then I realized I had a MEMORY LEAK (this is where some program eats memory without the computer realizing it untill it realizes it has none left), this is a fuggin pain in the ass and is something that can be hard to track down. I suggest getting someone to have a look at your comp cause there is a bunch of causes most deep software/hardware.
Kehldon
05-23-2003, 12:23 AM
Actually Im a computer engineer, so that someone should be myself. :)
Nah its not another program leaking memory, and if it is, its hlrad doing so. I have monitored the process and eats a ****load of memory. Im compiling as we speak and its just started and already eaten 60Mb ram and 190Mb virtual memory and its like 20% done...
Im compiling in win2k and you can specify what you want to se in the task manager. Im using Zoners 3.5.1 -17 compile tools if I remember correctly.
kleinluka
05-23-2003, 01:10 AM
try adding -sparse to your rad commandline
Kehldon
05-23-2003, 01:57 AM
I am using sparse ...
Im currently at the last part of the rad process ... making scales
1/3 of it done... memory usage 170Mb Ram and 430Mb swap file...
I wonder if it will be enough :(
Craftos
05-23-2003, 02:06 AM
If you had set -sparse these numbers are pretty high. Maybe you have lights placed in too much open area, when they light too many faces simultaneously. You should try to mess with lights.rad file and reduce number of light in your map.
Kehldon
05-23-2003, 03:04 AM
Unfortunatly it crashed at the end but I managed to save most of the log...
################################################## #
# Batch Compiler Zoners Spec #
################################################## #
################################################## #
# Please report bugs to: ryansgregg@hotmail.com #
################################################## #
Written At: 2003-05-23 08:04:14
BC Version: 2.0.1
hlrad v2.5.3 rel Custom Build 1.7 (Dec 9 2002)
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 (merlinis@bigpond.net.au)
----- BEGIN hlrad -----
Command line: C:\mapping\zhlt\hlrad.exe -sparse -bounce 1 -smooth 5 -estimate -t
exdata 12000 C:\mapping\rmf\dod_lighthouse.map
-= Current hlrad Settings =-
Name | Setting | Default
--------------------|---------------------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 12288000 ] [ 4194304 ]
priority [ Normal ] [ Normal ]
vismatrix algorithm [ Sparse ] [ Original ]
oversampling (-extra)[ off ] [ off ]
bounces [ 1 ] [ 1 ]
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 [ 5.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 [ 64.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 [ on ] [ 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 ]
10851 faces
Create Patches : 63057 base patches
69 opaque faces
803723 square feet [115736200.00 square inches]
13 direct lights
BuildFacelights:
(1960.07 seconds)
BuildVisLeafs:
(4313.94 seconds)
visibility matrix : 32.3 megs
MakeScales:
(2350.08 seconds)
SwapTransfers:
(917.54 seconds)
Transfer Lists : 84908096 : 84.91M transfers
Indices : 42996624 : 41.00M bytes
Data : 339632384 : 323.90M bytes
Bounce 1 GatherLight:
(530.32 seconds)
FinalLightFace:
10449 / 10851 (96%: est. time to completion 2/3/0 secs)
It peaked at 181Mb Ram and 619Mb swap so its quiet large. Now I got like 15 lightsources including the sky. Now it might be my funky computer messing up, I got a friend ready this weekend to help me compile on a lot better system.... hopefully it will fix the problems with the crash...
FuzzDad
05-23-2003, 09:38 AM
10851 faces
Create Patches : 63057 base patches
That's a big map...the 353 avg vis leaf is huge too...my bet is that you have a lot of complicated faces that are breaking up other brushes...it's why your compile is taking so long and using so much mem.
RPGreg2600
05-23-2003, 09:53 AM
Yeah, there's no way in hell vis shouold take you 7 hours! Vis takes me like 10 minutes and the entire map finishes compiling in like half an hour (talking about heckeniveau) Before when I had a bunch of ****ty brush work in DoD honfleur it wopuld take like 3 hours, but that's no where near 7 hours just for vis! Do you have a whole **** load of overlapping world brushes or something?
Edit: btw, final face light takes me literaly 1 second on every map I've ever compiled. there's no way it should be taking you 2 hours. What are yo compiling on? a P1?
Kehldon
05-23-2003, 10:42 AM
Nah, most brushes are very clean but there some of areas that aint perfect yet. The whole map (except the houses) is build up but traingles in order make as realistic terrains as possible, well as the map is fairly large with quiet large open areas its alot of triangles... its has taken a few hours....
I have a ****ty computers, my home computer is P2-350 ( Im about to upgrade, but I have been unemployed couldnt afford it before) my work computer is p3-500 which I have been using for compiles nighttime :) Thus I asked a friend with a highend computer do the compiles for me, so we are going to rig his computer up, hopefully this weekend.
Here is an overview
http://hem.thalamus.nu/~ebo008681/image/dod_lighthouse_overview.gif
Thanks for the input guys! :)
EDIT: Lol, when adding a some minor things I just hit the upper brush limit... thats how big this map is....
Gorbachev
05-23-2003, 01:05 PM
Originally posted by RPGreg2600
Yeah, there's no way in hell vis shouold take you 7 hours! Vis takes me like 10 minutes and the entire map finishes compiling in like half an hour (talking about heckeniveau) Before when I had a bunch of ****ty brush work in DoD honfleur it wopuld take like 3 hours, but that's no where near 7 hours just for vis! Do you have a whole **** load of overlapping world brushes or something?
Edit: btw, final face light takes me literaly 1 second on every map I've ever compiled. there's no way it should be taking you 2 hours. What are yo compiling on? a P1?
I know what you mean about your earlier map taking a long time, but then improving drastically on yourself later. my very first map I ever made was dod_grave...the r_speeds were high and it took about 20 mins to compile and the whole thing was only about 45,000 square feet. My current project dod_innsbruck is 410,000 square feet with about 1500 solids and I made all areas as clean cut and efficient as possible. The highest r_speed is 600-650 and only in one tiny area, everywhere else it's about 200-400. The VIS on innsbruck takes 30-50 seconds (Full VIS) and the rest about 12-15 mins.
I'm compiling on a 1.3Ghz Athlon with 256Mb DDR RAM. And using the batch compiler.
RPGreg2600
05-23-2003, 01:58 PM
Ick, I tried compiling on an AMD 500mhz with 64MB of ram once. I gave it 24 hours and then gave up :D That was back before I installed the new CPU fan and windows XP in my good computer so it always crashed while compiling.
Craftos
05-24-2003, 02:25 AM
Start Hammer, load rmf, maximize 3D view, set 3D flat mode, then take some screenshots of different areas and post them here.
Or post bsp file without lighting.
Day of Defeat Forum Archive created by
Neil Jedrzejewski.
This in an partial archive of the old Day of Defeat forums orignally hosted by
Valve Software LLC.
Material has been archived for the purpose of creating a knowledge base from messages posted between 2003 and 2008.