• Shoutbox
    Active Users: 0
     
  • Notice: N/A
    Loading...
 
  • Active Users
     
  • There are currently no users chatting.
 
Results 1 to 8 of 8
  1. #1

    Excessive vis data size on a virgin source map

    Riddle me this:
    How does an unedited source map exceed the maximum vis data size by 1.5 times the limit?

    I know it's been done before but I poked around the Crossroads ("obj_team4.map") map altering one wall by request.
    I compiled and was amazed at the error:

    ************ ERROR ************
    LoadPortals: NumVisBytes 3089432 exceeds 2097152


    Thinking that something must be wrong with the calculation I compiled again.
    Same result.
    I compile a third time using MBuilder this time. Same result.

    So I removed all of the exploders in the bridge and reduced the height of the ridiculously tall clips, triggers and hints.
    The next compile gave this error:

    ************ ERROR ************
    LoadPortals: NumVisBytes 2950024 exceeds 2097152


    Getting a little closer but still no cigar.

    My question is how the FiretrUCK were they able to compile Crossroads / The Bridge with such excessive vis data?

    Was there a "mohdm4" source map released?
    If so, where can I get it?

  2. #2
    Administrator Major_A's Avatar
    Join Date
    Jul 2016
    Location
    Huntington, IN USA
    Posts
    328
    Trophies
    Blog Entries
    14
    I opened up my source maps folder, and it would seem out of 1-7, 4 is the one missing. Go figure.



  3. #3
    *Puts hand up in class with great enthusiasm*

    "Sir, I know why".

    They must have disabled automatic portal blocks during the compile, by using '-blocksize 0' in the BSP stage .

    By default this property is 1024, and will add a lot to your VIS data. Essentially it automatically generates portals (BSP tree splits) in 1024 x 1024 chunks.

    In maps that don't really use many structural brushes (like obj_team4), and relies purely on manvis instead, turning off blocksize is a neat trick that helps save visibility data and compile times.

    They may have also used -fast during VIS stage. 'fast' just means more VIS portals will be visible at certain locations than it otherwise would be, which isn't an issue for this map because it relies on manvis portals, and they aren't affected.

    Use these settings and let me know how you get on:



    I did a compare using q3map.exe against this recompile and the original BSP. See how the structure/data is almost identical (slight differences).

    Original BSP:



    Recompiled using above settings:



    So I think I'm pretty close to how the original devs compiled the map back in 2001.

    So remember, using manvis can increase your visibility sets and thus compile times if you're ALSO using the Quake-era VIS system. For MOHAA the devs invented manvis, to give you more control over what is rendered where. Sometimes you only need to use one or the other, not both systems.
    Last edited by 1337Smithy; 04-01-2019 at 07:23 PM.

  4. #4
    Guess who's getting a gold star on his report card? lol
    Thanks Smithy, that information is good to know..... in the right hands.
    Perhaps not good for me to know, as the community has been after smaller maps and I simply don't know when to stop. lol

    Cheers mate.
    You great source of knowledge, you.

  5. #5
    Using the "-blocksize 0" switch with the previously mentioned edits I managed to get the visdatasize down to 1958216
    Surprisingly 200,000+ bytes more than yours.

    I don't know what the vis data size of the default "obj_team4" map compiled at for me as I used MBuilder for that compile and Compile Mate's console for the slightly edited version of the same map.
    I'm just happy it's compiling.

    Thanks again, mate.

  6. #6
    Administrator Major_A's Avatar
    Join Date
    Jul 2016
    Location
    Huntington, IN USA
    Posts
    328
    Trophies
    Blog Entries
    14
    Glad you found a source of info...! Hopefully it's a checkbox on the compile options in the future, seems damned important to not make a note of, but to make an option of?
    Whatever said information you just gained, we know not what?
    referring to the pm you must have gotten lol



  7. #7
    Glad it's working!

    Major, can you not see my post earlier on this thread?

    Btw, if you ever wanted to keep portal splits but still lower data size, you just increase the size of the chunks. E.g. -blocksize 2048. Which essentially means fewer splits will be made.

    I should clarify though, even if blocksize is disabled, the game will still create splits if you use structural brushes like walls to a building or hints, and of course your sky box. So automatic VIS is still being generated. What are not being generated are 1024 x 1024 segments used to break up large areas. So to explain:



    The blue box is the skybox.

    The red blocks are the chunks generated by blocksize (lets say in this example they are 1024x1024).

    The black blocks are structural brushes used to create some rooms and a hallway between them. The numbers just show the number of 'leaves' the compiler has created. The game uses these areas to determine what can be rendered where. So for instance, if you're standing in room 5, the outside world won't be rendered, and also any interior rooms that aren't part of the Potentially Visible Set (PVS) won't be rendered, which in this case is room 1, as you can't see it from room 5.

    The large red chunks come into play if you want to create large rooms or if you want to break up your skybox, like done in some source maps. A skybox is just a large room, and treated no differently to that of the small black rooms in the middle.

    So for instance, you had a skybox like this:



    Now I've removed any black rooms and this map is just made up of large skybox rooms.

    I've numbered the 1024 x 1024 chunks this time.

    The green dot signifies the player's location.

    As it's a large area, and there aren't any other brushes blocking view or splitting up the level (other than the skybox), the game can use these large chunks to again not render certain areas. So from this player position, chunks 3, 4, and 9 can be marked as not seen and thus won't be marked for rendering (it will be culled), even though the player can see into the large skybox room from his position. So essentially it just creates invisible partitions in your map that work irrespective of your brush buildings, skybox, etc...

    Turning off blocksize means you no longer have these red partitions, meaning it'll all be rendered from that player position. But of course if you add the black rooms again, those interior rooms will continue to render or cull as desired. This is why it's adamant that you mark any brushes you don't want to use as splits (e.g. shadow volumes, detailing, etc...) as detail brushes because the compiler won't try and make these splits where you don't need them.

    Hope that made sense.

    For more reading, see this page from Valve's dev resource. As the Source engine uses BSPs too, it's largely the same.

    Taken from that page:
    The interior (i.e. not occupied by a world brush) space of a BSP map is split into visleaves. Visibility between these 3D volumes is calculated when the map is compiled, and embedded into the map file for use by the engine. Like brushes, leaves are always convex.

    The image to the left shows how leaves might be created in u-turn corridors (gaps between them have been added for clarity). There is no line of sight between leaf 1 and 3, and therefore when the camera is in one the contents of the other are not drawn. Calculating this is as simple for the engine as glancing at the map's embedded visibility chart.

    But there is a problem with leaf 2. The contents of all three leaves are drawn when the camera is within it, frustum culling aside, even if the left-hand wall completely fills its view. There are tools to overcome this that we'll look at shortly, but keep in mind that in a lot of cases fixing the problem will be more expensive than simply drawing the less-than-optimal scene.

    Bear in mind at all times that displacements, point and brush entities (including detail brushes) don't affect leaves. Create nodraw world brush 'foundations' if this is a problem: it's quite common for displacements to be created as detailed 'skin' on top of a world brush skeleton, for example.

    Note: World brushes with $translucent textures do cut visleaves.
    Warning: Leaves cannot be created if your map has a leak.

    Tip: Leaves are split every 1024 units along the xy-plane regardless of brush geometry in order to break large areas down. Hammer's grid is highlighted to help you accommodate this.
    Note: Leaves work vertically as well as horizontally. Treat skies as extensions of the streets and rooms beneath them.
    Last edited by 1337Smithy; 04-02-2019 at 09:59 AM.

  8. #8
    Major_A: It was 1337Smithy who thought to compile using "-blocksize 0" and posted his findings before my last two posts.
    And yes, the option has always been in Map Mate.

    blocksize.jpg

    I have never used blocksize before because I never fully understood it.
    After saying it here I know that's a bad excuse. lol

    1337Smithy: That was explained so crystal clear even a silly ol' fart like me could understand it.
    Thank you yet again kind sir.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •