Microscopic leak

Well, it appears that there is a bug in the compiling tools that will cause leaks under certain circumstances.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

Here is a screenshot of the hole (leak) created by the compiler:

(in game shot with "MAT_WIREFRAME 2", zoomed in with "NOCLIP" on)<o:p></o:p>

<o:p></o:p>

Probable causes:<o:p></o:p>

A) I'm guessing that the compiler is set to ignore solids or faces that are exstreamly small in nature. Unfortunately when the faces are cut up by the compiler it would appear that these holes are created in the process (creating the tiny solids).<o:p></o:p>

B) I have been using the vertex manipulation tool pretty extensively in this map, selecting more that one vertices at a time from more that one solid at a time. I haven?t used the scaling tool on any of the locations where the holes appear after compiling. Perhaps there is a bug with the vertex tool that causes the vertices to float off the grid at a microscopic level, thus causing the odd face split and leak.<o:p></o:p>

<o:p></o:p>

If it is in fact a problem with hammers compiling tools ignoring the small solids or faces does anyone know a compiling command that will cause hammer to not ignore these faces?<o:p></o:p>

EDIT: The solids that I am having a problem with are all four sided pyramids ( this may be why the pieces are so small after the compile tools shatter them when splitting the faces ).





(note: I have a specific reason why I am using four sided solids, for one it is impossable to create an invalid solid, unless you turn it inside out (game won't start and compiler doesn't mention any error). Also I have a new technique for working with four sided solids and the vertex tool. The only problem is what I mentioned above, beyond that its working great)



.

Hmmm is it connected in Hammer? If thats the case and your still
getting a leak then I would suggest putting a brush over it entirely,
and make it look like a rock (its not professional, but it prevents you
from having to do it over again). Or just rework the brushes in
that area, because like you said the tools are probably not calculating
it due to it being extremely small, and I dont think there is anything
else that you can do.

edit: have you tried "-full or -high" as paramiters for the bsp? That might solve the problem.

Well, setting a rock over the location would actually cause more problems, face splitting and such (I wish it where that easy). Also I'd say 95% of the faces in this map do not sit smoothly on any particular axis (x, y or z).<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

I havn't tried "-full" or "-high" yet but I will give it a try tonight.<o:p></o:p>



One long time consuming work around I did find :<o:p></o:p>

I have been able to get rid of some of the holes (as seen in screenshot) by revertexing all the verities to a new point in the grid, causing the face to be cut differently. Now, this is a work around but it isn't a clean (fast & fool proof) solution. The problem with this is that I have to hunt these holes down in HLDM with MAT_WIREFRAME 2 & NOCLIP activated and then look for the holes from the outside of the map (can see tiny triangles floating). There are dozens of holes through out the map currently. If there is a clean solution for this problem then it will solidify the mapping technique that I have come up with and I will post tutorials on how to do it.

<o:p></o:p>

Here is an example of the technique and the map that I am working on:



It hasn't reached the texturing stage but as you can see the geometry is quite complex. It didn't take nearly as long as you might imagine thanks to a certian technique I have come up with for creating and editing the solids.



100% 4 sided solids (excluding the skybox) (no solids overlapping)

Good looking map BTW, maybe you should try a displacement surface instead (cause it looks like its all brushes).

Your technique.....is it about adding verticies to 4 sided object (eg:
Ctrl-F) in vertex editing mode, because I cant really help you without
knowing what this "technique" is.

Edit (in response to orph): Have you tried alt-P? to check for any invalid brushes?

you know i was thinking the other day, what if the combined the ".maps removing invalid solids" with the "tools"

this would locate invalid solids real fast.

if i were you, and i knew this was going to happen, i would butt up a world brush on the back side before i compiled.

[edited for grim to more easily see.]

That looks great, but won't texturing it without massive misalignments be nigh on impossible? Also, how long do compiles take? I can't imagine vis being to happy with all those weird slanting angles!

<DIV class=quote>
<DIV class=quotetitle>? quoting omegaslayer</DIV>
<DIV class=quotetext>Good looking map BTW, maybe you should try a displacement surface instead (cause it looks like its all brushes).

Your technique.....is it about adding verticies to 4 sided object (eg: Ctrl-F) in vertex editing mode, because I cant really help you without knowing what this "technique" is.

