Compile Problem
ChickenOfWar
Join Date: 2003-04-09 Member: 15352Members
Join Date: 2003-04-09 Member: 15352Members
<div class="IPBDescription">What is it?</div> Im tring to release a Beta version of my map ns_canopy, but I keep getting an Error for HLRAD.exe.
Too many direct light styles on a face(?,?,?)
Repeated over and over again until I exit the program.
I'de like to ask, what qualifies as a direct light? I only have one light_spot entity on the map.
And can anyone help with the problem? I'll uhh give you a cookey <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Too many direct light styles on a face(?,?,?)
Repeated over and over again until I exit the program.
I'de like to ask, what qualifies as a direct light? I only have one light_spot entity on the map.
And can anyone help with the problem? I'll uhh give you a cookey <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Comments
A patch is one of thoose little light blocks on a texture poorly getting smoothed by the renderer.
All light data is stored on thoose patches whose RGB value gets multipy-blended with the texture.
Light on the patches is calculated in "layers" mixed together.
Each KIND of light gets stored in one layer, gets its reflection calculated seperately and then get mixed together for each patch.
Kinds of light differenciate in RED, GREEN, BLUE, BRIGHNESS, and APPEARANCE (static, flickering, toggleable, texturelight/env_light/spot).
Having 3 not flickering white lights with only different brightness values uses 3 differens layers!
Having 3 flickering lights of the same color, same brightness, same texture and same flickering uses one layer.
(Its not the number of lights its the number of DIFFERENT lights that is your problem)
Now each PATCH can just have 8 DIFFERENT LAYERS of static light OR 3 different layers of dynamic light MIXED TOGETHER on it.
If its more you get this error.
Fix this by:
- Changing some dynamic lights into static lights especially on places with many different lights.
- Reducing the different kinds of lights used near this place making more lights the same.
- adding a vis blocker that blocks the light.
- decreasing the number of reflections if you have straight corridors.
- Using less light spots.
This error has popped up before, but doesn't seem tied to overuse of dynamic lights. I'll wait and see if some expert mappers arrive at a solution, or find that it's just a calculation error stemming from complicated light data.
The difference between this error, and the standard one, is that there's quotation marks rather than actual numbers in the error message. Overuse of dynamic lights will result in numbers indicating the faces being affected.
Direct lights are all types of point lights (not too sure if this includes light_enviroment though).
I had this compile error on ns_hydrosity for about a week after I had tweaked some lighting. It ended up fixing itself. From my expirience, this error is like the allocblock of Rad. Very hard to pinpoint
That being said, the lack of solid coordinates makes me think you probably have a vertex manipulated solid with an inside out face, or possible an extraneous vertex on one side, or just something causing it to create an invalid solid or infinite plane that isn't detected during csg.
I dunno, but Ollj's fixes don't really apply here because I know Mouse had a similar problem and none of the conventional methods would fix it.
1. Create a large block which encompasses part of the map
2. Compile
3. If the error goes away, the invalid brush is somewhere within that large block you made
4. If the error did not go away, the invalid brush is in the error you did not block off
5. Repeat 1 by varying the position of the block if the error occured, or shrinking the block if the error went away
Eventually you should be able to narrow it down. This is a similar trick to what some people use for finding leaks.
Too many direct light styles on a face(?,?,?)
Repeated over and over again until I exit the program.
I'de like to ask, what qualifies as a direct light? I only have one light_spot entity on the map.
And can anyone help with the problem? I'll uhh give you a cookey <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I actually did some hunting for the problem when Mouse mentioned it a while back from an IRC conversation, and at that point I reduced the spam without fixing the problem outright... I've since found out more about what's going on--I believe the problem is actually related to the way that the texlight code scans entities for information about their light styles.
The texlight code scans every entity for a "style" key, and assumes that any match of this key must mean light style. Even though there is only a single light_spot on the map, any additional entities that have a style key will potentially contribute light styles to patches.
HLRAD's qrad.cpp:
<!--c1--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>CODE</b> </td></tr><tr><td id='CODE'><!--ec1-->#ifdef ZHLT_TEXLIGHT
//LRC:
if (*(s = ValueForKey(ent, "style")))
{
style = atoi(s);
if (style < 0)
style = -style;
}
else
{
style = 0;
}
//LRC (ends)
#endif<!--c2--></td></tr></table><span class='postcolor'><!--ec2-->
If you look at your map file in a text viewer (much easier to scan than the entity report when you're looking for a key rather than an entity type), you'll probably see key-value pairs where the key is "style" and the value may or may not be an integer. The pair is interpreted to be a light style on any object. It has been my experience when testing that removing these pairs where they are present can fix the error even if the entity isn't supposed to emit light. Doing this will also reduce the amount of lightdata stored in your bsp because the amount of data per patch is directly proportional to the number of light styles on that patch--I personally consider the addition of a lightstyle from a non-light entity lacking any lighting textures or explicit "_light" key to be a problem (especially due to the problems it causes down the line), but I haven't corrected the behavior yet.
I ended up tracing this by using an old map that had the problem, and I corrected it by removing the "style" key from some func_buttons (where "style" was 32 and 33).
My latest publicly released copy of the tools has been changed so that the error message is only displayed the first time the error occurs, allowing HLRAD to finish the compile. In that version, 1.7p8, there is another lighting bug that I accidentally introduced that can be avoided with the command line switch "-oldmath". I successfully found and squashed that lighting bug today, so my next tool release won't require the switch to compile properly.
EDIT: HOLD UP! It happened again. Only I found some conspicuous things in the compile log.
Is it supposed to say "0 opaque faces" after "create patches : X"? And the thing started happening RIGHT as the "Bounce 1 gatherlight" thing started. Maybe I missed something?