Talk:Level Overviews

From Valve Developer Community
Jump to: navigation, search

Clamping Problems

I have made an overview for a map. I used vtex to make it into a vtf since VTFEdit has clamping issues and imported my overview weird with extra black lines. I used this command line in a bat for vtex:

cd C:\Program Files (x86)\Steam\steamapps\markboydude\sourcesdk_content\cstrike\materialsrc\overlay

"%sourcesdk%\bin\orangebox\bin\vtex" 007_basement_egyptian.tga 007_basement_egyptian_radar.tga

pause

It worked fine, but I had the same clamping issue in-game with the smudges at the edges. It also didn't zoom in even if I set the zoom to 50, it did not zoom. This is probably because it clamped bad. --Markboydude 11:06, 11 July 2011 (PDT)


Have been utilising this in my mod- but have run into a problem. It's worked fine for the first few maps, but the latest map I'm working on is so large that I have to set the cl_leveloverview scale to 11 - which is so far out most of the map stops being drawn, and is replaced with a solid bright green. I've tried setting cl_maxrenderable_dist to something rediculously high such as 20000 or even higher, but it makes no difference. Has anyone else caome across this problem and found a work around?

screenshot

I ran into vis problems b4...some faces didn't render because they were considered to be not seen from the player's view -ts2do

ah... so you're saying that running a fast vis (the map is still under development) can be the cause of this?

Try the full vis compiling and you'll know it ;) --King2500 09:58, 6 Sep 2005 (PDT)

well... 3 days later and vis is still running. i may need to do a few optimizations here :)

3 days??? omg! Maybe try the fast vis! *rofl* --King2500 07:00, 9 Sep 2005 (PDT)

yeah fast vis is what i was using in dev - takes about 10 minutes, but was kinda the cause if this whole thread. vis is still running btw ;)

If vis is taking 3 days, you ain't optimised. At max it should take minutes for a well optimised map.

well optimisation aside (something i need to take up with my mappers) a full VIS didnt fix the problem. I managed to bodge the image together in photoshop this time around, but it'd be nice to find a solution.

Heres your solution. r_novis 1 in the console, it turns vis info off. - Jcw87

Zoom Problem?

I dont know what the problem here is. You can tell from the screenshot that the overview is tiled across it. Maybe because it is a small map? I dont know. Any suggestions? (This is not my map, I just thought I might try it out to get the feel)

screenshot

- I think the solution to this is to add the parameters "clamps" "1" and "clampt" "1" to the .txt file accompanying your source TGA. This will stop the image from tiling, as it will extend the border-pixels to infinity (so make sure your border pixels are all the same colour to prevent some ugly streaking). This should probably be mentioned in the article itself Merkaba48


i am using a widescreen monitor and i cant get to any resolution that is a power of 2. and if i adjust the image afterwards then my X and Y axis are off.

Background color problem

The overview background is green instead of black, and whats worse it that is 'leaks' the green into the actual image resulting in ugly overviews. example --Bluestrike 08:45, 20 Feb 2007 (PST)

I've had just the opposite problem. I had it black and needed it green which is normal. Turns out I had a prop_physics_multiplayer which was causing it to stay black. --Markboydude 11:23, 11 July 2011 (PDT)

Alternate Screenshot Method

Instead of the method the article uses to get the overhead screenshot of the level, I took screenshots directly from the Hammer editor x/y viewport. This allowed me to use an image editor with layer support to create different image layers for the different Z planes of my level, as well as add text and a "real paper" background effect. Even when following the article to the letter, I've found getting the origin and scale correct at the end required a trial and error process. When using Hammer screenshots, you still have the trial and error for the scale, but you can positively locate the origin on the first try. --Fishrokk 18:34, 1 November 2010 (UTC)