Max_patches

DjArcas · November 2002

<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?

c4x · November 2002

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.

DjArcas · 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*

Greedo · November 2002

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.

DjArcas · November 2002

Thank you. If it all goes wrong later on, I'm blaming you, Greedo :-)

humb1ed · 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.

Merkaba · November 2002

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_Star · November 2002

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.

SamR · January 2003

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 <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' valign='absmiddle' alt='biggrin.gif'>

BumbleBee · January 2003

To answer this question just look at the pinned topic at top by Tommy14

SamR · 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

RhoadsToNowhere · January 2003

-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. <img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' valign='absmiddle' alt='tounge.gif'>

SamR · January 2003

Ok, so using -sparse means that there are no limits at all anymore on the number of patches I have?

Good <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' valign='absmiddle' alt='biggrin.gif'>
Thanks for the help...

blue2k · January 2003

and thats how babies are made.

XaSer · August 2011

how to use -sparse with valve hammer editor 3.5 ? Where and how do I type it? Run - Expert ?

Kouji_San · 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

XaSer · 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_San · August 2011

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.

GiGaBiTe · January 2012

<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'>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.</div>

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.

Max_patches

Comments