Excellent work - and I'm really pleased you were able to fix the CSG error I was having without needing anymore information, good job <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
moultanoCreator of ns_shiva.Join Date: 2002-12-14Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
I've got a problem here. I don't know if this was something introduced in p15 or earlier, because I haven't used one of your builds before, but check it out. <img src='http://www.andrew.cmu.edu/user/rmoulton/error.jpg' border='0' alt='user posted image' /> I can send you the rmf if it would help. <!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1--> hlcsg v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004) 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 (webmaster@xp-cagey.com) ----- BEGIN hlcsg ----- Command line: "C:\Program Files\XP-Cagey\hlcsg.exe"-wadautodetect -cliptype simple -hullfile "C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\nshulls.txt"-chart -low "C:\0 Projects\map\ns_shiva3.map" Loading hull definitions from 'C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\nshulls.txt' Entering C:\0 Projects\map\ns_shiva3.map
Current hlcsg Settings Name | Setting | Default ---------------------|-----------|------------------------- threads [ 1 ] [ Varies ] verbose [ off ] [ off ] log [ on ] [ on ] developer [ 0 ] [ 0 ] chart [ on ] [ off ] estimate [ off ] [ off ] max texture memory [ 4194304 ] [ 4194304 ] max lighting memory [ 6291456 ] [ 6291456 ] priority [ Low ] [ Normal ]
noclip [ off ] [ off ] null texture stripping[ on ] [ on ] clipnode economy mode [ on ] [ on ] clip hull type [ simple ] [ legacy ] onlyents [ off ] [ off ] wadtextures [ on ] [ on ] skyclip [ on ] [ on ] hullfile [ C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\nshulls.txt ] [ None ] nullfile [ None ] [ None ] min surface area [ 0.500 ] [ 0.500 ] brush union threshold [ 0.000 ] [ 0.000 ]
Using mapfile wad configuration Wadfiles not in use by the map will be excluded Wadinclude list : [zhlt.wad]
Using Wadfile: C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\ns2.wad - Contains 22 used textures, 20.00 percent of map (296 textures in wad) Using Wadfile: C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\ns.wad - Contains 68 used textures, 61.82 percent of map (578 textures in wad) Using Wadfile: C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\ns_bast.wad - Contains 1 used texture, 0.91 percent of map (22 textures in wad) Using Wadfile: C:\Program Files\Valve Hammer Editor\halflife.wad - Contains 11 used textures, 10.00 percent of map (3116 textures in wad) Using Wadfile: c:\0 projects\map\ns_shiva.wad - Contains 8 used textures, 7.27 percent of map (8 textures in wad)
added 4 additional animating textures. Texture usage is at 3.44 mb (of 4.00 mb MAX) 190.48 seconds elapsed [3m 10s]
----- END hlcsg -----
hlbsp v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004) 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 (webmaster@xp-cagey.com) ----- BEGIN hlbsp ----- Command line: "C:\Program Files\XP-Cagey\hlbsp.exe"-chart -low "C:\0 Projects\map\ns_shiva3.map"
Current hlbsp Settings Name | Setting | Default -------------------|-----------|------------------------- threads [ 1 ] [ Varies ] verbose [ off ] [ off ] log [ on ] [ on ] developer [ 0 ] [ 0 ] chart [ on ] [ off ] estimate [ off ] [ off ] max texture memory [ 4194304 ] [ 4194304 ] priority [ Low ] [ 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)
<!--QuoteBegin-moultano+Jun 4 2004, 07:39 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (moultano @ Jun 4 2004, 07:39 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I can send you the rmf if it would help. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I'm going to try to reproduce it on a simpler map first, but I may end up asking you for the exported map file.
Were you running Merl's build earlier?
The most likely source of the problem in that picture would be a regression caused by the opaque entity lighting bugfix -- I tested lighting using several maps to confirm the opaques were lighting properly, but those maps might not have covered a special case. I'm pretty confident that the lighting between p11 and 1.7 is identical, so the p15 change is the likely culprit.
Does the entire map have that black-or-fullbright look, or is it just the one hallway?
moultanoCreator of ns_shiva.Join Date: 2002-12-14Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
edited June 2004
I should have described it more clearly. In the compiled version that hallway was clipped off entirely with an invisible brush, and there were HoM effects around the edges. This happened in several places around that area. The lights that aren't showing up are in the area that was erroneously solid.
<!--QuoteBegin-moultano+Jun 4 2004, 08:21 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (moultano @ Jun 4 2004, 08:21 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I should have described it more clearly. In the compiled version that hallway was clipped of entirely with an invisible brush. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Try settting -maxnodesize 2048 in HLBSP, and step it up to 4096 and 8192 if the problem persists.
The HLBSP algorithm for chopping the world down to the max node size runs before more careful checks, and disregards how healthy preliminary cuts are in terms of chopping up neighboring faces. Raising the max node size reduces the number of times the faster cuts are made, resulting in a more precise hull and potentially much slower compile times.
If all else fails, you could try setting the cliptype back to legacy.
EDIT: Let me know what happens when you run HLCSG / HLBSP / HLVIS... if the lipping problems aren't solved, don't bother running HLRAD since it's taking over an hour.
could this be it <!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Warning: Leaf portals saw into leaf Problem at portal between leaves 2201 and 2202: (2704.000 -1365.334 -416.000) (2704.000 -1344.000 -400.000) (2624.000 -1344.000 -320.000) (2624.000 -1344.000 -320.000) (2624.000 -1472.000 -416.000)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
I've got a problem that's just sprung up with the new opaque code in p15. No matter what light flags I use, I can no longer have entity brushes block light. No longer do my ns_nothing style light partitions owrk and light that I want trapped behind a grate-textured func_wall floods the room <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
moultanoCreator of ns_shiva.Join Date: 2002-12-14Member: 10806Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Gold, NS2 Community Developer, Pistachionauts
edited June 2004
<!--QuoteBegin-Vahn_Paktu+Jun 4 2004, 02:24 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Vahn_Paktu @ Jun 4 2004, 02:24 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> could this be it <!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Warning: Leaf portals saw into leaf Problem at portal between leaves 2201 and 2202: (2704.000 -1365.334 -416.000) (2704.000 -1344.000 -400.000) (2624.000 -1344.000 -320.000) (2624.000 -1344.000 -320.000) (2624.000 -1472.000 -416.000)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> It is probably related, but I didn't have that problem before. Its new.
Update: Running it in legacy mode fixed the problem, but I didn't have this problem using other clipping settings in p10
Update: Now the same problem is occurring when I use the p10 tools. This must have snuck in there while I was looking primarily at other parts of the map and didn't notice.
Update: It appears that the problem is with the simple flag on csg, and is in both p10 and p15
<!--QuoteBegin-Tequila+Jun 4 2004, 11:37 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Tequila @ Jun 4 2004, 11:37 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I've got a problem that's just sprung up with the new opaque code in p15. No matter what light flags I use, I can no longer have entity brushes block light. No longer do my ns_nothing style light partitions owrk and light that I want trapped behind a grate-textured func_wall floods the room <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Is the unblocked light an entity or a texture light? Is the unblocked light at least 2 full units behind the object casting the shadow?
<!--QuoteBegin-moultano+Jun 4 2004, 02:01 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (moultano @ Jun 4 2004, 02:01 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Ok I believe I have isolated it. The problem occurs when the cliptype is set to simple, and from what I can tell that is the only time it occurs. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> HLBSP still chokes on the more complex brush shapes that simple (despite its name, it's doing extra beveling; simple is less complex than precise but more complex than legacy) clipping produces, and I'm trying to work through where the remaining problems are coming from--the expanded brush shapes generated by HLCSG are correct.
If you could give me a copy of your rmf to use as a test case, I'd appreciate it; this is the first time I've heard of HOM being involved, and it indicates to me that the vis hull is also having problems under HLBSP even though it isn't being expanded in HLCSG.
I would have been really suprised if the problem was new to p14/p15, since the changes to SolidBSP were cosmetic and optimization merely strips unused information.
<!--QuoteBegin-XP-Cagey+Jun 4 2004, 11:41 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jun 4 2004, 11:41 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin-Tequila+Jun 4 2004, 11:37 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Tequila @ Jun 4 2004, 11:37 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I've got a problem that's just sprung up with the new opaque code in p15. No matter what light flags I use, I can no longer have entity brushes block light. No longer do my ns_nothing style light partitions owrk and light that I want trapped behind a grate-textured func_wall floods the room <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo--> <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Is the unblocked light an entity or a texture light? Is the unblocked light at least 2 full units behind the object casting the shadow? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> I've tried it with both texture lights and point lights, and with the light being embedded in the brush and also free behind the brush. All yield the same result <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
Mh, new problem... BuildVisLeafs is slow. Really slow. It takes 3 hours to reach 700/7790 on ns_enceladus with p15. p13 needs >45mins for the whole thing <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
I had an env_sprite and a light with the same name, so that I could turn them on and off together as part of a blinking emergency light. Prior to doing an only ents compile this setup was working perfectly for days. Then I did an only ents compile and the sprite turned on when the light turned off.
Doing a full compile returned the sprite and light back to their original working state.
Using Wadfile: \games or programs\counter-strike\valve\halflife.wad - Contains 27 used textures, 19.57 percent of map (3116 textures in wad) Including Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\coblet.wad - Contains 4 used textures, 2.90 percent of map (4 textures in wad) Using Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\ghost.wad - Contains 61 used textures, 44.20 percent of map (424 textures in wad) Using Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\govehicles.wad - Contains 40 used textures, 28.99 percent of map (75 textures in wad) Using Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\graffiti.wad - Contains 6 used textures, 4.35 percent of map (6 textures in wad)
added 20 additional animating textures. Texture usage is at 7.60 mb (of 9.77 mb MAX) 46.25 seconds elapsed
----- END hlcsg -----
hlbsp v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004) 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 (webmaster@xp-cagey.com) ----- BEGIN hlbsp ----- Command line: "D:\Program Files\ZHLT\hlbsp.exe"-maxnodesize 1024 -chart -texdata 10000 "D:\edd\My Documents\meh\urbane\go_urbane.map"
Current hlbsp Settings Name | Setting | Default -------------------|-----------|------------------------- threads [ 1 ] [ Varies ] verbose [ off ] [ off ] log [ on ] [ on ] developer [ 0 ] [ 0 ] chart [ on ] [ off ] estimate [ off ] [ off ] max texture memory [ 10240000 ] [ 4194304 ] priority [ Normal ] [ 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...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...7622 (1.17 seconds) BSP generation successful, writing portal file 'D:\edd\My Documents\meh\urbane\go_urbane.prt' SolidBSP [hull 1] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8286 (1.34 seconds) SolidBSP [hull 2] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7454 (1.19 seconds) SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8500...8794 (1.53 seconds) Error: ReadSurfs (line 14447): 40 > MAXPOINTS This is caused by a face with too many verticies (typically found on end-caps of high-poly cylinders)
----- END hlbsp -----
hlvis v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004) 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 (webmaster@xp-cagey.com) ----- BEGIN hlvis ----- Command line: "D:\Program Files\ZHLT\hlvis.exe"-full -chart -texdata 10000 "D:\edd\My Documents\meh\urbane\go_urbane.map" >> There was a problem compiling the map. >> Check the file D:\edd\My Documents\meh\urbane\go_urbane.log for the cause.
----- END hlvis -----
hlrad v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004) 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 (webmaster@xp-cagey.com) ----- BEGIN hlrad ----- Command line: "D:\Program Files\ZHLT\hlrad.exe"-sparse -bounce 4 -smooth 80 -coring 0.01 -chart -texdata 10000 "D:\edd\My Documents\meh\urbane\go_urbane.map" >> There was a problem compiling the map. >> Check the file D:\edd\My Documents\meh\urbane\go_urbane.log for the cause.
Never had that before <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Mh, new problem... BuildVisLeafs is slow. Really slow. It takes 3 hours to reach 700/7790 on ns_enceladus with p15. p13 needs >45mins for the whole thing <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Could this have something to do with the modified p15 opaque ents?
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I've got a problem that's just sprung up with the new opaque code in p15. No matter what light flags I use, I can no longer have entity brushes block light. No longer do my ns_nothing style light partitions owrk and light that I want trapped behind a grate-textured func_wall floods the room<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Well i tried doing a test myself..... opaque ents work for texlights, light_spot (point light) and light_environment (its works like a texlight?)
Just to prove this i took a screenie. I have used auto-contrast to show the shadows more accurately.... what baffles me is where the shadows are. in all three case they are on the wall mostly - the lights are all "pointing" down. the texlight and the light_environment both have a ordinary brush tube coming down from them to effectively point the light straight down.. why are the shadows not UNDERNEATH the boxes?
moultano: until such time as there is a fix for this sort of thing (I have had similar on a few occasions...) all you can do is simplify the geometry there or use the dreded func_wall.
Would double precision math in CSG/BSP help this sort of thing out? (or has that happened already?)
<!--QuoteBegin-FragBait0+Jun 6 2004, 06:42 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ Jun 6 2004, 06:42 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Could this have something to do with the modified p15 opaque ents?<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Nope, ents are ignored by the entire VIS process and use a different algorithm to determine when they're in the view.
I didn't change a line of VIS for p14-p15 except for the new file handler, which wouldn't affect this. Sir Pepe, were you running programs in the background when you had the 3 hour time? Running a multimedia program (even a screensaver) can starve the tools of CPU unless you set them to high priority. Having them take 4 times longer is entirely possible if they're splitting CPU with a demanding application.
------------------------
<!--QuoteBegin-FragBait0+Jun 6 2004, 06:42 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ Jun 6 2004, 06:42 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Would double precision math in CSG/BSP help this sort of thing out? (or has that happened already?)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Tried it for p14 pre-release, and it didn't solve the problem -- in fact, it can cause new problems when working with Quark maps that aren't snapped to the grid on export since Quark apparently uses shares the single precision error thresholds of the tools. If I make the tools more precise, it can cause new leaks in Quark maps.
------------------------
<!--QuoteBegin-FragBait0+Jun 6 2004, 06:42 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ Jun 6 2004, 06:42 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Well i tried doing a test myself..... opaque ents work for texlights, light_spot (point light) and light_environment (its works like a texlight?)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
They worked in my test maps as well, but I still want to figure out what may be different about his settings to cause the problem.
[quote=FragBait0,Jun 6 2004, 06:42 AM]Just to prove this i took a screenie. I have used auto-contrast to show the shadows more accurately.... what baffles me is where the shadows are. in all three case they are on the wall mostly - the lights are all "pointing" down. the texlight and the light_environment both have a ordinary brush tube coming down from them to effectively point the light straight down.. why are the shadows not UNDERNEATH the boxes?[quote]
It looks from the screenshot like the light_environment is being interpreted as set from an angle -- what settings did you use? Putting light_environment in a brush tube doesn't restrict the light it casts -- the light is rendered like the sun, always at the same angle and over the entire map wherever sky is used-- is your ceiling a sky texture?
You might have meant to use a light_spot instead. Perhaps attaching your test map would shed some light on the exact settings you used.
<!--QuoteBegin-Mendasp+Jun 5 2004, 02:20 AM, 06:42 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Mendasp @ Jun 5 2004, 02:20 AM, 06:42 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Anything new about the strange clipping holes? because I'm getting one of them in bast...
I also get strange invisible walls (with cliptype -precise), and I can't use -cliptype legacy because I've gone over the limit D:<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Using -maxnodesize 8192 completely fixed the bad clipping in the example map posted a few pages back, but it hasn't fixed the problem in more complex maps -- I know that one of Yama's maps still has issues with 8192 node size, and moultano's map got worse.
The extra non-axial planes generated by -cliptype precise wreak havoc with code in SolidBSP that throws out small area surfaces because they increase the chance of a split chopping a surface into triangles with area below the threshold--I haven't pinpointed the exact cause, but information is being thrown out at the wrong time.
------------------------
<!--QuoteBegin-Yamakazi+ Jun 5 2004, 03:27 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Yamakazi @ Jun 5 2004, 03:27 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Only Ents seems to have odd behaviour in P15.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
See if adding -noopt to HLBSP fixes the problem; it skips plane optimization so that the map and bsp files agree on plane assignments. I wouldn't have predicted that optimization would cause an entity problem, but it's the most likely change I can think of.
------------------------
<!--QuoteBegin-Cobra^+Jun 5 2004, 04:47 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Cobra^ @ Jun 5 2004, 04:47 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Never had that before <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--><!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->Error: ReadSurfs (line 14447): 40 > MAXPOINTS This is caused by a face with too many verticies (typically found on end-caps of high-poly cylinders)<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Make any recent changes to the map? Or to the compile settings? The BSP algorithm didn't change, I just added a function that prints progress. The plane optimization takes place after every tree in the map has been calculated and I know what the final plane use will be.
I'll try to see if MAXPOINTS is another stupid internal limit that can be raised, or if it's an engine liimitation.
<!--QuoteBegin-XP-Cagey+Jun 6 2004, 10:26 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jun 6 2004, 10:26 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I didn't change a line of VIS for p14-p15 except for the new file handler, which wouldn't affect this. Sir Pepe, were you running programs in the background when you had the 3 hour time? Running a multimedia program (even a screensaver) can starve the tools of CPU unless you set them to high priority. Having them take 4 times longer is entirely possible if they're splitting CPU with a demanding application. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Eh, i meant BuildVisLeafs, this thing in rad after BuildFaceLights and noting in VIS itself <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
And no, there were no programs running in the background and HLRAD was run with -high
Others wo tried to compile the map with p15 reported the same problem btw... <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
<!--QuoteBegin-XP-Cagey+Jun 6 2004, 04:28 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jun 6 2004, 04:28 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Make any recent changes to the map? Or to the compile settings? The BSP algorithm didn't change, I just added a function that prints progress. The plane optimization takes place after every tree in the map has been calculated and I know what the final plane use will be.
I'll try to see if MAXPOINTS is another stupid internal limit that can be raised, or if it's an engine liimitation. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> My mistake - I fixed it through deleting a prefab someone had made for me. Deleting the prefab also brought my texture memory down, so we are all happy about that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
<!--QuoteBegin--Sir_Pepe-+Jun 6 2004, 07:33 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (-Sir_Pepe- @ Jun 6 2004, 07:33 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> <!--QuoteBegin-XP-Cagey+Jun 6 2004, 10:26 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (XP-Cagey @ Jun 6 2004, 10:26 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I didn't change a line of VIS for p14-p15 except for the new file handler, which wouldn't affect this. Sir Pepe, were you running programs in the background when you had the 3 hour time? Running a multimedia program (even a screensaver) can starve the tools of CPU unless you set them to high priority. Having them take 4 times longer is entirely possible if they're splitting CPU with a demanding application. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> Eh, i meant BuildVisLeafs, this thing in rad after BuildFaceLights and noting in VIS itself <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
And no, there were no programs running in the background and HLRAD was run with -high
Others wo tried to compile the map with p15 reported the same problem btw... <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Sorry about that -- brain's on autopilot at 8 AM my time <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
It's possible that the extra check to see if the opaque face number hit matches the current face number (which allows opaque faces to light properly) is slowing things down--I certainly wouldn't have expected a factor of four though! How many opaque faces does your map use?
If the answer is '0', then the overhead of an extra parameter on the stack for several function calls is the only possible slowdown I can think of.
I can think of an optimization to the opaque code that should reduce the overall time in the special case that an opaque face is hit (which should balance or exceed the slowdown that opaque faces are apparently causing)... I'll try adding the optimization for p16.
I still get this problem, maybe I'm just an isolated case. No matter, because it doesn't interfere with my map's visual quality, I've already worked around it <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
Thanks for the assistance, and of course the fantastic tools Cagey.
Pepe isn't the only one getting this problem <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
One variable on the stack can't cause this, because if you REMOVED one variable the time should go down to -2,5 hours according to your theory, right? <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> Even if a memory operand instead of CPU registers only has to be used can the time go up like that?!? I mean FOUR TIMES, hey that's enormeous. Better run a DIFF on both versions of the code to go sure... And I'm really sorry for you XP-Cagey, seems like you have a lot of work for the next weeks :/ . I don't even get my own 'does this cube intersect with that polygon' code to work. Don't want to know how complex the mapping tools are!
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->It looks from the screenshot like the light_environment is being interpreted as set from an angle -- what settings did you use? Putting light_environment in a brush tube doesn't restrict the light it casts -- the light is rendered like the sun, always at the same angle and over the entire map wherever sky is used-- is your ceiling a sky texture?
You might have meant to use a light_spot instead. Perhaps attaching your test map would shed some light on the exact settings you used.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
They are right to left a texlight, a light_spot and a light_environment. I didn't explain the light_environment too well. Its a small sky patch in the ceiling, I then put a brush tube extending down from that. The light_environment is set to point straight down as is the light_spot. The texlight on the right has a small brush tube. The idea of the brush tube is to help restrict the light_environment to shining only on that cube.
I was going to attach the map last post but alas you dont seem to be able to attach more than one thing. meh. I probably could have used image tags or something...|>|-|34R the NS forum n00b. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> Its a very ugly map but it should do the trick...
<!--QuoteBegin-NerdIII+Jun 6 2004, 03:03 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (NerdIII @ Jun 6 2004, 03:03 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> One variable on the stack can't cause this, because if you REMOVED one variable the time should go down to -2,5 hours according to your theory, right? <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> Even if a memory operand instead of CPU registers only has to be used can the time go up like that?!? I mean FOUR TIMES, hey that's enormeous. Better run a DIFF on both versions of the code to go sure... And I'm really sorry for you XP-Cagey, seems like you have a lot of work for the next weeks :/ . I don't even get my own 'does this cube intersect with that polygon' code to work. Don't want to know how complex the mapping tools are! <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd--> Well, like I said, if he had 0 opaque faces, that was the only change I could think of.. but he had over 1100 so the other changes to the opaque code are the probable issue <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.
Comments
<img src='http://www.andrew.cmu.edu/user/rmoulton/error.jpg' border='0' alt='user posted image' />
I can send you the rmf if it would help.
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->
hlcsg v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004)
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 (webmaster@xp-cagey.com)
----- BEGIN hlcsg -----
Command line: "C:\Program Files\XP-Cagey\hlcsg.exe"-wadautodetect -cliptype simple -hullfile "C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\nshulls.txt"-chart -low "C:\0 Projects\map\ns_shiva3.map"
Loading hull definitions from 'C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\nshulls.txt'
Entering C:\0 Projects\map\ns_shiva3.map
Current hlcsg Settings
Name | Setting | Default
---------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ Low ] [ Normal ]
noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ on ] [ on ]
clip hull type [ simple ] [ legacy ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\nshulls.txt ] [ None ]
nullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]
Using mapfile wad configuration
Wadfiles not in use by the map will be excluded
Wadinclude list :
[zhlt.wad]
61 brushes (totalling 353 sides) discarded from clipping hulls
CreateBrush:
(144.33 seconds)
SetModelCenters:
(0.02 seconds)
CSGBrush:
(43.80 seconds)
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 0/400 0/25600 ( 0.0%)
planes 21756/32768 435120/655360 (66.4%)
vertexes 0/65535 0/786420 ( 0.0%)
nodes 0/32767 0/786408 ( 0.0%)
texinfos 10754/32767 430160/1310680 (32.8%)
faces 0/65535 0/1310700 ( 0.0%)
clipnodes 0/32767 0/262136 ( 0.0%)
leaves 0/8192 0/229376 ( 0.0%)
marksurfaces 0/65535 0/131070 ( 0.0%)
surfedges 0/512000 0/2048000 ( 0.0%)
edges 0/256000 0/1024000 ( 0.0%)
texdata [variable] 0/4194304 ( 0.0%)
lightdata [variable] 0/6291456 ( 0.0%)
visdata [variable] 0/2097152 ( 0.0%)
entdata [variable] 0/524288 ( 0.0%)
0 textures referenced
=== Total BSP file data space used: 865280 bytes ===
Using Wadfile: C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\ns2.wad
- Contains 22 used textures, 20.00 percent of map (296 textures in wad)
Using Wadfile: C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\ns.wad
- Contains 68 used textures, 61.82 percent of map (578 textures in wad)
Using Wadfile: C:\Program Files\Steam\SteamApps\moultano@yahoo.com\half-life\nsp\ns_bast.wad
- Contains 1 used texture, 0.91 percent of map (22 textures in wad)
Using Wadfile: C:\Program Files\Valve Hammer Editor\halflife.wad
- Contains 11 used textures, 10.00 percent of map (3116 textures in wad)
Using Wadfile: c:\0 projects\map\ns_shiva.wad
- Contains 8 used textures, 7.27 percent of map (8 textures in wad)
added 4 additional animating textures.
Texture usage is at 3.44 mb (of 4.00 mb MAX)
190.48 seconds elapsed [3m 10s]
----- END hlcsg -----
hlbsp v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004)
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 (webmaster@xp-cagey.com)
----- BEGIN hlbsp -----
Command line: "C:\Program Files\XP-Cagey\hlbsp.exe"-chart -low "C:\0 Projects\map\ns_shiva3.map"
Current hlbsp Settings
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
priority [ Low ] [ 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...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8500...9000...9464 (3.81 seconds)
BSP generation successful, writing portal file 'C:\0 Projects\map\ns_shiva3.prt'
SolidBSP [hull 1] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8500...8530 (2.20 seconds)
SolidBSP [hull 2] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7064 (1.36 seconds)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8500...9000...9066 (2.13 seconds)
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 86/400 5504/25600 (21.5%)
planes 5721/32768 114420/655360 (17.5%)
vertexes 18218/65535 218616/786420 (27.8%)
nodes 7583/32767 181992/786408 (23.1%)
texinfos 10754/32767 430160/1310680 (32.8%)
faces 13669/65535 273380/1310700 (20.9%)
clipnodes 18364/32767 146912/262136 (56.0%)
leaves 3804/8192 106512/229376 (46.4%)
marksurfaces 17154/65535 34308/131070 (26.2%)
surfedges 61992/512000 247968/2048000 (12.1%)
edges 32338/256000 129352/1024000 (12.6%)
texdata [variable] 5020/4194304 ( 0.1%)
lightdata [variable] 0/6291456 ( 0.0%)
visdata [variable] 0/2097152 ( 0.0%)
entdata [variable] 104037/524288 (19.8%)
114 textures referenced
=== Total BSP file data space used: 1998181 bytes ===
89.13 seconds elapsed [1m 29s]
----- END hlbsp -----
hlvis v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004)
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 (webmaster@xp-cagey.com)
----- BEGIN hlvis -----
Command line: "C:\Program Files\XP-Cagey\hlvis.exe"-full -chart -low "C:\0 Projects\map\ns_shiva3.map"
2713 portalleafs
7946 numportals
-= Current hlvis Settings =-
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max vis distance [ 0 ] [ 0 ]
priority [ Low ] [ Normal ]
fast vis [ off ] [ off ]
full vis [ on ] [ off ]
BasePortalVis:
(76.63 seconds)
LeafThread:
(1225.11 seconds)
Warning: Leaf portals saw into leaf
Problem at portal between leaves 2201 and 2202:
(2704.000 -1365.334 -416.000)
(2704.000 -1344.000 -400.000)
(2624.000 -1344.000 -320.000)
(2624.000 -1344.000 -320.000)
(2624.000 -1472.000 -416.000)
average leafs visible: 156
g_visdatasize:120735 compressed from 922420
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 86/400 5504/25600 (21.5%)
planes 5721/32768 114420/655360 (17.5%)
vertexes 18218/65535 218616/786420 (27.8%)
nodes 7583/32767 181992/786408 (23.1%)
texinfos 10754/32767 430160/1310680 (32.8%)
faces 13669/65535 273380/1310700 (20.9%)
clipnodes 18364/32767 146912/262136 (56.0%)
leaves 3804/8192 106512/229376 (46.4%)
marksurfaces 17154/65535 34308/131070 (26.2%)
surfedges 61992/512000 247968/2048000 (12.1%)
edges 32338/256000 129352/1024000 (12.6%)
texdata [variable] 5020/4194304 ( 0.1%)
lightdata [variable] 0/6291456 ( 0.0%)
visdata [variable] 120735/2097152 ( 5.8%)
entdata [variable] 104037/524288 (19.8%)
114 textures referenced
=== Total BSP file data space used: 2118916 bytes ===
1302.33 seconds elapsed [21m 42s]
----- END hlvis -----
hlrad v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004)
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 (webmaster@xp-cagey.com)
----- BEGIN hlrad -----
Command line: "C:\Program Files\XP-Cagey\hlrad.exe"-extra -sparse -notexscale -bounce 2 -smooth 80 -gamma 0.95 -chart -low "C:\0 Projects\map\ns_shiva3.map"
-= Current hlrad Settings =-
Name | Setting | Default
--------------------|---------------------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 4194304 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ Low ] [ Normal ]
vismatrix algorithm [ Sparse ] [ Original ]
oversampling (-extra)[ on ] [ off ]
bounces [ 2 ] [ 1 ]
bounce dynamic light [ on ] [ 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 [ 80.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 [ off ] [ 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.950 0.950 0.950 ] [ 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 ]
[Reading texlights from 'C:\0 Projects\map\lights.rad']
[107 texlights parsed from 'C:\0 Projects\map\lights.rad']
13669 faces
Create Patches : 61571 base patches
0 opaque faces
364777 square feet [52527888.00 square inches]
11708 direct lights
BuildFacelights:
(3097.27 seconds)
BuildVisLeafs:
(536.16 seconds)
visibility matrix : 17.3 megs
MakeScales:
(1283.94 seconds)
SwapTransfers:
(56.42 seconds)
Transfer Lists : 41199630 : 41.20M transfers
Indices : 27986204 : 26.69M bytes
Data : 164798520 : 157.16M bytes
GatherLight:
(6.94 seconds)
GatherLight:
(6.86 seconds)
FinalLightFace:
(9.30 seconds)
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 86/400 5504/25600 (21.5%)
planes 5721/32768 114420/655360 (17.5%)
vertexes 18218/65535 218616/786420 (27.8%)
nodes 7583/32767 181992/786408 (23.1%)
texinfos 10754/32767 430160/1310680 (32.8%)
faces 13669/65535 273380/1310700 (20.9%)
clipnodes 18364/32767 146912/262136 (56.0%)
leaves 3804/8192 106512/229376 (46.4%)
marksurfaces 17154/65535 34308/131070 (26.2%)
surfedges 61992/512000 247968/2048000 (12.1%)
edges 32338/256000 129352/1024000 (12.6%)
texdata [variable] 5020/4194304 ( 0.1%)
lightdata [variable] 1279620/6291456 (20.3%)
visdata [variable] 120735/2097152 ( 5.8%)
entdata [variable] 104037/524288 (19.8%)
114 textures referenced
=== Total BSP file data space used: 3398536 bytes ===
5022.77 seconds elapsed [1h 23m 42s]
----- END hlrad -----
<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
The leaf portal saw into leaf error didn't occur before.
<!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
I'm going to try to reproduce it on a simpler map first, but I may end up asking you for the exported map file.
Were you running Merl's build earlier?
The most likely source of the problem in that picture would be a regression caused by the opaque entity lighting bugfix -- I tested lighting using several maps to confirm the opaques were lighting properly, but those maps might not have covered a special case. I'm pretty confident that the lighting between p11 and 1.7 is identical, so the p15 change is the likely culprit.
Does the entire map have that black-or-fullbright look, or is it just the one hallway?
Update: the version I was using before was p10
Anything you would like me to test?
Try settting -maxnodesize 2048 in HLBSP, and step it up to 4096 and 8192 if the problem persists.
The HLBSP algorithm for chopping the world down to the max node size runs before more careful checks, and disregards how healthy preliminary cuts are in terms of chopping up neighboring faces. Raising the max node size reduces the number of times the faster cuts are made, resulting in a more precise hull and potentially much slower compile times.
If all else fails, you could try setting the cliptype back to legacy.
EDIT: Let me know what happens when you run HLCSG / HLBSP / HLVIS... if the lipping problems aren't solved, don't bother running HLRAD since it's taking over an hour.
Edit: also happens with 8192
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Warning: Leaf portals saw into leaf
Problem at portal between leaves 2201 and 2202:
(2704.000 -1365.334 -416.000)
(2704.000 -1344.000 -400.000)
(2624.000 -1344.000 -320.000)
(2624.000 -1344.000 -320.000)
(2624.000 -1472.000 -416.000)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Warning: Leaf portals saw into leaf
Problem at portal between leaves 2201 and 2202:
(2704.000 -1365.334 -416.000)
(2704.000 -1344.000 -400.000)
(2624.000 -1344.000 -320.000)
(2624.000 -1344.000 -320.000)
(2624.000 -1472.000 -416.000)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd--> <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
It is probably related, but I didn't have that problem before. Its new.
Update: Running it in legacy mode fixed the problem, but I didn't have this problem using other clipping settings in p10
Update: Now the same problem is occurring when I use the p10 tools. This must have snuck in there while I was looking primarily at other parts of the map and didn't notice.
Update: It appears that the problem is with the simple flag on csg, and is in both p10 and p15
Is the unblocked light an entity or a texture light? Is the unblocked light at least 2 full units behind the object casting the shadow?
HLBSP still chokes on the more complex brush shapes that simple (despite its name, it's doing extra beveling; simple is less complex than precise but more complex than legacy) clipping produces, and I'm trying to work through where the remaining problems are coming from--the expanded brush shapes generated by HLCSG are correct.
If you could give me a copy of your rmf to use as a test case, I'd appreciate it; this is the first time I've heard of HOM being involved, and it indicates to me that the vis hull is also having problems under HLBSP even though it isn't being expanded in HLCSG.
I would have been really suprised if the problem was new to p14/p15, since the changes to SolidBSP were cosmetic and optimization merely strips unused information.
Is the unblocked light an entity or a texture light? Is the unblocked light at least 2 full units behind the object casting the shadow? <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
I've tried it with both texture lights and point lights, and with the light being embedded in the brush and also free behind the brush. All yield the same result <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
p13 needs >45mins for the whole thing <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html//emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif' /><!--endemo-->
I also get strange invisible walls (with cliptype -precise), and I can't use -cliptype legacy because I've gone over the limit D:
I had an env_sprite and a light with the same name, so that I could turn them on and off together as part of a blinking emergency light. Prior to doing an only ents compile this setup was working perfectly for days. Then I did an only ents compile and the sprite turned on when the light turned off.
Doing a full compile returned the sprite and light back to their original working state.
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 (webmaster@xp-cagey.com)
----- BEGIN hlcsg -----
Command line: "D:\Program Files\ZHLT\hlcsg.exe"-wadinclude coblet.wad -chart -texdata 10000 "D:\edd\My Documents\meh\urbane\go_urbane.map"
Entering D:\edd\My Documents\meh\urbane\go_urbane.map
Current hlcsg Settings
Name | Setting | Default
---------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 10240000 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ Normal ] [ Normal ]
noclip [ off ] [ off ]
null texture stripping[ on ] [ on ]
clipnode economy mode [ on ] [ on ]
clip hull type [ legacy ] [ legacy ]
onlyents [ off ] [ off ]
wadtextures [ on ] [ on ]
skyclip [ on ] [ on ]
hullfile [ None ] [ None ]
nullfile [ None ] [ None ]
min surface area [ 0.500 ] [ 0.500 ]
brush union threshold [ 0.000 ] [ 0.000 ]
Using mapfile wad configuration
Wadinclude list :
[zhlt.wad]
[coblet.wad]
39 brushes (totalling 236 sides) discarded from clipping hulls
CreateBrush:
(31.56 seconds)
SetModelCenters:
(0.00 seconds)
CSGBrush:
(10.19 seconds)
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 0/400 0/25600 ( 0.0%)
planes 23580/32768 471600/655360 (72.0%)
vertexes 0/65535 0/786420 ( 0.0%)
nodes 0/32767 0/786408 ( 0.0%)
texinfos 3553/32767 142120/1310680 (10.8%)
faces 0/65535 0/1310700 ( 0.0%)
clipnodes 0/32767 0/262136 ( 0.0%)
leaves 0/8192 0/229376 ( 0.0%)
marksurfaces 0/65535 0/131070 ( 0.0%)
surfedges 0/512000 0/2048000 ( 0.0%)
edges 0/256000 0/1024000 ( 0.0%)
texdata [variable] 0/10240000 ( 0.0%)
lightdata [variable] 0/6291456 ( 0.0%)
visdata [variable] 0/2097152 ( 0.0%)
entdata [variable] 0/524288 ( 0.0%)
0 textures referenced
=== Total BSP file data space used: 613720 bytes ===
Using Wadfile: \games or programs\counter-strike\valve\halflife.wad
- Contains 27 used textures, 19.57 percent of map (3116 textures in wad)
Including Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\coblet.wad
- Contains 4 used textures, 2.90 percent of map (4 textures in wad)
Using Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\ghost.wad
- Contains 61 used textures, 44.20 percent of map (424 textures in wad)
Using Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\govehicles.wad
- Contains 40 used textures, 28.99 percent of map (75 textures in wad)
Using Wadfile: \program files\steam\steamapps\killer_eddy@steel-dragon.co.uk\half-life\ghost\graffiti.wad
- Contains 6 used textures, 4.35 percent of map (6 textures in wad)
added 20 additional animating textures.
Texture usage is at 7.60 mb (of 9.77 mb MAX)
46.25 seconds elapsed
----- END hlcsg -----
hlbsp v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004)
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 (webmaster@xp-cagey.com)
----- BEGIN hlbsp -----
Command line: "D:\Program Files\ZHLT\hlbsp.exe"-maxnodesize 1024 -chart -texdata 10000 "D:\edd\My Documents\meh\urbane\go_urbane.map"
Current hlbsp Settings
Name | Setting | Default
-------------------|-----------|-------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 0 ] [ 0 ]
chart [ on ] [ off ]
estimate [ off ] [ off ]
max texture memory [ 10240000 ] [ 4194304 ]
priority [ Normal ] [ 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...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...7622 (1.17 seconds)
BSP generation successful, writing portal file 'D:\edd\My Documents\meh\urbane\go_urbane.prt'
SolidBSP [hull 1] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8286 (1.34 seconds)
SolidBSP [hull 2] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7454 (1.19 seconds)
SolidBSP [hull 3] 500...1000...1500...2000...2500...3000...3500...4000...4500...5000...5500...6000...6500...7000...7500...8000...8500...8794 (1.53 seconds)
Error: ReadSurfs (line 14447): 40 > MAXPOINTS
This is caused by a face with too many verticies (typically found on end-caps of high-poly cylinders)
----- END hlbsp -----
hlvis v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004)
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 (webmaster@xp-cagey.com)
----- BEGIN hlvis -----
Command line: "D:\Program Files\ZHLT\hlvis.exe"-full -chart -texdata 10000 "D:\edd\My Documents\meh\urbane\go_urbane.map"
>> There was a problem compiling the map.
>> Check the file D:\edd\My Documents\meh\urbane\go_urbane.log for the cause.
----- END hlvis -----
hlrad v2.5.3 rel Custom Build 1.7p15 (Jun 3 2004)
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 (webmaster@xp-cagey.com)
----- BEGIN hlrad -----
Command line: "D:\Program Files\ZHLT\hlrad.exe"-sparse -bounce 4 -smooth 80 -coring 0.01 -chart -texdata 10000 "D:\edd\My Documents\meh\urbane\go_urbane.map"
>> There was a problem compiling the map.
>> Check the file D:\edd\My Documents\meh\urbane\go_urbane.log for the cause.
----- END hlrad -----
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Never had that before <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
p13 needs >45mins for the whole thing <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Could this have something to do with the modified p15 opaque ents?
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->I've got a problem that's just sprung up with the new opaque code in p15. No matter what light flags I use, I can no longer have entity brushes block light. No longer do my ns_nothing style light partitions owrk and light that I want trapped behind a grate-textured func_wall floods the room<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Well i tried doing a test myself..... opaque ents work for texlights, light_spot (point light) and light_environment (its works like a texlight?)
Just to prove this i took a screenie. I have used auto-contrast to show the shadows more accurately.... what baffles me is where the shadows are. in all three case they are on the wall mostly - the lights are all "pointing" down. the texlight and the light_environment both have a ordinary brush tube coming down from them to effectively point the light straight down.. why are the shadows not UNDERNEATH the boxes?
moultano: until such time as there is a fix for this sort of thing (I have had similar on a few occasions...) all you can do is simplify the geometry there or use the dreded func_wall.
Would double precision math in CSG/BSP help this sort of thing out? (or has that happened already?)
Nope, ents are ignored by the entire VIS process and use a different algorithm to determine when they're in the view.
I didn't change a line of VIS for p14-p15 except for the new file handler, which wouldn't affect this. Sir Pepe, were you running programs in the background when you had the 3 hour time? Running a multimedia program (even a screensaver) can starve the tools of CPU unless you set them to high priority. Having them take 4 times longer is entirely possible if they're splitting CPU with a demanding application.
------------------------
<!--QuoteBegin-FragBait0+Jun 6 2004, 06:42 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ Jun 6 2004, 06:42 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Would double precision math in CSG/BSP help this sort of thing out? (or has that happened already?)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Tried it for p14 pre-release, and it didn't solve the problem -- in fact, it can cause new problems when working with Quark maps that aren't snapped to the grid on export since Quark apparently uses shares the single precision error thresholds of the tools. If I make the tools more precise, it can cause new leaks in Quark maps.
------------------------
<!--QuoteBegin-FragBait0+Jun 6 2004, 06:42 AM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (FragBait0 @ Jun 6 2004, 06:42 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Well i tried doing a test myself..... opaque ents work for texlights, light_spot (point light) and light_environment (its works like a texlight?)<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
They worked in my test maps as well, but I still want to figure out what may be different about his settings to cause the problem.
[quote=FragBait0,Jun 6 2004, 06:42 AM]Just to prove this i took a screenie. I have used auto-contrast to show the shadows more accurately.... what baffles me is where the shadows are. in all three case they are on the wall mostly - the lights are all "pointing" down. the texlight and the light_environment both have a ordinary brush tube coming down from them to effectively point the light straight down.. why are the shadows not UNDERNEATH the boxes?[quote]
It looks from the screenshot like the light_environment is being interpreted as set from an angle -- what settings did you use? Putting light_environment in a brush tube doesn't restrict the light it casts -- the light is rendered like the sun, always at the same angle and over the entire map wherever sky is used-- is your ceiling a sky texture?
You might have meant to use a light_spot instead. Perhaps attaching your test map would shed some light on the exact settings you used.
I also get strange invisible walls (with cliptype -precise), and I can't use -cliptype legacy because I've gone over the limit D:<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Using -maxnodesize 8192 completely fixed the bad clipping in the example map posted a few pages back, but it hasn't fixed the problem in more complex maps -- I know that one of Yama's maps still has issues with 8192 node size, and moultano's map got worse.
The extra non-axial planes generated by -cliptype precise wreak havoc with code in SolidBSP that throws out small area surfaces because they increase the chance of a split chopping a surface into triangles with area below the threshold--I haven't pinpointed the exact cause, but information is being thrown out at the wrong time.
------------------------
<!--QuoteBegin-Yamakazi+ Jun 5 2004, 03:27 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Yamakazi @ Jun 5 2004, 03:27 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Only Ents seems to have odd behaviour in P15.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
See if adding -noopt to HLBSP fixes the problem; it skips plane optimization so that the map and bsp files agree on plane assignments. I wouldn't have predicted that optimization would cause an entity problem, but it's the most likely change I can think of.
------------------------
<!--QuoteBegin-Cobra^+Jun 5 2004, 04:47 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Cobra^ @ Jun 5 2004, 04:47 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Never had that before <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--><!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--c1--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->Error: ReadSurfs (line 14447): 40 > MAXPOINTS
This is caused by a face with too many verticies (typically found on end-caps of high-poly cylinders)<!--c2--></td></tr></table><div class='postcolor'><!--ec2-->
Make any recent changes to the map? Or to the compile settings? The BSP algorithm didn't change, I just added a function that prints progress. The plane optimization takes place after every tree in the map has been calculated and I know what the final plane use will be.
I'll try to see if MAXPOINTS is another stupid internal limit that can be raised, or if it's an engine liimitation.
Eh, i meant BuildVisLeafs, this thing in rad after BuildFaceLights and noting in VIS itself <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
And no, there were no programs running in the background and HLRAD was run with -high
Others wo tried to compile the map with p15 reported the same problem btw... <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
I'll try to see if MAXPOINTS is another stupid internal limit that can be raised, or if it's an engine liimitation. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
My mistake - I fixed it through deleting a prefab someone had made for me. Deleting the prefab also brought my texture memory down, so we are all happy about that <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
Eh, i meant BuildVisLeafs, this thing in rad after BuildFaceLights and noting in VIS itself <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
And no, there were no programs running in the background and HLRAD was run with -high
Others wo tried to compile the map with p15 reported the same problem btw... <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo--> <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Sorry about that -- brain's on autopilot at 8 AM my time <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->
It's possible that the extra check to see if the opaque face number hit matches the current face number (which allows opaque faces to light properly) is slowing things down--I certainly wouldn't have expected a factor of four though! How many opaque faces does your map use?
If the answer is '0', then the overhead of an extra parameter on the stack for several function calls is the only possible slowdown I can think of.
I can think of an optimization to the opaque code that should reduce the overall time in the special case that an opaque face is hit (which should balance or exceed the slowdown that opaque faces are apparently causing)... I'll try adding the optimization for p16.
Thanks for the assistance, and of course the fantastic tools Cagey.
Even if a memory operand instead of CPU registers only has to be used can the time go up like that?!? I mean FOUR TIMES, hey that's enormeous. Better run a DIFF on both versions of the code to go sure...
And I'm really sorry for you XP-Cagey, seems like you have a lot of work for the next weeks :/ . I don't even get my own 'does this cube intersect with that polygon' code to work. Don't want to know how complex the mapping tools are!
You might have meant to use a light_spot instead. Perhaps attaching your test map would shed some light on the exact settings you used.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
They are right to left a texlight, a light_spot and a light_environment. I didn't explain the light_environment too well. Its a small sky patch in the ceiling, I then put a brush tube extending down from that. The light_environment is set to point straight down as is the light_spot. The texlight on the right has a small brush tube. The idea of the brush tube is to help restrict the light_environment to shining only on that cube.
I was going to attach the map last post but alas you dont seem to be able to attach more than one thing. meh. I probably could have used image tags or something...|>|-|34R the NS forum n00b. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
Its a very ugly map but it should do the trick...
Even if a memory operand instead of CPU registers only has to be used can the time go up like that?!? I mean FOUR TIMES, hey that's enormeous. Better run a DIFF on both versions of the code to go sure...
And I'm really sorry for you XP-Cagey, seems like you have a lot of work for the next weeks :/ . I don't even get my own 'does this cube intersect with that polygon' code to work. Don't want to know how complex the mapping tools are! <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Well, like I said, if he had 0 opaque faces, that was the only change I could think of.. but he had over 1100 so the other changes to the opaque code are the probable issue <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->.