Max_patches

DjArcasDjArcas Join Date: 2002-11-11 Member: 8187Members
<div class="IPBDescription">*shudders*</div> I know this is more a WC/VIS/RAD question than an NS one, but it is an NS map, and, well, gosh-darn it, there's some very nice clever friendly people here.

I'm getting the MAX_PATCHES problem - more than 65535 patches. Now, I've looked around, and the solution seems to be increaseing the scale on some textures, especially ones that aren't seen. One person recommends scaling up any textures touching the void by 100, which saved him about 100 megs of VIS data.

Question 1 - does that actually make any difference? Surely the VIS process throws away any textures facing into/touching the void?

Secondly, I can use the -sparse option, which gets around this problem - but does that simply mean my map is likely to arse up within HL itself?

Comments

  • c4xc4x Join Date: 2002-10-16 Member: 1512Members
    Yes, increasing the scale on textures helps.

    And you're also correct about VIS throwing away any textures touching the void. Well, actually the textures are still there, but VIS doesn't create any lightmaps for those textures, which is what patches are, lightmaps. So even if you do scale up textures touching the void it won't help.

    You could try using -chop with a value greater than 64, but the higher you go the worse your lightmaps will look in-game.
  • DjArcasDjArcas Join Date: 2002-11-11 Member: 8187Members
    edited November 2002
    Now here's the odd thing...


    8547 faces
    Create Patches : 67116 base patches
    0 opaque faces
    548434 square feet [78974560.00 square inches]
    9390 direct lights

    Ok, so I'm over the limit, but:


    Object names Objects/Maxobjs Memory / Maxmem Fullness
    ------------ --------------- --------------- --------
    models 28/400 1792/25600 ( 7.0)
    planes 9546/32767 190920/655340 (29.1)
    vertexes 11362/65535 136344/786420 (17.3)
    nodes 4389/32767 105336/786408 (13.4)
    texinfos 1612/32767 64480/1310680 ( 4.9)
    faces 8547/65535 170940/1310700 (13.0)
    clipnodes 11560/32767 92480/262136 (35.3)
    leaves 2416/8192 67648/229376 (29.5)
    marksurfaces 10604/65535 21208/131070 (16.2)
    surfedges 39921/512000 159684/2048000 ( 7.8)
    edges 20393/256000 81572/1024000 ( 8.0)
    texdata [variable] 5812/4194304 ( 0.1)
    lightdata [variable] 1412796/4194304 (33.7)
    visdata [variable] 123123/2097152 ( 5.9)
    entdata [variable] 6859/524288 ( 1.3)

    I'm not even CLOSE on any of those. *muttering to himself*
  • GreedoGreedo Bounty Hunter Join Date: 2002-01-24 Member: 37Members, NS1 Playtester, Contributor
    Use -sparse
    It will increase your compile time a fair bit, but you won't have any patches problems, and -sparse does not alter lighting quality in any way (for better or worse). As far as I know, all the official NS maps had to use -sparse to avoid patches problems.
  • DjArcasDjArcas Join Date: 2002-11-11 Member: 8187Members
    Thank you. If it all goes wrong later on, I'm blaming you, Greedo :-)
  • humb1edhumb1ed Join Date: 2002-10-06 Member: 1446Members
    edited November 2002
    Yeah, if you're not too worried about how things look on these not-final compiles, go ahead and do -chop 128 to cut down on compile times, at least thats what I do. And if you're just going to let it compile overnight or if you don't mind waiting a bit longer to see how the lighting will actually work, add -sparse and leave chop alone.
  • MerkabaMerkaba Digital Harmony Join Date: 2002-01-24 Member: 22Members, Retired Developer, NS1 Playtester
    This is a common problem, but thankfully one easily avoided.

    In the end I had to compile ns_hera with -chop 128. The lighting doesn't really suffer all that much, and if it does give horrendous results, you can always use -sparse instead. This will take MUCH longer though, and is only recommended for final compiles. You can also use -chop 96, which hardly affects the lighting at all.

    Alternatively, you can put the NULL texture on faces the player won't see, but are still in the level after BSP. This will stop RAD from building lightmaps on those faces, but it won't really help in any other way. (It's a myth that putting the NULL/SKY texture on unseen faces will raise the r_speeds.)

    During the BSP process, all faces touching the void or another brush are culled from the .bsp - this is why you can't decompile maps into brushes very easily - no data is kept for the culled faces. (So BSP doesn't just not build a lightmap for the culled faces - it deletes them altogether.)
  • Cash_Car_StarCash_Car_Star Join Date: 2002-11-03 Member: 6448Members
    On some systems with less RAM (such as my old compiling machine) -sparse can actually decrease compile time. It will help if hlrad seems to hit a wall somewhere in the MakeScales and progress starts becoming really slow.
  • SamRSamR Join Date: 2002-09-30 Member: 1382Members
    Hey

    Sorry to ressurect this topic, but...

    I've just hit the max patches problem with my map, Ns_Titan6. Oh bugger. I searched and found this thread, and have discoved the -sparse line which I can add to my compile.

    I am a little confused though, what does this actually do? Why does it allow me to go over the limit, and are there any side effects which will be apparent in the map?

    Any help would be very much appreciate <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' valign='absmiddle' alt='biggrin.gif'><!--endemo-->
  • BumbleBeeBumbleBee Join Date: 2003-01-13 Member: 12239Members
    To answer this question just look at the pinned topic at top by Tommy14
  • SamRSamR Join Date: 2002-09-30 Member: 1382Members
    edited January 2003
    I already checked the pinned topic, and there isn't any mention of -sparse in there.

    EDIT: There is a mention of sparse, but it doesn't answer my questions
  • RhoadsToNowhereRhoadsToNowhere i r 8 Join Date: 2002-01-24 Member: 33Members
    -sparse just uses a different algorithm to calculate the lighting. The vismatrix is represented differently --instead of using a fixed-size matrix that stores every entry, they use a "sparse matrix" which only stores the necessary entries. The size is much more variable that way, so you can go above the max_patches limit.

    I think. <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' valign='absmiddle' alt='tounge.gif'><!--endemo-->
  • SamRSamR Join Date: 2002-09-30 Member: 1382Members
    Ok, so using -sparse means that there are no limits at all anymore on the number of patches I have?

    Good <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' valign='absmiddle' alt='biggrin.gif'><!--endemo-->
    Thanks for the help...
  • blue2kblue2k Join Date: 2002-11-02 Member: 4025Members
    and thats how babies are made.
  • XaSerXaSer Join Date: 2011-08-05 Member: 114386Members
    how to use -sparse with valve hammer editor 3.5 ? Where and how do I type it? Run - Expert ?
  • Kouji_SanKouji_San Sr. Hινε Uρкεερεг - EUPT Deputy The Netherlands Join Date: 2003-05-13 Member: 16271Members, NS2 Playtester, Squad Five Blue
    edited August 2011
    Heh the best thing you can do for custom compiling is use the <a href="http://nemesis.thewavelength.net/index.php?p=3" target="_blank">batch compiler</a> in combination with the latest compile tools called <a href="http://zhlt.info/" target="_blank">zhlt</a>


    [edit]
    Also damn this thread is old :D
  • XaSerXaSer Join Date: 2011-08-05 Member: 114386Members
    edited August 2011
    <a href="http://paste2.org/p/1569738" target="_blank">http://paste2.org/p/1569738</a>

    "wad" is ""

    Error: File read failure


    help?
  • Kouji_SanKouji_San Sr. Hινε Uρкεερεг - EUPT Deputy The Netherlands Join Date: 2003-05-13 Member: 16271Members, NS2 Playtester, Squad Five Blue
    It seems you're going over the texture memory set (8Mb). Now this won't show you a recognizable error, because you're including them into the bsp and instead will show you an (none-informational) read error instead. Try and compile without including them to see where it goes.

    Sidenote:
    I'm not sure goldSRC can handle anything over 16Mb though. It's not a computer speed issue, it's mostly an engine choking issue.
  • GiGaBiTeGiGaBiTe Join Date: 2003-10-07 Member: 21489Members
    <!--quoteo(post=1867622:date=Aug 8 2011, 05:41 PM:name=Kouji_San)--><div class='quotetop'>QUOTE (Kouji_San @ Aug 8 2011, 05:41 PM) <a href="index.php?act=findpost&pid=1867622"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It seems you're going over the texture memory set (8Mb). Now this won't show you a recognizable error, because you're including them into the bsp and instead will show you an (none-informational) read error instead. Try and compile without including them to see where it goes.

    Sidenote:
    I'm not sure goldSRC can handle anything over 16Mb though. It's not a computer speed issue, it's mostly an engine choking issue.<!--QuoteEnd--></div><!--QuoteEEnd-->

    Actually, the default texture usage limit is 4M, not 8. HL was released in the times of yore when most people had GPUs in the 4M range, and "gamer" cards of the time required you to sell a kidney (3dfx).

    IIRC, HL has a limit on the number of unique textures allowed in a single map. You can theoretically allocate as much texture memory as your GPU has. Since most modern cards have well over 256M, you aren't going to hit that limit before you hit the unique textures limit. I've used up to 64M in textures before in a map and there was no noticeable performance impact.
Sign In or Register to comment.