Losing Sight Created 21 years ago2003-04-30 03:33:19 UTC by Skeeve

Have a slight problem with the map I have created. Things in the distance go black in several places, including the sky.

There are a couple of places in the map that there is no obstruction of sight from one end of the world to another. Map is a battleship, so hard to just throw up a wall : )

sky distances
4997 x 1919 x 1204

Have tried playing with Max Viewable Distance in the worldspawn, but does not have any affect. Have taken it up to 64000.

Any suggestions?

Max viewable distance is defaulted to 4096 units. I read a tutorial recently that explained all this, but hey, I wasn't really paying attentionI think it might have been through the Collective forums, so what I am about to say might be wrong......
There is a Maximum, you can tweak the distance but I think 64000 is above the true max. I have read that 7094.48 is the absolute figure.
So what to do about it?
I think that your best solution is to search for a tweak, or reduce the size of the map.

If you have a large amount of brushes in your map it can cause the problem you are seeing. The HL engine starts to drop brush faces when there are too many to draw. As an experiment, make a copy of your map and take out your battleship. Then compile it. If the black patches don't appear in the test map, then your ship has too many faces. You can try making your ship (or parts of it)into a func_wall which should cut down on the number of faces. Also, when you compile are you doing a full vis? If nothing gets rid of the patches, it's possible the map is just too big. The HLrad section of the compile log displays the number of faces and the number of patches. Let me know what your counts are for those.

Thanks,

Was using a custom sky, which once I removed there is a lot less problems up top. Now just need to make a cargo bay area smaller and fix a few leaks. Map is wa too large for anything other than LAN play. A little over 13 hours for a full compile.

Thought about scrapping the map alltogether, but my son and nephew threw a fit when I mentioned that. Map is ugly, but there is definately room to battle.

I will definately keep these things in mind for my second map.

As far as using func_wall, I thought that was not a good idea. I read an article saying that using that method will speed up compile times, but slow down the gaming engine. If I remember correctly, the article said this is because entities are only rendered when the entity is in a players veiw.

Is this accurate, or not?

Thanks again for the suggestions, I am very happy that I happend upon this group.

13 hours is a long compile.... I normally give up after 6.
If you want, I am happy to have a look at it. I had some success with VooDooPig's recently. Just zip the .rmf and .bsp and e-mail it to me.
On the func_wall debate, Yeah, there are two theories. SlayerA is right in that by making some of your brushes into func-walls, you will reduce the render split caused by that brush when it touches another brush. An entity brush placed on a normal brush tricks the engine into rendering the original (normal) brush as one rather than spliting it into two where a normal brush would join. However.... an entity brush that has a texture applied still has to be rendered, and unfortunatley does not block VIS. So the savings are minimal.
Compile times are not a huge worry (normally:-), wpoly count produced by the amount of textured brushes the engine is trying to render are, and these can only be truely shown after a full compile.
The long compiling times are normally caused by a large lightmap or complex brushes. A single log wall can take over an hour to compile by itself.
I am not sure that the engine renders entities as the player approaches or in the players view, I have never encounted any difference in Normal brushes vs entity brushes and the engine sees a lot more than the player does and compensates by trying to render things it thinks the player will see. In my experience the engine treats them the same. As for entity brush effect on compiling times, I doubt that they would speed it up, unless used to build the map in a better way, nor would they slow game play down.
If you want a better understanding of all this check out FireBinders Test Chamber at:
http://home.att.net/~firebinder/halflife/TestC_01.htm
It is a working example of true results on r_speeds.

Thank you for your input and the link to the Test Chamber. The test chamber is a big help concerning optimizing maps. Since this is my first map, its development is entirely educational. Although; my children seem to like the map.

With compiling, I was using Hammer's run command (F9) to compile and run the map. Today, I did my first attempt at a batch compile and found it much faster. More information is also given when compiling through a batch file (leak info and such).

Thanks again, with the help of this group I have been able ti fix 90% of the maps problems.