Too many vertex format changes in frame, whole world not rendered

Ok there’s a build map I’ve been developing lately and I’ve been having a lot of problems with it. basically the console spams this error - “Too many vertex format changes in frame, whole world not rendered” - and parts of the map flicker. This only occurs when a large portion of the map is visible at once.

I know the error sound like I have to much detail, but after googling for a bit I found out that someone had deduced that the error was caused by having too many textures or something. I thought this sounded far-fetched at first but it does actually seem to have truth to it - I compiled the map with only 2 textures and the error was gone. After that I decided to try and reduce the amount of textures that I used in the map, which I did but without any affect.

Now, I know this error isn’t very serious since the map still runs fine and stuff, but it annoys me that other maps with more textures and more detail in the same area as mine seem to have no such problem, the console spam and texture flickering are an annoyance to say of the least. The map doesn’t even have much detail and I have done some optimization with hint brushes, func_details and func_areaportals.

Is there any way to fix this error? I really want to find a way to fix it because it ruins the entire map in truth, it could be so much better if it worked perfectly.

I was getting this error on one of my maps a few days ago. It was caused by having the bottom brush that seals my map from the void being textured with the Skybox texture, which was in turn being covered up by another brush that acted as the ground for my map.

So, I textured that non-visible brush with the Nodraw texture, and the error went away.

It seems that this error can be caused by a lot of things, and it’s not necessarily caused by “too much detail”.

can u post a screenshot of the 3d view of your map in Hammer?

Not everyone uses the same view port setup as you, I hope you know.

ok let me ask you some questions:

  1. are all those little buildings func_detail? If they’re not, make them all one big func_detail. I will repeat that: ONE (1) func_detail. Yes, I know it may take a long time to individually select them all, but do what must be done.

  2. I see that you have the skybox texture completely surrounding the map. Is the skybox texture also on the bottom brush which seals the map from the void? If it is, then make it nodraw.

Try both of these things, do a VVIS Normal compile with VRAD set to “no” and report back

Those are horrible optimization tips.

here we go again…

If you’re referring to the the “make everything func_detail” statement, tell me what’s wrong with that. I’ve said it before, and I’ll say it again:

The simple rendering of a world brush is so much more expensive than a func_detail, that the performance gains of having a world brush adjusting visibility is negligible. Not to mention, it takes hours longer to compile if the map is large.

A brush should be func_detail if it meets these qualifications:

  1. is not being used to seal the map

  2. is not being used to seal areaportals

  3. is not a displacement

  4. is not water

  5. is not some other entity (like func_door, func_illusionary, etc)

And of course you’ll probably respond with:

“But what about the visibility calculations for props that may be behind those brushes? they won’t get culled because the brushes are func_detail’s”

In which I will respond:

In situations like this, you should be using Areaportals and Occluders anyway.

Well to your last statement that wouldn’t work if you have those buildings as func_detail.

Also you should have only one rule for what should be func_detail: common sense based on an understanding of how it actually works. Those buildings shouldn’t be func_detail unless they’ve got windows meaning you can see out of them anyway.

Yeah I know and they do have windows, and I see that the OP is using areaportalwindows successfully. Also, this doesn’t contradict what I’ve already said: don’t make something a func_detail if it is sealing an areaportal.

in the picture, the ramps, sidwalks, curbs, columns, and buildings with doorways that are very large should all be func_detail. having so much “world” geometry (i.e., non-func_detail brushes) could be causing the “too many vertex format changes” error.

If he would just try it, it may solve his problem

func_detail is still rendered and has vertices don’t you know.


And making him func_detail all his buildings will cause more to be rendered, worsening his problem, not make it better.

You should probably also note that really, func_detail is for optimizing compile times, not in-game performance. Sure lots of visleafs will take longer to compile, but it’s precalculated, the cost of having lots of them in a map is only (from the players point of view) map size (and that’s not exactly massive)

Also brerben, you’re a little bit of a muppet, read your own rules, those buildings are sealing his areaportals, making the buildings func_detail would ruin that.

This. Your tip doesn’t fix the problem at all.

Ok I think my head is going to asplode…but would it actually help if I sliced up those roads and made them func_details, thereby hopefully reducing the amount of visleaves?

Pretty much anything that doesn’t really block visibilty should be func_detail.

Polygon for Polygon, func_detail’s are rendered cheaper than world geometry.

quoted from :

“All brushwork that does not form the ‘backbone’ of the world (and that is not tied to a real entity) should be detail.”

which is basically, most of the map if the map is mostly outdoors.

and as for the areaportal thing brushes, yes I agree with you to leave those alone and don’t make them func_detail’s, I just forgot to include that in my first post.

  1. Uh what? VBsp triangulates both in exactly the same manner, how can one be cheaper than the other?

  2. if you func_detail everything around the areaportals they will no longer work.

You’re forgetting that there are two roles to a “brush” in the BSP format: Its visible polygons (which stress the graphics card), and the brush’s function (which stresses the CPU)

In our case, world geometry (that is not tied to any entity) actually does have a function that will stress the CPU: it calculates (per-frame) whether or not things will be rendered if they are behind it.

On the other hand, if you tie that same brush to a func_detail, the CPU no longer has to calculate and use resources to determine if things behind the brush need to be rendered, and all you have to worry about are the visible polygons on that brush.

I have an idea.

Billi add me on steam, I’ll explain this to you so you don’t get confused.

What the hell have you been smoking? If you have a solid brush, the engine will draw everything behind if the visleaf is drawn. If you make everything func_detail it means that everything will be drawn thus leading to bad FPS.

Pretty much this.

Hurf derf.

What you are calling “brush geometry” is actually the function of an occluder. What do you think VVis does? Magically eat up CPU time because it can? Is it a madntory tea break creator? No.

It calculates what can and cant be seen from each visleaf, so since the engine knows which visleaf its in (it’s part of the map data) it knows precisely what to render, without having to work it all out per frame (that would be like running VVis once across your map every frame if you tried to get source to do it, you’d get precisely 0 FPS).