What does VIS actually do? Created 20 years ago2004-01-17 18:51:53 UTC by Dark Phoenix

Im making quite big maps and by the time im getting to the end of my map the compile times are bordering 2 hours! But once compiled the maps run fine, no frame skips. But it does get frustrating when all your doing each time you compile is tweaking small things like sound and lighting. The thing that takes the most time is HLVIS, the rest takes about 10 minutes whilst that takes up more than an hour and a half.

So what i did was i compiled without VIS running. I thought it did something amazing thats why it took so long, but i ran may map without VIS and it didnt look any different than if if i had run VIS. Obviously when i do my final compile i'll use VIs, but i was just wondering what VIS actually does?

Something to do with reflective light.

It does all the lighting.
No VIS - Fullbright. Doesnt look very good, trust me.

VIS stands for Visability Matrix. It processes all of the rendering and light bounces. It basicly controls what is rendered and how. If you compile somthing without VIS it goes fullbright just like Zl said. The reason that happens is because RAD (the lighting program) relies on VIS to calculate the bounces and renders! So if VIS doesn't run, RAD can't run either, causing it to be fullbright!
In big, complex multiplayer maps, you should put in vis blocks. This means that only certain parts are rendered at once. You have to be very careful where you put these otherwise your map will render very funny (because the vis block will render as nothing making a block of black!). Vis blocks are good for keeping r_speeds down in maps. R_speeds make everything run laggy and chuggy! This is espescially important in multiplayer maps!

Did that explain it? I spent 8 minutes working all of that out!

still want vis? just cordon off ur map so it compiles oly the bit u want to look at

simplest explanation without going into what its used for in RAD -

Stand in a room in halflife thats properly compiled
The rest of the level is not visible around the corner (gl_wireframe 2 shows this)
If it was the map would be unplayably laggy
VIS works out, for every 'room' in the map, what should be VISible

I'm sure theres a guide on here or VERC (gak) for what it does in intricate detail

I dont like vis that much, it only slows down my compile tmie. Plus if there arent any leaks in the level vis will run(obviously) and all the lights that you put as a dark shade will still appear bright. Which is bad for my haunted level. So I put an extremely small leak between the sky walls and sky roof.

Hm. Why not just compile without VIS??

compiling without vis is like a chilli con carne without rice, stupid!

erm, llike brattylord, he doesnt like lights!!

heh

I compile with intentional leaks AND with vis turned on because I am too lazy to move the mouse and click on the run vis button.

But when i dont run VIS, my map isnt fullbright. Its still correctly lighted? RAD runs and says no VIS info, but its still runs and does the lighting for the map. It just makes RAD take a little longer, and i mean a little. More like 2 minutes more. Im just gona not run VIS anymore until the final version. But dont you think thats weird? :

No. Read the log, it will say "no VIS information, direct lighting only". This means light will not bounce at all (along with the normal effects of not VISing) therfore the map will be in stark contrast

fgs never ignore VIS, if you cant compile with fast vis (which usually takes a few seconds for huge maps) then don't compile at all as the end result will be unplayable

One exception: When you're looking for leaks using the shrinking box method.

whats the shrinking box method i had to search for about a half hour for a leak yesterday and was so pissed by the time i found it i had to quit for the night

In the help file for Hammer it shows u what it is and how it works. Basically what happens is that u put a biiiig block in ur level and compile. Use the pointfile now and if theres no leaks then that block must have fixed the leak. Therefore, keep shrinking that block until u pin point the location of the leak. Or and even simpilar solution: don't make leaks in ur maps!! Usually they appear because of using the carve tool. Don't use it there are better ways for example Vertex Manipulation (one gr8 tool). Learn to use it it will save heaps of time.

Um... You don't use the pointfile in the shrinking box method.:confused:

You just create a block that covers the entire area first. Then onto expert compiling where you untick every process after HLBSP. Then compile. Is there a leak still? Yes? Then your block isn't covering the whole level. And make sure you haven't tied this block to an entity.

Shrink the box a little. Recompile. Leak? Then there's a leak within that area that you just uncovered. Recompile and shrink in small parts until you have the entire level fixed.

And I wouldn't think anyone would make leaks in their maps on purpose other than example maps for Leak tutorials.