Engines with increased limits and mapping?

[damage_inc]

I was just checking out Daz's [ame="http://www.youtube.com/watch?v=ty_UVj3qc00"]video review[/ame] of Honey(By czg) and got to thinking...

... when you create a map for engines with increased limits do you even have to worry about r_speeds, vis and such?

That map is huge and detailed! I mean there's no using corners or blocking walls to help either! For the most part. I don't know enough to know if the "fog" helps in his map or not? I know in earlier games that was a way to help out rendering though.

So, can you basically create any amount of brushes and be fine? When using an engine with increased limits? Within "reason" of course. And reason meaning that I know increased does not mean limitless!

- damage_

[Spiney]

afaik...

BSP is slower to render than raw triangle data, but most systems nowadays just waltz through at the speed of sound so it's not really a limiting factor. It mostly depends on the quality of the vis and the engine support for huge maps. A simple fastvis might still bring things down if the map is heavy enough (the case of some Schism maps). Some huge maps just use fastvis since the vistimes tend to explode into several days even on multicore systems. If the engine doesn't support the increased limits well enough it'll fall of a performance cliff. Most important are increased BSP limits. Most popular engines support protocol 666. Then there's BSP2 which extends limits further. RMQe, DP nightly and FTE support those atm. Fitz might be in progress I believe.

About the amount of brushes mostly matters for vistimes. The latest TyrUtils support func_detail which splits the bsp but is ignored by vis. That speeds up vis times a ton. There's also the method of using func_wall which decouples the brushes. There's drawbacks to that though, such as no shadowing.

Ask GB or someone experienced if you need more info.