BSPC (compiling SP bot file) after q3map2

(kat) #1

I’m in the middle of another RtCW SP map that’s basically a cave system built using the quadsouping method outlined by sock (works well by the way Mr Brushmonkey…!) and I’ve come accross and odd ‘issue’ that I’m not sure how to resolve or what’s causing it in the 1st place.

For some reason BSPC compiles after using q3map2 are taking a massive amount of time to process, several hours infact rather than the ususal several minutes (it takes ages to run through the “depth first BSP building” part of compile running into a 7 figure number ‘splits’ - not sure if this is good or bad.?!). So far as I can tell nothing unusual is present in the map except for the some use of the new terrain blending techniques and a few ASE models that are cliped using brushwork and not from a shader.

I’ve tried various compile versions - no entities, no models, no clips, just brushwork etc and it still take ages regardless, I just can’t think that the brushwork is that complex that’d it’d be taking so long to compute the AAS data… anyone got any ideas of things to try on this one?

[EDIT]
snipped from bspc log

depth first bsp building..
1569130splits
169328 KB of peak total bsp memory
BSP tree created in 10349 seconds
------- Prune Nodes --------
1524776 pruned nodes
---- Node Portalization ----
 44355 nodes portalized
  3300 tiny portals
  9018 KB of portal memory
 20584 KB of winding memory
------ FloodEntities -------
------- FillOutside --------
13323 solid leaves
 3528 leaves filled
 5327 inside leaves
  5326 areas created
   869 face merges
  1355AAS_TestSplitPlane: tried face plane as splitter
  1549
    28 face merges
  3236 areas merged
  6018 nodes pruned
  3640 areas checked for shared face flipping
  3640 areas checked for shared face flipping
  8837 face merges
   153 plane face merges
     0 ladder subdivisions
 13567 edges melted
  3640 areas provided with settings
allocated 6 MB and 117 KB and 604 bytes of AAS memory
  3632 areas stored

AAS created in 10358 seconds
loading collision map...

[snipped]
a couple of screenies

showing the basic brushwork and how high it is

showing the extensive monster clipping going on to reduce waste to the min

(kat) #2

I figured out what was causing the problem; some really badly placed Cluster Portals - they had been cut up in an attempt to make them fit the profile of the terrain better, not a good idea as this then goes on to create a massive amount of extra ClusterPortals splits relative to each individual brush … kicks self in nuts as a reminder NOT to do it again

(QESTUDENT) #3

Your post is, I think, almost harmless. :banana: