remove the compilators limits Created 20 years ago2004-11-13 21:19:16 UTC by J.C

it may look something stupid, or ridiculous I don't know, but I think I just hit the compilators faces limit, and after tried to modify, remove, reduce and so on the last blocks I just added, I realized there are no way to complete my map by adding more blocks, because there are no more way to complete a compilation.

then I wondered, because I do think there's no problem with Hammer and HL, and only with the compilators, if there could be a way to remove or increase or make anything with those damn limits that I could complete my map.

this map I am working is 60% done, mean a huge ammount of work time, and I wouldn't like to that wasted

I compile with ZHLT,
the faces total in Hammer are 14831,
there may be 18674 faces in ZHLT while compiling, just before it stops, but I am not sure ...
the error is "hlrad : error : Exceeded MAX_PATCHES"

what do you think about that ?

Compilators? Compilers.

Tommy says about "Exceeded MAX_PATCHES":

Exceeded MAX_PATCHES

When hlrad runs, it takes all the visible faces in the game, and divides them into sections called patches. These patches are the textures used as the lightmaps for the world. There is a hard limit of 65535 patches that hlrad can deal with. By default, a 64x64 game unit chunk of space is the size of one patch. If the texture scaling (not texture size) is larger or smaller, it will directly affect the lightmap size as well. This means a texture with scale of 2, will have at best 1/4th as many patches as a texture with a scale of 1.

Putting a 'box' around the level to protect from leaks is the most commmon cause of this error, beyond excessively large maps. The box causes vis to keep the faces on the outside which would normally be thrown away. These faces are then required to have lightmaps. Worst case, is that putting a box around the level will usually cause an extra 40-80% more lightmaps to be created than necessary.

Barring having a box, the other cause is large maps. The fixes are varied but can only help so far.

Remove any "box" from around your level and fight the leak leak leak war the right way.

If you have not boxed in your level, then the #1 fix is running HLRAD with the -sparse flag - but compile will be slower.

Using -chop values larger than the default 64 for hlrad will cause the light patches to be larger. However, for values larger than around 96 the map's lights start looking bad, and will more prominently show the 'staircase' effect on shadows.

Using a larger scale on large textures (dirt, rock walls, concrete) will help those large surfaces consume fewer patches for lighting.

!!!

And those .1 textures, too! They are ten times the patches....

k I set the texture scale to 0.2, I slightly reduced the skybox, and our team programmer made me a modified version of the compilators, which now are correctly processing, but stop all the same the compilation because ... I don't have enough RAM !

the error ZHLT reported :
visibility matrix : 290.9 megs
Failed to allocate s_vismatrixError: Memory allocation failure
Description: The program failled to allocate a block of memory.
Howto Fix: Likely causes are (in order of likeliness) : the partition holding the swapfile is full; swapfile size is smaller than required; memory fragmentation; heap corruption

I got 512 DDR wtf

those damn comps, every three months you need to upgrade something ...

