visleaf help

Discussion in 'Mapping Questions & Discussion' started by 3DRyan, May 20, 2009.

  1. 3DRyan

    3DRyan L2: Junior Member

    Messages:
    57
    Positive Ratings:
    6
    Hey all,

    Okay, so I've decided to make a go at releasing a gameplay prototype of my ctf level. The portalling part of vvis takes about 2 hours to do, which is ridiculous for how much i've optimized the level. I've func. detailed everything that can, put in some area portals, while making sure my world geometry is clean, but haven't tried hints yet. As you can see from the pics, the portal file shows a crap ton of visleafs, and i don't understand how they have formed in this way. I'll also include the vmf, if anyone is kind enough to look at it that way. I know that the outside area has alot of visibility, which i'm sure i'll be told, but that doesn't explain why i'm getting so many visleaf cuts in the interior, which is what i'm having the most trouble understanding.

    Thanks in advance!
     
    Last edited: May 26, 2009
  2. Kronixx

    Kronixx L5: Dapper Member

    Messages:
    205
    Positive Ratings:
    38
    i'm not expert at optimization as i've yet to even touch this process of mapping myself but from what little i DO know, i see a couple brushes in that area that seems to like not line up quite right creating faces that really don't belong, or certainly DO NOT belong. Um, the 2 examples i found without very close inspection.

    1) that ramp has a very tiny face on the top of the ramp before it switches to the next very large brush for the floor. You can combine the vertexes and eliminate that useless face. It's very small and won't do any good leaving it there.

    2) Looking at the ramp, go through the metal door on the left where your resupply sign is. Go down the hall until it starts to ramp up ever so slightly. You have 2 long brushes connected with a very small brush. Problem is, the tiny little connecting brush doesn't line up. Creating a little tiny ridge in the brushes. Those brushes down this hallway could be causing a sort of cascading visleaf thing that is going through that room. That's maybe why you have those random boxes out infront of the ramp, because it's connecting the faces of the ramp and that geometry with the visleafs created by that weird ramp thing you got going on through that resupply door.

    Keep in mind i've never optimized a map before so i could be blowing chunks of nonsense that isn't remotely right. BUT, from my inexperienced eye they may be some things to consider looking into to see if it knocks out even a couple of those lines.

    In short, check your brush work to find small useless faces, and vertex's that don't line up. As every single one of those tiny useless faces will get counted when calculating visleafs.

    I hope this points you in the right direction even if it doesn't directly help your problem...best i can offer :(
     
    • Thanks Thanks x 1
  3. BrokenTripod

    BrokenTripod L5: Dapper Member

    Messages:
    248
    Positive Ratings:
    65
    You should make that small ramp a func_detail, there's no way that's going to block anyone's view of anything.

    Another thing is that there's still a lot of nodraw textures on walls and different places of the map...not sure if that's a problem for vvis. Also, I THINK you're using area portals wrong? I'm not 100% sure though.

    Also, on this version, I don't actually see any hints anywhere.
     
    • Thanks Thanks x 1
  4. lustygoat

    lustygoat L2: Junior Member

    Messages:
    66
    Positive Ratings:
    23
    Looking at the map there's an enormous amount of stuff that should be func_detail... sloped building roofs, curved walls outside your intel room, etc. There's a huge open space in the middle with sloped brushes all over the place. You should be able to func_detail all this stuff and make the map compile very quickly without any area portals.

    The plain world geometry brushes in your map should be as simple and few as possible... you can run around in Valve maps and start turning things off in order to see for yourself. Open a Valve map and do r_drawfuncdetail 0, r_drawbrushmodels 0, r_drawdisp 0, and r_drawstaticprops 0.
     
    • Thanks Thanks x 1
  5. Sgt Frag

    Sgt Frag L14: Epic Member

    Messages:
    1,443
    Positive Ratings:
    356
    louiekidd might not be an expert but he is right. any little faces that don't line up are gonna cause splits.

    Top of the ramp is a prime example. But even if you func_detail that the cube behind it doesn't line up to the wall next to it, so there's another split.

    All this basic geometry should be done on a fairly large scale. At least grid 8 if not 16.
    16 is nice beacuse it'll give a good wall thickness to block shadows and fit doorways. And the walls will snap nice and easy because they take up a full cube on the grid (if you use grid 8 they'll take 2 units of the grid -easier to mess up and make them one or 3 units, also easier to get off the main grid lines).

    Another thing I notice in that pic.
    In front of the ramp there is a vis-leaf that splits all the way across the room. No doubt that's on a red grid line which automatically splits vis. If you can put walls on those lines, but don't go too far out of the way to do so. In that case I'd leave it as is. That would be a pretty large change to the area to move those walls that far.

    The far back door has the same issue. The wall the door is in is a few units behind the wall above it, so another small sliver you can kill there.

    And all the way in the back past the ramp there are little slivers of walls that stick out. Flush that all up.
     
    • Thanks Thanks x 1
  6. 3DRyan

    3DRyan L2: Junior Member

    Messages:
    57
    Positive Ratings:
    6
    Wow, i guess i need to simplify even more than I originally thought....

    Everyone's answers point to the same thing, so that sounds good and easy enough. I'll let you guys know how it turns out.

    Kudos to all of you and thanks again. :)
     
  7. Kronixx

    Kronixx L5: Dapper Member

    Messages:
    205
    Positive Ratings:
    38
    anytime, good luck
     
  8. 3DRyan

    3DRyan L2: Junior Member

    Messages:
    57
    Positive Ratings:
    6
    Update! Okay, so I went through and basically made all of the world geometry nothing but boxes, so it should be close to the best i can simplify it to. If someone wants to take a look at the file and give me some more feedback, that would be awesome. I put an updated comparison pic and the new vmf at the beginning of this post. It looks a million times better than before, though it doesn't look as perfect as i had hoped. Oh well.

    A few questions just out of curiosity:

    1. How badly do func. details affect the compile and visleafs if they touch world geometry? I know you will get an error if you get too many of these "t junctions", but does it affect gameplay, or how the visleafs get made?

    2. If func. details intersect one another, does it have any bad effect?

    Thanks to everyone's help so far, if someone could lend me some advice on all of this, it would be greatly appreciated. :)
     
  9. n30n

    n30n L4: Comfortable Member

    Messages:
    154
    Positive Ratings:
    13
    I dunno whats the policy here bump vs new topic so here goes. I have same issue. My map is very open and it adds extremely quickly. It appears that theres extra leaf on every floor outside even if walls are flat. Please help it can be only worse :/ Vmf and ss in attachment.
     
  10. Sgt Frag

    Sgt Frag L14: Epic Member

    Messages:
    1,443
    Positive Ratings:
    356
    Well, it would deffinately help if you hid everything except terrain brushes (func_details, objects, etc...) when you take that screeny. All that stuff makes it hard to see the base geometry and that's what you're asking for help with.

    One issue you are going to have though is simply the fact you have such a large open area there. Players can see alot and a long ways and add 10+ players fighting with high poly counts and particles and it's gonna kill framerate.

    Is that a quick compile? Or a full compile. Full compiles will be cleaner so you really need to do that to get an idea of what issues you REALLY have.
    Just turn off lighting and it won't take long.
     
  11. Terr

    aa Terr Cranky Coder

    Messages:
    1,591
    Positive Ratings:
    405
    For everyone with maps that have huge open areas:

    If the problem is the speed VVIS itself, and not the speed while actually playing, then I think what you want is the brush entity func_viscluster.

    n30n: Given your map, make special note the above/below water prohibition on the page.
     
    Last edited: Aug 7, 2009
  12. III_Demon

    III_Demon L2: Junior Member

    Messages:
    57
    Positive Ratings:
    29
    note: visclusters effectively merge visleaves. you will find statements out there to the contrary, and while technically, yes, you cannot merge visleaves, a func_viscluster effectively does. visclusters can only make in-game performance worse, not better. they are only for cutting down vvis time.

    for maps with lots of open sky, if used right, they are fantastic. generally you want to stick them in big areas of sky or unplayable space. valve uses them in places like the unplayable space in the background of badwater, where its beyond fences, and there are vis leaf cuts just because of the back sides of buildings, and the 1024 split.
     
  13. Terr

    aa Terr Cranky Coder

    Messages:
    1,591
    Positive Ratings:
    405
    Hrm. I'll see if I can verify that on a test map later.
     
  14. Sgt Frag

    Sgt Frag L14: Epic Member

    Messages:
    1,443
    Positive Ratings:
    356
    I used them(func_visclusters) in my latest build of Orient.

    I didn't notice ANY noticeable framerate changes at all. And if they improved speed of vis compile it was negligible.

    But they do clean up the view when viewing the portal file.

    They could have a negative impact if used wrong for sure.
     
  15. Terr

    aa Terr Cranky Coder

    Messages:
    1,591
    Positive Ratings:
    405
    As far as I can tell func_viscluster does pretty much what it says on the tin: For the visleafs the entity encloses, VVIS takes a shortcut in processing and simply notes in it's data structure that any one of them can see all the rest.

    mat_leafvis will show no change, because the leaves themselves are unchanged, only their set of relationships is. Hammer seems to have some of the same smarts VVIS has (or else gets confused by the portal file) and will use the viscluster information inside the portal file to avoid drawing you visleafs which do exist but were clustered together. Use Hammer/Portal-file to debug clustering attempts, rather than mat_leafvis.

    At any rate, the only way func_viscluster can hurt you is if you do not follow the instructions... if you use it to connect areas which most of the time wouldn't always be able to see one another. Used correctly it will speed of VVIS, presuming VVIS is having problems with lots of open-air leaves anyway. It won't speed up your actual running of the game, because your computer still needs to deal with a huge list of "leaf X can see leaves 1-99999999", the only thing that is faster is generating those precomputed "leaf-X-can-see-leaves-Y/Z" bits.
     
    Last edited: Aug 8, 2009