Edit (in response to orph): Have you tried alt-P? to check for any invalid brushes?
</DIV></DIV>
If you add verts it's no longer a four sided solid! And as he already said, because he is using four vert brushes, it ought to be almost impossible to create invalid soilids. whenever I am doing complex 3D curves I cut my brushes up this way.

Thanks, the map is for the competition. Hopefully I'll have it done this weekend.<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"> <v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></v:path><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:lock aspectratio="t" v:ext="edit"></o:lock></v:shapetype><v:shape id=_x0000_i1025 style="WIDTH: 11.25pt; HEIGHT: 11.25pt" alt="" type="#_x0000_t75"><v:imagedata o:href="http://www.snarkpit.com/images/smiles/icon_smile.gif" src="file:///C:/DOCUME~1/RICHAR~1/LOCALS~1/Temp/msoclip1/01/clip_image001.gif"></v:imagedata></v:shape><o:p></o:p>

The "technique" really doesn't have anything to do with the problem unfortunately; the technique is just creating certain prefabs that can be easily sculpted into just about anything. It is similar to using a displacement surface but yes, using solids. Displacement surfaces are great in some areas, I have them in the map but the core of the map is solids. Everything in the screenshot is solid, displacements wouldn't due for what I am working on (wanna make an entire map out of displacements? :wink: )<o:p></o:p>

The problem doesn't rest in how the solids where created it rests in the cutting of the faces. All the verities have been resting on the grid, at least from what I can tell, zoomed in 100%<o:p></o:p>

<o:p></o:p>

Well alls I can say is to re work the brush work in that area....

<DIV class=quote>
<DIV class=quotetitle>? quoting omegaslayer</DIV>
<DIV class=quotetext>Edit (in response to orph): Have you tried alt-P? to check for any invalid brushes?
</DIV></DIV>

Alt+p has never found them before, why would it suddenly begin to?

the only method i know for sure finds invalids is "exporting to .map+closing+reloading the .map"
this is only a comment to omega, if grim is sure its not an invalid solid, i trust him.

Never done the exporting thing before (I should really try it!)

