that spikey map i was working on before was crashing most quakes with about 37000 clipnodes. 

large maps cause large problems... 

...this http://www.planetquake.com/fatty/default.asp?opinion=generaldesign might be of assistance 

After understanding "clip textures", and doing so, I found myself stranded with the same thing for animated ones. Sometimes they appear good in Quark, but after compiling not. 

Some BSP compilers don't automatically include all of the frames for animated textures in the BSP (wQBSP is one of the culprits, if I remember correctly). To get around this, you can use another compiler, or you can manually apply all of the texture frames in the animation into the bsp (by applying those textures to hidden faces somewhere in the level, eg on the back of walls which you will never see).

Of course, that may not be your problem, MadFox, can you give us more information? 

After finishing the Quatrotski map with texture clipping, I noticed the lava brushes didn't compare.
So I tried to match them in Quark6.3
After doing so, and compiling, they still went separate. 

why are you using quark? 

do I play Quake? 

...errr.. there is aonly a pub banner here... or there is a hidden "subliminal" message ??? 

I want to make it so that when you kill some particular monster, two more appear via teleport. I know that it involves the trigger_multible, but i forget how. 

Are you making an uber-terrain map if I recall? If you get a minute, what sort of clipnodes/marksurfaces are you getting on that? 

Start your teleported monsters off in a hidden box outside your main level. Make them stand inside trigger_teleports, but give the triggers targetnames, that way they won't teleport until triggered. Set up your info_teleport destinations where you want your monsters to appear. Have another monster target the trigger_teleports - when you kill him, the others should teleport in. You might also want to add a delay to that. 

...strange, it sends me to the fat controller's Q1 ladder tutorial.

*shrug* 

Are you making an uber-terrain map if I recall? If you get a minute, what sort of clipnodes/marksurfaces are you getting on that?


from my qbsp.log:

---- WriteBSPFile ----
8259 planes 165180
13898 vertexes 166776
6414 nodes 153936
292 texinfo 11680
11280 faces 225600
25868 clipnodes 206944
4035 leafs 112980
13603 marksurfaces 27206
50568 surfedges 202272
25692 edges 102768
43 textures 783216
lightdata 0
visdata 0
entdata 30840

I just c'n'p, 'cause I honestly don't know what it all means :P 

With my map I get:

---- WriteBSPFile ----
15103 planes 302060
26567 vertexes 318804
13760 nodes 330240
847 texinfo 33880
22945 faces 458900
44954 clipnodes 359632
5951 leafs 166628
28612 marksurfaces 57224
101267 surfedges 405068
50691 edges 202764
54 textures 1130160
lightdata 0
visdata 0
entdata 30754


Already, I can see the similarity with the high clipnodes/marksurfaces ratio, which is I believe a result of loads of triangle brushes. I'm currently covering as much as I can with clip brushes, which is having a dramatic effect with reducing clipnodes, although I have a long way to go before they drop below the magic 32,000. 

If you are using Dark Places anyway, maybe you should consider the Quake 3 BSP format. You are using Q3 textures a 1 to 1 ratio would look better too.

PS. I still fear the Vonder! 

you would not be able to use Aquire's tools. 

with q3map2 and all of it's bazillion features or whatever 

I haven't researched the idea of Q3 bsp in Q1 yet. Can monsters still navigate the same? i.e. are the clipping hulls the same?

As for Q3 textures, well actually they are the same scale because I resize them 50% before I do the palette conversion.

And yes, having to use totally different compile tools would be a headache as well (not to mention having to switch to GTK). 

Those stats are after I replace the valley floors of my terrain with large flat brushes, which reduced the clinodes cosiderably. 

Another thing I need to do though is isolate patches of terrain that combine to form convex shapes, and replace those with single brushes. That should reduce a lot of overhead if I can find lots of instances of that. 

you're going to need it ;P 

yeah - although I reckon if I go really crazy with the clip brushes, I can probably get the clipnodes under the limit. 

a general interest in me publishing a high-capacity WinQuake 1.20 variant similar to GLQuake 1.20? 

That would be cool. Winquake has many useful features lacking in GL, r_drawflat for instance.

Btw, something I've been meaning to ask you; I've been using -hull # in your bsp tool recently, and I've noticed that clip brushes are still invisible - is that intended?