Brush limit for TDM.

[Bikerdude]

Following on from nbohr1more's comment -

Where did you get 14k as the brush limit? If that's confirmed in testing then we should add it to the limits wiki.

I found that figure after several days work & testing on the very large city map, when the map hit 33k it would instantly crash to desktop with malloc errors. had to get it down to 15k before it would stop crashing.

 

As Goldwell pointed out I have created other large maps that have gotten close to 33k but they were fine, so as Obs pointed out the conclusion is that the engine is splitting brushes at compile time exponentially increasing the number of brushes.

Edited April 20, 2018 by Bikerdude

[nbohr1more]

http://wiki.thedarkmod.com/index.php?title=Limits,_Max,_Min,_Stats,_etc

[Bikerdude]

Done.

[Springheel]

Is this system dependent?

[Obsttorte]

I wasn't able to find any specified limit in the code, so I would guess that the issue is only system dependent. Maybe the computer simple runs out of memory when dealing with that many primitives. Another explanation could be the following. All primitives are indexed with an integer. If the number grows too high you get an overflow (not sure on the name, been a while) and you restart with negative numbers. I am almost sure though that the limit is way higher with integers.

[Goldwell]

Is the limit really 14,000 brushes?

 

I've never heard of a brush limit, I looked through my release folders and found a few released maps with higher brush counts that aren't crashing:

 

Behind Closed Doors: 26,273 brushes

A House of Locked Secrets: 24,930 brushes

Penny Dreadful 3: 19,923 brushes

Requiem: 18,134 brushes

 

Even my current WIP has over 15 thousand brushes and doesn't crash.

[Obsttorte]

Another aspect that may play a role here might be the amount of intersections between the brushes and patches. They split up each other. Also, why are we talking about brushes only? It appears odd to me that there should be a limiting factor applied to brushes that isn't affected by the amount of patches used.

[Goldwell]

Another aspect that may play a role here might be the amount of intersections between the brushes and patches. They split up each other. Also, why are we talking about brushes only? It appears odd to me that there should be a limiting factor applied to brushes that isn't affected by the amount of patches used.

 

The only limit i've ever known about was the 7k entity limit. I've seen maps with as many as 10k patches, however that's quite rare as most maps have only a few thousand patches, usually under 5k.

[Bikerdude]

Behind Closed Doors: 26,273 brushes

Well spotted, it never occurred to me that these maps would be that big

Another aspect that may play a role here might be the amount of intersections between the brushes and patches. They split up each other.

Hmm, that could be whats happening in my case then - how do we check to see what the final brush count is at map runtime..?

Edited April 20, 2018 by Bikerdude

[stumpy]

doom 3 turns all brushes into flat surfaces, so a box in darkradiant becomes 6 flat surfaces when run in the engine, if a side has caulk on it, or nodraw, then it becomes 5 flat surfaces. eg visportals in darkradiant are a cube but in the engine its one flat surface.

[ERH+]

You are all talking about the number of brushes, but from my experience it is also related to the size of rooms - i.e. if you have a room 30k/30k in diameter it will run ok, but if enlarged to 50k it will start crashing (And it is not related to AI path finding - there wasn't any in area).

[peter_spy]

50 000 units equals roughly to 1,3 kilometers. Not sure how you would have to use this space to make something playable, and with high graphical fidelity, before hitting any performance limits first.

[Bikerdude]

Morning, I've updated the Op and wiki - with the new info in this thread.

Edited April 20, 2018 by Bikerdude

[Bikerdude]

You are all talking about the number of brushes, but from my experience it is also related to the size of rooms - i.e. if you have a room 30k/30k in diameter it will run ok, but if enlarged to 50k it will start crashing (And it is not related to AI path finding - there wasn't any in area).

How would I tell how big in diameter a map is, to see if it s that causing the issue for me atleast

[Bikerdude]

Hmm, that could be whats happening in my case then - how do we check to see what the final brush count is at map runtime..?

Any one got any idea on how to do this..?

[Obsttorte]

The splitting doesn't increase the brush count. Brushes are used as an intermediate representation for the map to be used in the editor. The engine works with BSP leafs and the tris contained there. So the splitting generates tris. I am not sure whether a high overall tris count could really cause a crash, as tris are rather small objects (the amount of data required to represent them is rather small) and you really would need a huge amount of tris to fill your main memory. You could compare the size of the cm and proc files to the ones in the fms mentioned above, though and check whether they are extraordinary high.

[Bikerdude]

You could compare the size of the cm and proc files to the ones in the fms mentioned above, though and check whether they are extraordinary high.

BCD -

• Cm - 78,961
• proc - 85,695
• Map - 46,159

SH WIP -

• Cm - 67,720
• Proc - 60,460
• Map - 41,973

The SH Wip is small across the board, yet crashes on compile. its only when I got this map down to 15k brushes it stopped crashing

Edited April 20, 2018 by Bikerdude

[ERH+]

wip SotL:

 

cm - 141,299

proc - 118,434

map - 68,035

 

packed map - 120,061

 

This version is playable but crashes if I just load saved game, but not if I start a new game and THEN load a save.

In attempts of optimising it came out that turning brush/patch func_static into .ase models cause even worse effects, precisely in dmaping crashing.

Edited April 20, 2018 by ERH+

[Bikerdude]

In attempts of optimising it came out that turning brush/patch func_static into .ase models cause even worse effects, precisely in dmaping crashing.

Im not surprised the map is crashing, its the largest one to date.

 

You can use the export to model function of DR 2.5.0, to get the numbers down (it noticeably reduce brush and entity count on my SH wip). Just don't do it on cylindrical models, as the export function remove the smoothing.

Edited April 20, 2018 by Bikerdude

[nbohr1more]

On a related note, I believe I did see a Shadow limit in the Dmap code. I thought it was only for pre-calculated shadows though.

[ERH+]

Im not surprised the map is crashing, its the large one to date.

 

You can use the export to model function of DR 2.5.0, to get the numbers down (it noticeably reduce brush and entity count on my SH wip). Just don't do it on cylindrical models, as the export function remove the smoothing.

You are not paying attention, I said brush-based f_s work better than .ase .

From the other side - same model in .ase format weighs 800 and in .iobj 109?? That sounds promising...

[Bikerdude]

From the other side - same model in .ase format weighs 800 and in .iobj 109?? That sounds promising...

Ah yes.

[nbohr1more]

I added entries about: MAX_SHADOW_VERTS and MAX_SHADOW_TRIS to the wiki.

 

It's unclear what they are limiting but it seems to be the number of shadow tris or verts a single model

can have when Dmapped.

[Obsttorte]

The vertices and tris the shadow frustrums contain of are stored in arrays of constant size. Those sizes are defined by those constants (and are fairly large). However, as I read the code overstepping those boundaries would cause the game to throw an error informing the user about the fact that those boundaries have been exceeded. So I guess it is unlikely that these are causing any issues.