Idd, you need to make those 0.2 textures (HL doesn't liek anything lower than 0.10 on a single face, let alone 40 or 50, which is what this sounds like)

I hope you got rid of teh skybox.

If you use a skybox you will run out of memory, and that's what's happening. You need to rememebr that any face that is inside the map area will be rendered, so if you don't have teh sky cutting off everything on the outside you'll be in trouble.

Set things like paper on tables to func_wall or func_illusionary.

cylinders should be a func_wall, or they should not be allowed to touch any other world brush.

HL can't handle too many complex shapes, I think your engine room might be a problem, looks very complex in terms of shapes cutting into each other. Try getting some models or make more of the stuff into func_walls.

And how about your knowledge of the engine/compilers?

this is my second map for HL, and probably the last one ...
I don't know that much the compilers, but I stand by the community to support me ...

Half-Life uses a bsp method wich isn't really optimized for outdoor scenes...

I know, don't worry : most part of the game happens in the destroyer, and inside rooms are, I think, well layed and scattered. the only thing that bother me, is that HL/Hammer are considering the portholes as potentials exits, and uselessly draw most of the time the half of the ship, even if I close the windows with skyboxes : ...

Are you using entities to ease the VIS process for example?

yes and no : I added some hints brushes in the map, but I think there aren't considered by the engine because I only run fast compilations ...
why only fast ones ? because :
fast compilation = about 10 minutes
full compilation = more than 13 hours.

You need to rememebr that any face that is inside the map area will be rendered

but I didn't know the skybox was rendered, I mean I don't see any patches of sky, there aren't lighting rendering on, neither shadows or anything, are youy really sure the skybox is rendered too ? : ...

Set things like paper on tables to func_wall or func_illusionary.

I know that trick is useful for some objects on a standard map, but I am not sure that could help if I apply it in this project, because on a way a lot of thing is touching a lot of things, then what do you think that will happen if about 20-25% of the map is turned into func_walls ?
I never tried : I will make a test ... is there any func_walls number limit ? ^^

cylinders should be a func_wall, or they should not be allowed to touch any other world brush.

there aren't cylinders in this map, from a Hammer point of view, I only gather boxes and use a lot the vertex tool, but that's ok I get what you mean.

HL can't handle too many complex shapes, I think your engine room might be a problem, looks very complex in terms of shapes cutting into each other. Try getting some models or make more of the stuff into func_walls.

I think you underestimate HL/ZHLT/Hammer : I thought like you first, but when I build and compile the map, I am amazed (using the wireframe display) to see how the compilers are making wonders with so much faces : a very smart laying in my opinion.
and on an other hand, 500 more or less faces aren't that critical in this kind of map, I mean with our current computers : personnaly I don't notice any real slowness when there are 2000 wpolys on the screen instead of 800, and my comp cannot run Doom3 ...

I will upload soon on the webpage an alpha version of the map : that way you will be able to directly see how the map is build and what could be improved ...

A skybox isn't rendered as faces or the like, it only shows the sky. The actual problem with 'skyboxing' a level (placing a large box around your level) is that is causes a lot of extra places in your level to be compiled, and in-game to be rendered too. Sometimes the effects are worse than in other situations, but the method is usually discouraged.
Therefor, I would recommend you to keep the outside as simple as possible, only letting the decks be compiled, e.g. sealing of the rest with skybrushes, so that the hull of the ship isn't being compiled. I suspect that that area of the map causes a lot of extra VIS work.

I would definitely recommend the use of entities to avoid a lot of unnecessary face-splitting. True, face splitting will happen in a lot more occasions, but some face-splittings are just easy to prevent and unnecessary. Small, detailed brushes should nearly always be made entities. Better for the VIS process too.
Sure, there's an entity limit, but you're closer to your performance limit than to your entity limit...

As for r_speeds... true, nowadays computers can handle a lot more, but that doesn't say the Half-Life engine can... it's only flexible to a certain amount. 1200-1300 is the aim of some SP mods, but 800-900 should be kept as DM maximum (and only such high numbers in non-combat zones preferrable). You may not see slowdown but keep in mind there will be played in your map, and that on itself already takes up calculation time. Then image a few player models having to be rendered... There's more than only polygons that slow down a map, so you'd better not take it too high.
Also... not everyone has such a higher-end system. Now it indeed depends on the public your aiming for, but I think it's best to keep it easily playable, even for the lower-end machines.

And... to see the actual performance, run full VIS. It would also be good to plan out the level beforehand, marking high-poly and low-poly area's, starting with little detail and watching performance, then deciding where's room for some extra detail and where isn't. Planning saves a lot of time on the long run...

wow you are talking like a professional Oo|

I cannot run a compil full VIS as long as I don't have an other comp : I tried once to compile the map with the preset "final compilation", but after 13 hours, the compilers evaluated the time needed to complete to 17 hours again, that's why I am looking for a month for a comp to rent to test full compilations ...

I tried to turn into func_walls some pipes that are touching walls or other parts of the rooms : I will quickly see if that's useful to build all the map that way or not ...

thanks all for your advices by the way.

k I created 1 unit spaces between little contact zones, I made func_wall with blocks which needed to have a "clean" shadow and was making other faces to split, I reduced the skybox, I applied your advices, I seen a slight reduction of the r_speeds, but ...

now I got a Exceeded MAX_MAP_CLIPNODES compil error ...

with no more details : I DIDN'T added more blocks, I just optimized the map, wtf is wrong again ? : ...

k I just read the ZHLTProblems.html file : I need to add clip brushes to define more accurately the player-accessable space ...

NNNNOOOOOOOOO you don't say!?