If face-splitting is your problem, try making some of the brushes
func_details. They work just like func_walls did back in HL1
(they don't block VIS or split faces) but they are lit like real
brushes.

Texturing is going to be a hassle, I do have a plan though. Selecting all the faces in the entire map at once and the selecting "world" or "face" alignment. I can't remember which I used but I tested it and it aligned all the faces so that they could be textured correctly.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

<o:p></o:p>

The map compiles very quickly with four sided solids, unless of course you build a box around the map and try to compile, then it has to deal with the spiky outside of the map, its almost impossible to compile at that point. The outside of the map looks like a big porcupine.

I must say wow to your map.... I mean i dont know how you ever made
that without getting errors looks like u made the thing in a 3d program
like 3ds lol nice work tho.. ne better tips on your technique i
see the prefab and easily sculpted but id love more detail if you could
explain a bit more

<DIV class=quote>
<DIV class=quotetitle>? quoting Raeth</DIV>
<DIV class=quotetext>If face-splitting is your problem, try making some of the brushes func_details. They work just like func_walls did back in HL1 (they don't block VIS or split faces) but they are lit like real brushes.
</DIV></DIV>

I wish I could do exactly that but these solids seal the outside void. Unless you can use FUNC_DETAIL to seal the void.
As far as there being invalid solids it would not be possible due to the fact that there are only four verticies.

<DIV class=quote>
<DIV class=quotetitle>? quoting sXenoG</DIV>
<DIV class=quotetext>I must say wow to your map....</DIV></DIV>
grim always makes stuff like this. personally, i've come to expect it.

[edit] grim go back and read my 1st reply

<DIV class=quote>
<DIV class=quotetitle>? quoting sXenoG</DIV>
<DIV class=quotetext>I must say wow to your map.... I mean i dont know how you ever made that without getting errors looks like u made the thing in a 3d program like 3ds lol nice work tho.. ne better tips on your technique i see the prefab and easily sculpted but id love more detail if you could explain a bit more
</DIV></DIV>
Thanks, I'm actually trying to perfect the techique before I post any tutorials. Once I figure out a good way to deal with the micro leaks I am experiencing then I will just about be ready. (ofcourse I'll need to finish my map first since there isn't much time left :smile: )

<DIV class=quote>
<DIV class=quotetitle>? quoting Orpheus</DIV>
<DIV class=quotetext>you know i was thinking the other day, what if the combined the ".maps removing invalid solids" with the "tools"

this would locate invalid solids real fast.

if i were you, and i knew this was going to happen, i would butt up a world brush on the back side before i compiled.

[edited for grim to more easily see.]

</DIV></DIV>

The only problem with that Orpheus is that there are dozens of these holes in the map at the molment, hunting them down alone is pretty time consuming, covering them with solids on the back? Would take too long, considering the outside is spikes and also the number of these odd holes that appear after compiling. Thx for the idea though.

remember bud, i have not even loaded the new hammer yet so all my comments are hypothetical.

you could possibly use scary_1's old trick. he put sky brushes behind all his complex shapes to seal them. sky textures do not cause issues when they bisect other world brushes, so overlapping is not an issue.

put a big block of sky on the backsides

Using the sky texture on a brush might come in handy in a few locations, I'll have to remember that one :smile: .

Well, it appears that there is in fact verticies floating off the grid in the map I am currently working on:

Screenshot of max zoom in hammer, scaled in photoshop to further reveal gap:



I can only imagine that the cause of such a small discrepancy in alignment could be caused by some faulty calculation in hammer.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

<SPAN style="FONT-SIZE: 10pt; COLOR: red; FONT-FAMILY: Verdana">I didn't use any scaling, rotating, clipping or carving on this solid, again it is four sided, four faces and four vertices. This solid DID come from a prefab, I suppose that could be the problem; maybe hammer isn't calculating the placement of prefabs properly. After it was created via dragging a box to create (inject) the prefab it was manipulated with the vertex tool to its current location on the grid, I believe I did move more that one verticy at once while moving it. Anyway I think I am at least limiting the possibilities as to what could be causing the problem.<o:p></o:p></SPAN>

I?ve also tried using the following BSP commands to avoid shatered solids/faces:

-verbose <o:p></o:p>

-noprune <o:p></o:p>

-nocsg <o:p></o:p>

<SPAN style="FONT-SIZE: 10pt; COLOR: red; FONT-FAMILY: Verdana">?noweld (too many vertices with this one)<o:p></o:p></SPAN>

-micro <.1><o:p></o:p>

And to test for the leaks faster: -leaktest<o:p></o:p>

<o:p></o:p>

<o:p></o:p>

<DIV class=quote>
<DIV class=quotetitle>? quoting Orpheus</DIV>
<DIV class=quotetext>remember bud, i have not even loaded the new hammer yet so all my comments are hypothetical.

you could possibly use scary_1's old trick. he put sky brushes behind all his complex shapes to seal them. sky textures do not cause issues when they bisect other world brushes, so overlapping is not an issue.

put a big block of sky on the backsides

</DIV></DIV>

What map did scary_one ever make that had complex brushes? I seem to remember them all being very smooth and flowing with focus on gameplay over looks...
Also, Grim, this rockwork is ridiculous. I don't know how you have the patience for it.

Well, after much testing I am at a complete loss.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

After spending a few hours fixing the little holes by moving vertices I decided to just start placing blocks over the areas so that I could get a count of how many holes I was dealing with....... I think I got up to 50!!! Then I decided to just start blocking off huge chunks of the map all-together, I'm down to maybe 10% of the map and still getting leaks!!!!<o:p></o:p>

So I guess after all the energy I put into this "technique" of mapping solids in such a complex way it was all for nothing!!!! All I have to say is THANK YOU VALVE AND F*CK YOU!!!! I can't believe hammer is such a piece of s**t! I am 100% confident that it isn't the result of anything I did, I didn't make any mistakes, it?s in "steamer world editor"<o:p></o:p>

Man, I really feel that I had a good shot at that competition, to at the very least hit the top ten, maybe the top 3.<o:p></o:p>

If this is what we can expect of the latest hammer editor then honestly I don't want anything to do with it!!!! What?s the use of having access to the potential of the source engine if it can't be fully tapped due to the world builder programs limitations? <o:p></o:p>

SCRAPPED DUE TO BUGS IN HAMMER AND THE COMPILER TOOLS!!!!!!!<o:p></o:p>

My first and possibly LAST hl2 map, depending on how I feel after I cool down!!!<o:p></o:p>

Maybe I'll put it up for download so people can poke at it and see what was beyond the range of the valve "steamer editor" and current compiler tools.

I'll post some screenshots of the solids I created for the prefabs and also a brief desciption of the technique I was attempting to build and perfect. Tomarrow maybe.

Thanks to everyone who posted on this topic!

Damn. I've never been very impressed with the ability of hammer to keep verts where they should be. In Feculence I have lots of pretty complex rockwork and, somehow, a large chunk of it ended up slightly off-grid, even though I KNOW I didn't build any of it that way. It was iritating because I think it lengthend my compile times, but fortunatly it didn't cause any leaks.

Wasn't there a way with the old tools to change the size at which BSP split brushes? Is there nothing like that you can try with the new tools? Also, I seem to remember reading that the default split distance in HL2 is 1024 units. Maybe if you worked your geometry so that no individual face was greater than 1024 units in any direction you could get a 1:1 ratio of faces in hammer to those after the compile... and what about HINT brushes? don't they cause face splitting? Maybe you could manually direct the splitting in a more optimal way? There might be some way that you could incorporate hint brushes into your construction technique so that you would "automatically" compensate for this devastating error...

If you can't tell, I really want to see this map completed!

Maybe you could just go not-so-over-the-top with the vertex manipulation?

In all my years of using vertex manipulation I have never had any problems caused by the editor. Every leak or error I got was user-created, and usually caused by carelessness. In this case I'd say the human error is merely because of the complexity of what you're doing, the large number of strange angles you're attempting, and the density of lines you have on the screen. I haven't come across anything like this in the new Hammer either. Oh well, maybe I just don't push enough mapping limits.

I doubt you'd be able to do what you're attempting in either the doom or the unreal engines, so I don't think you should throw in the towel with HL2 just yet.

<DIV class=quote>
<DIV class=quotetitle>? quoting Yak_Fighter</DIV>
<DIV class=quotetext>

What map did scary_one ever make that had complex brushes? I seem to remember them all being very smooth and flowing with focus on gameplay over looks...

</DIV></DIV>

lets say rather, more complex than 90* wall buttresses then :biggrin:

seriously though, Steve sent me a few of his older .rmf's and i noticed that be did stuff like putting sky brushes on the back side of things.

he even went so far as to make sky's that fit angles.. its hard to explain, but a sky brush over a windowed area might be made of 20 or so brushes.

anywho's, someplace i have a s**tload of .rmfs on a disk. i may even have a copy or two of yours :biggrin:

<DIV class=quote>
<DIV class=quotetitle>? quoting GrimlocK</DIV>
<DIV class=quotetext>This solid DID come from a prefab, I suppose that could be the problem; maybe hammer isn't calculating the placement of prefabs properly.</DIV></DIV>

i'd say your right, and that it's a bug that's been inherited from earlier versions of hammer. 3.3 and 3.4 both acted like this when i had a go at making some modular cave/tunnel prefabs that could be mixed and matched. it wasn't all made with 4 sided solids, but like yours, there were very few faces on an X,Y or Z plane.
i didn't complete the whole set, but i found that overlapping the brushes you wanted to turn into a prefab with a large world brush [that sits perfectly on one of the larger grid sizes] solved this. just delete the large brush after you import the prefab, and the prefabs vertices should all be on the grid.

Orpheus said:
<DIV class=quote>
<DIV class=quotetitle>? quoting omegaslayer</DIV>
<DIV class=quotetext>Edit (in response to orph): Have you tried alt-P? to check for any invalid brushes?
</DIV></DIV>
Alt+p has never found them before, why would it suddenly begin to?

</TD></TR>
<TR>
<TD height=5></TD>
<TR>
<TD style="FONT-SIZE: 11px; COLOR: gold" bgColor=black>http://www.snarkpit.com/users.php?name=omegaslayer

/me was wondering, can you not just "snap to grid" an entire map if necessary?

.

.

.

.



very nice.. i am glad they finally addressed this.

Its as if the "snap to grid" option only applies to changes YOU make,
since hammer very often puts vertices off the grid. What we need is a
tool that loads the VMF and rounds off all the vertices.

Here is some images of the prefabs I created for my project. There are a few other variations of the two 4 sided solids grouped, I excluded them because you could only see the nodraw texture since they where facing away. I also created a variety of the two grouped 4-sided solids (non-prefab) for various areas.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

I know it may be hard to believe for some but all the leaks have been generated by a problem either in the compile tools or in hammer it self. I was extremely careful when editing. Part of the "technique" I was using involved selecting all vertices on one grid point and manipulating them to mold the world. I both moved the selected vertices with the mouse at times and the nudge feature also (arrow keys).<o:p></o:p>

Anyway, I've decided to start over from scratch (I don't give up so easily :wink: ). This time with another one of my "techniques" that hopefully, will make the map even better than it would have been with the 4 sided technique solely. There isn't much time but hopefully I'll be able to get most of it done today and during the next week.

<SPAN style="FONT-SIZE: 10pt; BACKGROUND: black; FONT-FAMILY: Verdana">EDIT: Orpheus, I did try to "snap to grid" but it had no positive effect, with everything selected it only moves everything as a whole, preserving what ever gap may or may not be there. I could snap each piece individually but their are over a thousand pieces that I would have to go through, also "snap to grid" doesn't work on individual vertices. I still think it has something to do with the fact that the solids get very thin at their point which causes issues in the BSP process.</SPAN>

Prefabs created for project:<o:p></o:p>

The spiked arch was to be created at 960 X 960 to avoid floating vertices, all other solids theoretically should have been find no matter what size they where created on the grid.<o:p></o:p>





pulled apart:



<o:p></o:p>

well grim,

"i grieve with thee."

Grim, what your doing will work if the prefabs are completly enclosed in a big brush when they're made, that forces the smaller details to stay aligned on the grid when you import it again.

on the other hand, i do believe you're right to look at other ways of getting the complex geometry that you want. unless you need a concave face, there's no need to use any more than one brush, and when you do use only one brush for something like a rounded hill-top sort of shape, you get a lot less snagging. and with fewer brushes, there's less face splitting.

Ctrl+f is your friend :smile:

Orph, the pic i posted was from hammer3.4. as far as i know, which only goes back to a week or so before 3.3 was released, the editor has always found invalid solids. maybe not all of them, but it must have picked up 99% of mine.

<DIV class=quote>
<DIV class=quotetitle>? quoting fishy</DIV>
<DIV class=quotetext>

Orph, the pic i posted was from hammer3.4. as far as i know, which only goes back to a week or so before 3.3 was released, the editor has always found invalid solids. maybe not all of them, but it must have picked up 99% of mine.

</DIV></DIV>

hmm. well i stand corrected then. i learned the trick i posted in 2.1, it worked in 3.3 and .4 and.5 so i never questioned its accuracy. if alt+p works too, tis all good.

fortunate for my style, i rarely create an invalid solid, so i honestly do not know how accurate alt+p is.
good call.

Well, on further testing I discovered that shards do in fact cause leaks, if they are small enough, take a look at this screenshot of my test:

EDIT: this test box contains 48 4 sided solids. It compiled fine, I even vertexed some of the solids and it still ran fine. When I cut the solid as seen in the pic it created a leak.

This was actually my second attempt at cutting a shard, the first one fit on a single grid block, and worked fine. The second in the pic is smaller than one grid section:

Well, here is my proof.... the compile tools ARE causing the problem!!!. Its cutting my solids into shards and then conveniently deleted the ones that fall off the grid!!!! To find out for sure id did some more testing, check out the screenshot:<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

<o:p></o:p>

After my shard test I repaired the hole, test compiled and it worked fine, then I decided to do another test, force the compiler to cut up the 4 sided solid. I placed a block over the solids, compiled and it leaked!!!<o:p></o:p>

I was even using the following BSP options:<o:p></o:p>

-verbose -leaktest -noprune -nocsg -micro <.1><o:p></o:p>

<o:p></o:p>

anyone have any news on more advanced tools for HL2?

Cutting things is obviously asking for trouble -- I would expect
the box example to leak nearly every time just as if you have used the
box to carve the surrounding brushes. I thought the whole point
of using 4 vertex solids was to allow you to vertex edit without
worries. If so, why clip anything? That's just asking for
these sorts of floating point errors. Perhaps I'm
misunderstanding what you're trying to show.

I have floating verts, but in bits I made using the box tool! How the hell this happens i don't know, but it forced me to go through my map for hours fixing it...

Grim. I applaud you trying to create this elaborate process for rockwork. I used similar techniques with Hl1, for rocks (wedges, but not prefabs). I am sorry that it seems to be causing so many problems...very frustrating stuff. That said...

Why the hell aren't you just using displacements!!!?

Seriously, looking at your screenshot I don't see anything that I couldn't build with the new dispalcement method. In the end, I think that you are focusing way to much on technique, and making this MUCH harder for yourself. Give in to the dark side.. work with dispacments. Save yourself this heartache, my son.

<DIV class=quote>
<DIV class=quotetitle>? quoting Raeth</DIV>
<DIV class=quotetext>Cutting things is obviously asking for trouble -- I would expect the box example to leak nearly every time just as if you have used the box to carve the surrounding brushes. I thought the whole point of using 4 vertex solids was to allow you to vertex edit without worries. If so, why clip anything? That's just asking for these sorts of floating point errors. Perhaps I'm misunderstanding what you're trying to show.
</DIV></DIV>

I apreciate the comment Raeth but you should read a little deeper in the thread to understand the problem. The clipping and also the block where just tests to confirm problem in hammer and the compile tools.

Finger, I have started reconstructing a large portion of the map with displacements but have found that you quickly hit certian limits when the displacements get more complex.

Maybe this limit can be safely ignored, does anyone know??

see ORANGE highlight:

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 1/1024 48/49152 ( 0.1%)
brushes 9/8192 108/98304 ( 0.1%)
brushsides 54/65536 432/524288 ( 0.1%)
planes 338/65536 6760/1310720 ( 0.5%)
vertexes 251/65536 3012/786432 ( 0.4%)
nodes 65/65536 2080/2097152 ( 0.1%)
texinfos 16/12288 1152/884736 ( 0.1%)
texdata 6/2048 192/65536 ( 0.3%)
dispinfos 128/0 22528/0 ( 0.0%)
disp_verts 36992/0 739840/0 ( 0.0%)
disp_tris 65536/0 131072/0 ( 0.0%)
disp_lmsamples 214764/0 214764/0 ( 0.0%)
faces 181/65536 10136/3670016 ( 0.3%)
origfaces 145/65536 8120/3670016 ( 0.2%)
leaves 67/65536 3752/3670016 ( 0.1%)
leaffaces 60/65536 120/131072 ( 0.1%)
leafbrushes 39/65536 78/131072 ( 0.1%)
surfedges 1314/512000 5256/2048000 ( 0.3%)
edges 728/256000 2912/1024000 ( 0.3%)
worldlights 2/8192 176/720896 ( 0.0%)
waterstrips 2/32768 20/327680 ( 0.0%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 24/65536 48/131072 ( 0.0%)
cubemapsamples 0/1024 0/16384 ( 0.0%)
overlays 0/512 0/180224 ( 0.0%)
lightdata [variable] 451644/0 ( 0.0%)
visdata [variable] 284/16777216 ( 0.0%)
entdata [variable] 700/393216 ( 0.2%)
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
detail props [variable] 1/12 ( 8.3%)
static props [variable] 1/12 ( 8.3%)
pakfile [variable] 9906/0 ( 0.0%)

Win32 Specific Data:
physics [variable] 4230693/4194304 (100.9%) VERY FULL!
==== Total Win32 BSP file data space used: 5845835 bytes ====

Linux Specific Data:
physicssurface [variable] 14199507/6291456 (225.7%) VERY FULL!
==== Total Linux BSP file data space used: 15814649 bytes ====

Total triangle count: 372

Any ideas? Maybe I should start another post on the question of the limit.

The problem isn't with Hammer, and while the compiler is creating the errors, that's not really the problem either. I think the main problem is that you are making things which are just too complex for world geometry. Even if you were able to get it to properly compile without leaks, I shudder to think how nuts the VIS process would be.

In the long-term you should probably see what you can do to adapt your technique to displacements, since your technique seems to work in a similar way and displacements will probably perform better in the long term with a given number of vertices.

In the mean-time you should probably just make all of your cool stuff into func_detail brushes. That way the compiler won't cut them up, since func_details are ignored during that step.

Either way, you shouldn't be using your shapes to seal the level. Make some large, simple brushes and put them behind and/or inside your shapes to do the actual VIS blocking and level sealing. You can even make them nodraw and they will still seal the level.