Major Problem
rimj0b_r0dent
Join Date: 2003-03-16 Member: 14581Members
Join Date: 2003-03-16 Member: 14581Members
<div class="IPBDescription">(i think...)</div> Today's a good day for mapping and errors too, it seems:
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->entering d:\data\hammer maps\natural selection\ns_ateus.map
CreateBrush:
10%...20%...30%...40%...50%...60%...70%...80%...90%...Error: Entity 59, Brush 10, Side 0: plane with no normal
Error: plane with no normal
Description: The map has a problem which must be fixed
Howto Fix: Check the file ZHLTProblems.html for a detailed explanation of this problem
Error: Entity 59, Brush 10, Side 4: plane with no normal
Error: Entity 59, Brush 10, Side 4: has a coplanar plane at (-3180, -2834, -4), texture YELLOW
Error: Entity 59, Brush 11, Side 1: plane with no normal
Error: Entity 59, Brush 11, Side 5: plane with no normal
Error: Entity 59, Brush 11, Side 5: has a coplanar plane at (-3176, -2844, -15), texture YELLOW
Error: Entity 59, Brush 11: outside world(+/-4096): (-10000,-7047,-7047)-(10000,7095,7095)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10000,-7047,-7047)-(10000,7095,7095)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10000,-7047,-7047)-(10000,7095,7095)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7083)-(10016,7111,7131)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7083)-(10016,7111,7131)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7083)-(10016,7111,7131)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10032,-7079,-7079)-(10032,7127,7127)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10032,-7079,-7079)-(10032,7127,7127)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10032,-7079,-7079)-(10032,7127,7127)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7065)-(10016,7111,7113)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7065)-(10016,7111,7113)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7065)-(10016,7111,7113)
(4.22 seconds)
----- END hlcsg ----- <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's bitching about a ship I made out of brushes, made it a func_rotating, gave it "yellow" texture, made it transparent, tilted it to a crazy angle, made it an additive and FX of 50 (so it's transparent). One thing that I am sure of is that my little ship model is definetly NOT outside my map. The rest I don't really understand.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->entering d:\data\hammer maps\natural selection\ns_ateus.map
CreateBrush:
10%...20%...30%...40%...50%...60%...70%...80%...90%...Error: Entity 59, Brush 10, Side 0: plane with no normal
Error: plane with no normal
Description: The map has a problem which must be fixed
Howto Fix: Check the file ZHLTProblems.html for a detailed explanation of this problem
Error: Entity 59, Brush 10, Side 4: plane with no normal
Error: Entity 59, Brush 10, Side 4: has a coplanar plane at (-3180, -2834, -4), texture YELLOW
Error: Entity 59, Brush 11, Side 1: plane with no normal
Error: Entity 59, Brush 11, Side 5: plane with no normal
Error: Entity 59, Brush 11, Side 5: has a coplanar plane at (-3176, -2844, -15), texture YELLOW
Error: Entity 59, Brush 11: outside world(+/-4096): (-10000,-7047,-7047)-(10000,7095,7095)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10000,-7047,-7047)-(10000,7095,7095)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10000,-7047,-7047)-(10000,7095,7095)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7083)-(10016,7111,7131)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7083)-(10016,7111,7131)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7083)-(10016,7111,7131)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10032,-7079,-7079)-(10032,7127,7127)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10032,-7079,-7079)-(10032,7127,7127)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10032,-7079,-7079)-(10032,7127,7127)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7065)-(10016,7111,7113)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7065)-(10016,7111,7113)
Error: Entity 59, Brush 11: outside world(+/-4096): (-10016,-7063,-7065)-(10016,7111,7113)
(4.22 seconds)
----- END hlcsg ----- <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
It's bitching about a ship I made out of brushes, made it a func_rotating, gave it "yellow" texture, made it transparent, tilted it to a crazy angle, made it an additive and FX of 50 (so it's transparent). One thing that I am sure of is that my little ship model is definetly NOT outside my map. The rest I don't really understand.
Comments
And ignore all "unused keyvalues" messages thats a hoax error.</b>
its just crappy brushwork caused by vertex manipulation that causes all theese errors:
HL does not like convex brushes , convex and concarfe faces.
(this gets fixed automatically by moving vertexes around randomly wich causes leaks and brush outside world)
And it does not like brushes with 2 of its polygons (triangles...) in the same "plane".
(this causes the compiler to abort)
"Plane with no normal" means that there is one plane/face of a brush that oes not know whats "inside..." and whats "outside of its brush" caused by MUCH vertex manipulation.
(abort, too)
<b>Press alt+p in VHE to find all brushes with that errors.
And ignore all "unused keyvalues" messages thats a hoax error.</b>
plane with no normal <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
i think it says outside world maby because you have a leak in that room <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
thats all i can say
Rim, the compiler is at least nice enough to point out the brushes with the problem. Use the map --> go to brush number and then enter the entity and brush numbers as listed in the compile log. When you're there, look for two faces that lie on the same plane or any extra vertices that don't belong. Also make sure that no solids bend back into themselves, creating concave brushes. Also, note that the coordinates on entity 59, brush 11 are all outside the +/- 4096 range that is the valid grid space in HL. This entire brush pretty much needs to be destroyed. Brush 10 you can likely salvage. It's also possible that the invalidity of brush 11 is causing things to jump around so much that it shoots some of its vertices out in a seemingly neverending solid, and if you can find the problem you may be able to fix it without actually deleting or re-building the brush.
A good way to double-check to see if you've missed anything would be moving your camera very carefully around the solid in the 3d view. Each face should appear flat and non-distorted. If you see any creases where there's not actually an edge, you've got a problem. The easiest way to fix that sort of error (if it's a convex crease) would be to select the vertex at each end and hit ctrl+f to create an edge between the two vertices. That way the brush can actually have the shape it's trying to get anyway. This is about the easiest type of invalid solid error to fix. Others will require brush splitting or some really picky VM work to repair.
Yeah, rotating things will destroy even the cleanest brushwork with floating point errors, either deforming the geometry or making it completely invalid in the process.
A good way around this, if it's a static rotation, is to make the brush normally flat against the grid, then tie it to a func_door_rotating entity. Trigger it with a trigger_auto or set it to start open, and set the rotation for whatever you need. Very useful for angled details at an angle other than 45 degrees, which isn't too bad to manually fix.
(abort, too)<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
For the record, a "Plane with no normal" error occurs when the three points specified for the plane in the map file are colinear. When that's the case, the normal is logically indeterminate... the program attempts to take the cross product of two edges and gets a vector of length zero, causing it to throw the error.
Also for the record, if a brush has a bad plane definition, that plane is skipped when calculating face boundaries in CSG, which is the probable cause of the "outside world" error you had for brush 11--if you remove one plane from a brush and the remaining planes don't form the boundaries of an enclosed polyhedron, the resulting brush created by CSG is bounded by arbitrary limits set by program.
That arbitrary limit for brush bounds was set just outside the legal world bounds so that logically unbounded shapes will be reported by the program. In the case of brush 10, the remaining plane intersections still define a complete solid even without the missing plane. I can illustrate this if somebody cares--I'm not sure if I'm using mathematically accurate terms, but what I said does describe the effect.
I don't have any source for the rmf-->map exporter (I'd love to see that made available like the map->dxf translator source was made available), but I'd conjecture that the colinear plane definitions in the exported file are due to colinear points in the rmf brush face used for plane generation.
i think more by visual geometry than math, here is how i think this problem happened:
he made the brushes, vertexes on the grid. then he rotated it - and some vertexes move OFF the grid. that is ok for the .rmf, it can go decimal. but stupid WC/HAmmer then exports to .map format, and for some dumb reason always rounds to the nearest whole number for the vertexes.
(doesn't need to, Quark allows its .map to go decimal and the levels compile fine....)
so as he exports to .map, the editor warps his rotated brushes into some weird illegal shape. then you get things as cagey explained - a line of vertexes in a row or on top of each other for a "no normal" error, bad planes deleted resulting in "outside world errors", "<a href='http://www.slackiller.com/tommy14/errors.htm#coplane' target='_blank'>coplanar errors</a>" where two faces are parallel, and so on.
if i am wrong cagey, please clarify.
i think more by visual geometry than math, here is how i think this problem happened:
he made the brushes, vertexes on the grid. then he rotated it - and some vertexes move OFF the grid. that is ok for the .rmf, it can go decimal. but stupid WC/HAmmer then exports to .map format, and for some dumb reason always rounds to the nearest whole number for the vertexes.
(doesn't need to, Quark allows its .map to go decimal and the levels compile fine....)
so as he exports to .map, the editor warps his rotated brushes into some weird illegal shape. then you get things as cagey explained - a line of vertexes in a row or on top of each other for a "no normal" error, bad planes deleted resulting in "outside world errors", "<a href='http://www.slackiller.com/tommy14/errors.htm#coplane' target='_blank'>coplanar errors</a>" where two faces are parallel, and so on.
if i am wrong cagey, please clarify.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Yep, there is some warping of brushes on export -- what you said is right. The only thing I haven't confirmed is WC's method for generating integer coordinates on export--rounding would be the easiest way to do it, but you could also search for an integer valued best fit of the plane equation to find integers that lie as close as possible to the original plane, sacrificing time for accuracy.
If you're going to document what I said above, I should note that skipping invalid planes is only one cause of "outside world" errors... two others are<ul><li>explicitly creating items outside the +/-4096 bounds of allowed mapping space (actually "outside world")<li>creating items within (largest bounding box dimensions)/2 of +/-4096... when brushes are expanded for the clipping hull, they end up partially outside the world (although this could be modified, since simple geometry can demonstrate that any face that gets expanded across a world boundary must be on the exterior and should be culled unless the map leaks).</ul>If the brush being reported as outside world isn't near the edge of the map, however, a skipped invalid plane is the best bet <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
One trick I use to see how well WC is dealing with complex geometry is exporting to .map format in the File Menu and then reloading the .map in WC... if it says illegal brushes were removed when loading, then you know it's exporting bogus information. Quark can audit WC exported .map files, and sometimes catches vertex manipulation problems WC hasn't reported while in .rmf format (I have a sample brush illustrating an uncaught .rmf brush problem if anybody's interested).
Just thought I'd add a little teaser here.. I'm working on a command line rmf->map converter that preserves floating point values and does lots of other geometry correction. The basic conversion works already, I'm just finishing all the geometry correction before I release.. should be done in a week or two.
<b>WHAT! Jedediah, that would be great! whoohoo! </b> <img src='http://www.gamers-forums.com/smilies/otn/party/partysmiley.gif' border='0' alt='user posted image'>
the texture mapping to aviod overlays is great for NS, but this, this .rmf->.map translator could be used by ALL mod mappers to aviod problems - and there have been a LOT of them. <img src='http://www.rocketsky.net/~mysmilies/otn/party/partytime.gif' border='0' alt='user posted image'>
<i>how'd ya get the .rmf coding specs? a lot of folks have wanted them and couldn't find them.</i>
oh, yeah, getting back to Cagey - your other point have been mentioned in zoners error log, i was just going to append your comments to that log....
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Just a little engineering of the reverse kind. I'll publish the RMF format along with the tool when it's done.
1. Decals:
I don't really know how to resize/move/mess around with decals. I know how to place them. If someone could post me a link to a good decal tutorial that would be great.
2. Selective Compiling:
Say I want to compile the new room I worked on, but not the whole level. If I were to draw a huge brush through the other parts of the level would that work and speed up my compilation process? I really need to do this since I have started with the bad habit of completeting individual rooms before having a whole layout of the map.
3. The join team sign in the ready room:
Is that a decal or a func_illusionary brush? I made it func_illusioinary, so that adds to my w_poly, right?
That's all I can think of right now, gotta go library people kicking me off... <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
1. Decals:
I don't really know how to resize/move/mess around with decals. I know how to place them. If someone could post me a link to a good decal tutorial that would be great.
2. Selective Compiling:
Say I want to compile the new room I worked on, but not the whole level. If I were to draw a huge brush through the other parts of the level would that work and speed up my compilation process? I really need to do this since I have started with the bad habit of completeting individual rooms before having a whole layout of the map.
3. The join team sign in the ready room:
Is that a decal or a func_illusionary brush? I made it func_illusioinary, so that adds to my w_poly, right?
That's all I can think of right now, gotta go library people kicking me off... <!--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><span class='postcolor'><!--QuoteEEnd-->
1.
Decals in the map architecture are evil
are you sure you dont mean Sprites?.
sprite alignment requires a little hex edit:
<a href='http://www.cryotank.net/maps/tutorials/sprites1.html' target='_blank'>http://www.cryotank.net/maps/tutorials/sprites1.html</a>
2.
The compiler always creates one Hull around each point entity (if its not already in the same hull of another).
Hulls are the visible places you can walk in. (one hull for RR, one for the map)
To compile just parts of your map place big blocks over parts that you dont want to get compiled!
Or place walls through your map and one small solid block over each point entity that should not create a hull.
Make sure there is a info_player start in the part of your map that you want to get renderes.
This does not increase CSG compie speed but all other steps get MUCH faster.
Compile time of VIS and RAD grows exponential to hull-complexity/volume/surface.
3.
its a func_illusionary brush. rendermode additive, ammount 255.
the invisible faces of the brush are just strechted black parts of the texture (worse w-poly) or covered with the "null" texture (better).
Each brush face adds w-poly. Each object polygon adds e-poly.
1. Decals:
I don't really know how to resize/move/mess around with decals. I know how to place them. If someone could post me a link to a good decal tutorial that would be great.
2. Selective Compiling:
Say I want to compile the new room I worked on, but not the whole level. If I were to draw a huge brush through the other parts of the level would that work and speed up my compilation process? I really need to do this since I have started with the bad habit of completeting individual rooms before having a whole layout of the map.
3. The join team sign in the ready room:
Is that a decal or a func_illusionary brush? I made it func_illusioinary, so that adds to my w_poly, right?
That's all I can think of right now, gotta go library people kicking me off... <!--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><span class='postcolor'> <!--QuoteEEnd-->
1. Decal scales and appearances mimic the scale (and I think rendermode?) of the face the decal is placed on... if your face texture is streched to double size, the decal will be, too.
2. If you're using WC/Hammer, search the help for 'cordon'. This is a tool designed to allow you to use only part of your map at a time for compilers, and it is easier to work with IMO than blocking sections off with brushes. Hammer will only export items inside the cordoned area to the .map file, and then bound it with black axial planes. Pretty much what you're talking about doing, but it's automatic, and you don't end up with leak errors from items stuck inside brushes.
3. If you null texture every face of the func_illusionary except the one containing the sign, it should only contribute a single w-poly per sign.
On another note: Jeb - if you do release the format and Valve doesn't mind people incorporating .rmf support into tools, I'll be all over that spec one you release it <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. I don't want to use the format without their permission, so I'll have to see how they react.
Because traditional RR designs aren't connected to the rest of the map, the vis algorithm tells the program to hide the RR from the map and vice versa -- each node in the worldspawn hull is given a simple check based on current character position to see if it should be drawn. Even though they're the same hull, the area (RR or main map) that the player is not standing in will make zero contribution to w-poly counts. This is actually more effective than blocking with a func_wall could be, since func_walls aren't used for vis calculations by the current tools.
Entity hulls are always drawn in their entirety because vis matrices aren't calculated for anything but the worldspawn. The engine uses the main hull's vis information at the location of the entity instead of looking at the entity's nodes.
1. Texture memory limit:
My texture memory is already at a little less than 2 megs. I don't know if I'm using the correct terms but I am refering to the 4 MB texture limit. Is it the amount of different textures used that adds to that number?
2. Jetpacker-friendly hives:
How exactly can I make a large room difficult to attack using a jetpack?
1. Texture memory limit:
My texture memory is already at a little less than 2 megs. I don't know if I'm using the correct terms but I am refering to the 4 MB texture limit. Is it the amount of different textures used that adds to that number?
2. Jetpacker-friendly hives:
How exactly can I make a large room difficult to attack using a jetpack? <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
1. The amount of texture memory you use is proportional to what can be thought of as the "square footage" of unique textures your level uses. The engine reads each texture from disk and stores it in memory for reference when drawing faces. Only a single copy of each texture is needed for this reference, so if you use a texture many times it only counts once toward the cap. Because the actual image is being stored, larger images take more memory (a 256x256 image will take up at least as much memory as 4 128x128 images).
2. I think this is going to be largely a matter of opinion. It really depends on how skilled the jp player is... if they're not very good and spend most of their time along the ceiling, adding obstructions there could trip them up. If a ceiling is low enough, it becomes easier to hit a jp by jumping. If you don't place any high ledges, jp players won't be able to touch down and recharge without being vulnerable.
None of that is going to stop a good jp player, though, who can hover or fly at a consistant height without any problems. The believe the jp is going to be nerfed by becoming more expensive in 1.1, and I think I remember flay saying it would no longer be able to be used 100% of the time as well (either slower recharge or faster drain when in use).
1. After I compiled my map I joined the marine team, just to test out comm mode. I didn't put a info_mapinfo and the comm chair worked. I got in and viewheight was at 0. Then I put a info_mapinfo entity and recompiled and it wouldn't let me join any team. It would just go into "ghost" (specatator) mode. This happened both when I had viewheight set to 200 and when I left everything as defaults.
2. What is one way to see how textures split faces in the game? I've seen a screenshot somewhere on a website a while ago and I could really use that tool (I think it was a tool). My r_speeds (w_poly) are going over 700 and maybe I can fix a few faces if I knew how to see the splits.
C:\Half-Life\hl.exe -console -game ns (your favourite parameters here!) +map mapname -dev
In-game type in console: gl_wireframe 1 or 2
1: It draws the lines of the faces YOU see
2: It draws the lines of the faces HL renders (this is the poly count on r_speeds)
Because traditional RR designs aren't connected to the rest of the map, the vis algorithm tells the program to hide the RR from the map and vice versa -- each node in the worldspawn hull is given a simple check based on current character position to see if it should be drawn. Even though they're the same hull, the area (RR or main map) that the player is not standing in will make zero contribution to w-poly counts. This is actually more effective than blocking with a func_wall could be, since func_walls aren't used for vis calculations by the current tools.
Entity hulls are always drawn in their entirety because vis matrices aren't calculated for anything but the worldspawn. The engine uses the main hull's vis information at the location of the entity instead of looking at the entity's nodes. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
I was really asking about the fact of having more then 1 hull.. does it impact the map's performance?
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->the vis algorithm tells the program to hide the RR from the map and vice versa <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Do you mean in the commander view? Thats normal cuz the view height is usually LOWER then the RR itself <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
Not at all. In fact, if the hulls are sealed from each other this will assure that nothing in one hull is drawn while the viewer is in the other hull.
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--><!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->the vis algorithm tells the program to hide the RR from the map and vice versa <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Do you mean in the commander view? Thats normal cuz the view height is usually LOWER then the RR itself <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
If the RR is above the commander view height then it should never be drawn for the commander.
I seem to remember that, in conjonction with the normal VIS stuff, your FOV has a "cone" in front of you that extends for like 128 units or something. And that thing goes through walls.
So, if you have a big room, and a wall between the two seperating it into 2 distinct hulls, if you go up to the wall, your cone can see into the other hull.
Thats one of the things that cause a few weird error messages in your console when going around your map.
But i recall this from long ago and im not 100% sure
I seem to remember that, in conjonction with the normal VIS stuff, your FOV has a "cone" in front of you that extends for like 128 units or something. And that thing goes through walls.
So, if you have a big room, and a wall between the two seperating it into 2 distinct hulls, if you go up to the wall, your cone can see into the other hull.<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
Technically, the RR is part of the same worldspawn hull as the main map area, they're just disjoint sections (2 distinct sections, not 2 distinct hulls). If you were creating the RR out of a func_wall entity, it would be a second distinct hull, and possibly be visible through a wall.
The initial calculation of what can and can't be drawn has more to do with what's visible from openings between nodes (the portal list created by bsp, not to be confused with a portal based rendering engine). This check can only be done when the player is inside a node on the map, so it doesn't apply to the commander view.
After the initial list has been set using the vis algorithm, the game checks an approximation of player's FOV to further cull the list of polygons to draw (the cone doesn't have a distance limit, which is one reason why a map that hasn't been VIS'd has such high r_speeds). As you said, this check works in conjunction with the VIS algorithm. It never adds items back into the potentially visible set of worldspawn nodes--it only refines what VIS gives it.
Given the example of a wall with items drawn behind it, one of three things is happening:
1) There is a doorway or other opening in the wall that allows the player to see past it from one point in the node, so items behind the wall are drawn everywhere in the node, allowing you to see things through it (this is where hint brushes can help by defining node boundaries).
2) The wall isn't part of the worldspawn (e.g., a func_wall entity) and is ignored for VIS calculations. When this is the case, the field of view is the only method the game will use to determine visibility.
3) The items visible through the wall aren't part of the worldspawn, and aren't embedded into the VIS table. When this happens, the game uses an approximation of the entities' positions to determine visibility, and it is possible to see them through a wall if the bounding box overlaps the wall or another section visible from behind the wall (e.g., around a corner visible from the end of the wall). Entities are drawn as an all-or-nothing addition.
Adding a switchback fixes problem #1. Changing the wall or the items behind it from an entity to a world brush fixes problems #2 and #3 at the expense of extra chopping of the world by BSP.
None of the three cases above applies to a RR created out of worldspawn brushes. If you're still worried, you can always experiment. Try creating a sealed room (RR or otherwise) and run gl_wireframe 2 to check if it is being drawn by the engine... if the room was made with worldspawn brushes and you're standing inside the worldspawn hull, I'm confident it won't be.
Before i came to this forum, i though i knew a lot about HL mapping.. but with your insane knowledge of the compiling tools.. you're blowing everyone out of the water!
Layman's terrrrrrrmmm maaaan! LAAAYMAAAAANN! <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
Before i came to this forum, i though i knew a lot about HL mapping.. but with your insane knowledge of the compiling tools.. you're blowing everyone out of the water!
Layman's terrrrrrrmmm maaaan! LAAAYMAAAAANN! <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo--><!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
doH! <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
I'll try to think of a good way to explain it without getting to technical and post it later today <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->. In the meantime, I've dug up the reposting of Michael Abrash's "Ramblings in Realtime" articles on the Quake engine, where he talks about how Quake engine games (including Half-Life) determine what is visible. Unfortunately, these articles do use some of the jargon I used above. <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
<a href='http://www.bluesnews.com/abrash/contents.shtml' target='_blank'>http://www.bluesnews.com/abrash/contents.shtml</a>