Discussion in 'Request Area' started by Grubzer, Jun 7, 2017.
I know that vvis source code is available somewhere, but where?
You can use Source SDK to create a base for a mod, which will download source code for the utils, vis included, into Moe's directory. This will be a pretty old version of it I'm pretty sure, I only got Create a Mod to work in 2007 source branch.
More details in 10ish hours
It was updated 4 years ago... Isn't it outdated?
Source itself is outdated.
I'd be surprised if they updated it after that. Vvis is not exactly a piece of software you're going to add hot new features to. As far as I know, only the vrad code is slightly out of date if you compare to csgo/tf2 but that's the latest we have so there ya go.
Well... At least add gpu acceleration, or make it use 100% of my CPU, so instead of compiling for 1 hour on normal mode, it would take much less time to do it
That is a perfect example of a feature modders would have to use this code to add because Valve never will.
if only it was that simple
it does. Or if it's not using all your threads add the -threads command to the expert options
your compile time is because your map is poorly optimised, look into func_detail and func_visclusters. VVIS on a complex map properly done should only take 15 minutes max, maybe more if your map is super open.
My map is 75% func_detailed. Some players even say that it is poorly optimised. But without it compiling would take more than 1 hour.
Interesting fact: I'm using compile pal, and on Full compile Both it takes around 20 minutes to compile it. But on Fast setting it can take up to 35 minutes... Why???
Map with func_detail
Map without func_detail
dude, I don't know how to tell you this but I'm not sure why you bothered to func_detailing everything. That was a waste of time and it doesn't optimize anything. I'm not even sure why you run vvis at all tbh. Having the whole map in a func_viscluster would have saved you trouble.
As for compilepal's "Full" and "Fast", those are just preset names. Compile speed is going to depend on the settings you have in either of these so only you has the answer to this question really.
Yeah...func_detail is only helpful if you use it properly. Overusing it - especially to the point of 75% - is gonna do more harm than good. You need something left to break up visibility and prevent the whole map from rendering at once.
Ideally, you want the basic shape of your map to be made up of large, simple world brushes that separate your map into its different "sections". Put blocks of nodraw under and behind displacements to fill in the empty space (no one will ever see back there, so why let a visleaf occupy that space?). Building walls should also be world brushes with areaportal windows and doors so that clients inside don't render everything outside, and vice versa. The only things you should func_detail are small brushes that won't block visibility anyway - doing so will prevent them from making unnecessary visleaf cuts and drastically reduce your compile time.
To help you optimize visleaf structure, Hammer comes with portal files that let you visualize the leafs in your map. You can load it with Map > Load Portal File after you've run VBSP. In general, you should aim to make your leafs as simple as possible (no dense/messy clusters of blue lines) while also using world brushes to separate leafs that shouldn't see each other.
Lastly, I want to emphasize that func_detail exists to reduce compile time, not to increase performance. The two aren't directly related, either - a 15 second compile could still produce a map that runs at 15 FPS. Your world brush/areaportal/occluder/hint usage is far more important than func_detail for performance optimization.
Using a i5 4660 (if stating compile times this is a very important thing to note as this can identify diffirences in compile times a lot) it took me about 10 minutes of vvis on normal in giza, and that is considering a that a section is rotated and offgrid which can influence the compile time by a lot.
The number of stuff i func_detailed would be between 5 to 10%.
The only time you would have to func_detail something is when the compile time is exceeding an acceptable limit. You might have a small map, but if vvis takes 20 minutes on that, it might still be acceptable. Sure, it can be optimized by checking for high density areas (lots of blue lines when looking at the visleafs in hammer). But it might not need fixing. A 5 minute longer compile time can add 20% extra fps by just having that few extra visleafs that cut visibility around corners. You can manualy solve this to speed it up, but if its acceptable already, just dont bother unless its in/close to RC state.
Stuff you normaly should func detail (many hints are based on your example):
- Thin poles (essentialy anything that simply isnt thick enough to block any vision)
- Sections sticking out of a wall that arent the wall itself (window borders, supports).
- Arches (and make sure there is a solid wall behind the sides)
- Any brushwork in front/behind a window you can look through
Stuff you should not func_detail:
- Regular walls
Anything that is essentialy blocking off a room is worthy for vvis. Keep these things there
Things you should use hints for:
- Sloped bridges (put a hint box around it so it can only create 2 triangle leafs in the slope - one above, 1 under).
- Any odd angled stuff (like a rounded pillar) could use a hint brush arround it to contain the triangle leafs to just that box
Things you need to add brushwork to:
- Displacements (you often want a nodraw brush under/behind the displacement to act as a wall for vvis since displacements act like func_details)
- Sections behind the playing ground can often be suitable for a skybox brush (which goes all the way to the skybox on top) directly behind it. Its not a good idea to keep the skybox a huge box.
What are the dates for next to build programs name when compiling? I see Feb. 17 2017.
@Grubzer you have managed to func_detail too much and simultaneously not enough. Those roofs, assuming they overhang the buildings, ought to be detail (unless they're displacements) and definitely so should the mini roof bits with the windows on them (I know there's a proper architectural term for those). But the large walls that make up the castle should not.
Separate names with a comma.