[SOLVED] Reducing Planes on a Map

[Slav K***ht Gael]

Hi everyone, I was wondering how to best approach reducing the total planes on my map.

I'm up to 70% at the moment with hopefully quite a bit of work left to do, and it's been a mostly gradual climb up to that point. My map is relatively complex with world geometry/func_details, but isn't especially detailed/expansive yet.

Other factors like waterindices have a lot of documentation already on what they are and how to reduce them, but I couldn't find much info on how exactly planes are generated.
From what I've read it seems pretty rare to run into a worrying amount of planes before something like waterindices or brushsides. I do have some info about my map that might be pertinent.

I haven't used the torus, sphere, or carving tools.
I've done a decent amount of vertex editing, but with pretty simple shapes. Having been compiling often I haven't seen much of an impact.
I have a few examples of pretty complex world geometry and func_details, some I successfully turned into props with Propper, others were unable to light properly/generate a shrink-wrap collision model. Hiding the worst example reduced planes by 6%, good but not the number I'm looking for.
I have no complex displacements, hiding all had no effect on planes.

Does anyone have tips on how to reduce planes on maps? What exactly are they individually? Thanks!

 

[worMatty]

A plane is a flat, 2D surface which is infinitely long in either direction. Faces create and occupy these planes. Where the tool limits are concerned, each face is actually responsible for the creation of two planes. Multiple faces may share a plane if they are aligned with each other, even if they belong to different solids. In that case, no additional planes will be created. If you put two platforms along side each other at the same height, their tops would be on the same plane.

So to reduce the number of planes, you can:

1. Reduce the number of faces, and

2. Align as many faces as you can with other faces on the same plane.

Practically, option 1 will likely have the greatest impact and option 2 is unlikely to be possible. Continue to use static props in place of complex geometry.

https://developer.valvesoftware.com/wiki/Valve_Map_Format

For static prop lighting: If you haven't already, investigate per-vertex lighting on static props. Alternatively, you can try lightmaps on some props if parts of their textures are not repeated on the same prop.

For static prop shrink-wrapping: Try building your own collision mesh using a func_brush textured with toolsclip and specify it in your Propper entity properties. Collision meshes can only have something like fifteen sides, after which they will become simpler and probably not what you want. I'm told that when you create a static prop normally you can specify multiple component concave solids to use as the collision mesh, to spread this limit out. Propper may allow you to do this by using multiple func_brushes with the same name. If it doesn't work, you may need to split up the model or investigate another method of compiling it. Or just don't compile any collision if it doesn't need it, and use some toolsblockbullets2 brushes.

 

[Slav K***ht Gael]

So to reduce the number of planes, you can:

Thanks! That makes a lot of sense as to why I have so many planes, a lot of my trimming/decorative geometry I have is not actually aligned with the walls they're attached to. I'll definitely give turning some of this geometry into props another try with this info too!
One small problem unrelated to this thread I had with Propper is sometimes it seems really darken certain textures on the prop, even when the prop itself lights up fine. Is there a way to get around this?

 

[Cyberen]

Since you already know about Propper, I'll answer your last question. It's important to recalculate face normals in Blender before exporting models in case there's any odd darkening. Failing all else, convert the texture to unlitgeneric.

 

[worMatty]

One small problem unrelated to this thread I had with Propper is sometimes it seems really darken certain textures on the prop, even when the prop itself lights up fine. Is there a way to get around this?

VertexLitGeneric materials do look slightly different to LightmappedGeneric but they should not look darker. If a static prop is too dark, that suggests it's not receiving sufficient illumination. A common cause of that is that the prop is being lit using origin-based lighting, and its origin is hidden by a brush or buried in one. I would need to see some examples and judge them on a case by case basis to give any more info.

Failing all else, convert the texture to unlitgeneric.

That would make the prop fully bright, which is undesirable.

 

[Slav K***ht Gael]

VertexLitGeneric materials do look slightly different to LightmappedGeneric but they should not look darker. If a static prop is too dark, that suggests it's not receiving sufficient illumination. A common cause of that is that the prop is being lit using origin-based lighting, and its origin is hidden by a brush or buried in one. I would need to see some examples and judge them on a case by case basis to give any more info.

Thanks for the responses.
I have here a couple examples of the simple repeated details I turned into props. Within hammer the textures are also slightly darker - but I put some of them in a compiled map here side by side.

Here on the right we have brushes that were used to create the props.
In the middle we have these brushes turned into props with Propper. I have vertex lighting enabled and -Staticproplighting used in the compile. I've tried a variety of different VRAD options but none changed this dark texture.
On the left I have the same props but with their lighting origin pointing to a nearby info_lighting.
None of these brushes are touched by the shadows of anything outside of the screen as far as I can tell.

From what I can tell it seems like Propper is just darkening the textures themselves since it's also a bit darker in hammer, but I have no real idea why if that's the case.

 

[worMatty]

That is indeed rather strange.

Would you mind doing the following for me:

Use CompilePalX to compile your map and have it pack the model files in automatically. Use the same compile settings you used to make the map in the screenshot.
Upload the BSP here along with the VMF in a zip. I will see how it looks for me and if I can spot anything wrong.

 

[Slav K***ht Gael]

That is indeed rather strange.

Would you mind doing the following for me:

Here you go, thanks for the help!

Edit: I've been looking around but haven't been able to find an answer for this either. I got CompilePal shortly before you posted about it, but I recently noticed that it's skipping vvis entirely. It gives me the error tier0.dll is missing. I am sure tier0.dll is in the bin folder.
I've tried deleting the bin folder and verifying files, reinstalling CompilePal, and I'm using the completely unaltered "normal" compile config with vvis checked on. If you know anything about this problem as well please let me know!
CompilePal seems really nice I'd hate to have to go back to compiling/packing with hammer.

 

[worMatty]

I believe this is caused by the presence of bump maps on the original VMTs. Unfortunately static props cannot support bumpmaps and per-vertex lighting at the same time, so you can either have one or the other. The simplest solution is to remove the $bumpmap property from your prop's VMTs. Edit the propper_models to disable bumpmaps for any future compiles.

I was expecting you to include the propper_model entities in your VMF so I could see what settings you chose, but in their absence I modified the brush models and created my own to test. I've attached the VMF for you and suggest you have a look at their properties to see the format I used for the material and model paths, and naming.

tier0.dll is in Team Fortress 2/bin. If it's there, I'm not sure why CPX can't find it. Maybe it's misconfigured. I suggest you run hammer.bat then try reopening CPX.

 

[Slav K***ht Gael]

I believe this is caused by the presence of bump maps on the original VMTs. The simplest solution is to remove the $bumpmap property from your prop's VMTs. Edit the propper_models to disable bumpmaps for any future compiles.

I got CompilePal working so thanks for the help with that!

As for the props, I'm going to say the problem is solved. Your models look how I hope they would, and replicating the settings you used makes my Propper models work how I'd like. Thank you so much!
I also noticed you adjusted to origin of the props to near the edge of the model, is there a reason for this outside of easier alignment?

I later ran into a smaller problem where a larger Proppermodel I tested on is now adopting an unused texture once turned into a prop. I remember reading a thread on someone else with this problem a while back though so I'll keep doing some research on it.


Edit: Not sure if I should just make a new thread for this but I'm having an additional problem where my map's world geometry is now all compiling as pitch black. I spent all day trying to search for what I thought was the problem brush by hiding geometry and using cordon, because it would seem to randomly compile correctly.
Now I realize that simply removing a random large selection of func_details from the map seems to cause it to compile correctly. I'm not at any of the engine limits on geometry and only have zero child area patch/displacement edge abutting errors, all of which existed before this problem occurred. I could make the sacrifice and just remake lots of random geometry, but it doesn't make sense to me why this works, and I'm worried it would just happen again once I recreated enough.

This is not the first time this has happened, and the last situation happened at a similar time: just after using Propper to turn a complex brush into a model on my map. However last time just deleting the Proppermodel entity solved the issue, not the case this time. Both the Proppermodel and the prop created from it are completely removed from the map.
I haven't been able to find anything on a situation similar to this. Compiling with fast vis also prevents the pitch dark geometry.
In the future I'll bring brushes to a separate map before compiling them with Propper.

 

[worMatty]

I usually put the origin of a static prop somewhere that makes it easy for me to align it. If a prop should sit on the floor, I would put the origin at its foot in the centre. If it's designed to go on a wall, like a picture, I would put the origin at the rear face in the centre. If it's designed to be some kind of trim that fits on the top or bottom or a wall, I would align the origin with the top/bottom corner of the brush it's fitting onto. The idea is when you place the initial point entity in Hammer, you intuitively click where the model will go, and if you have chosen a good place for the origin, when you set the model path it will more or less be in the right place.

Note in the VMF I sent, I put your props in their own dir named after your project. This makes sense since they are specific to the project, as opposed to forming part of a more 'global' asset pack. One thing you were already doing which you should continue to do, is to put your Propper materials in their own dirs rather than have them all mixed together. This is because, if you need to set specific properties for a particular prop's materials, and it also shares a VMT of the same name with another Propper prop in the same dir, your changes will take effect on both props. So if you disable bumpmaps on one prop and then create another prop which uses them, and it shares a material with the latter, they will both now have bumpmaps enabled.

Not sure what's causing the prop to use an unspecified material. I believe there is a limit to the number of materials on a single prop, something like fifteen, but I'm not sure. Perhaps you should experiment with this.

It's perfectly fine to keep your Propper model entities in your production map, though I suggest you put them in a custom visgroup and keep them hidden when they aren't needed. Putting them in a separate VMF is also a good idea, so do what you feel works best for your process. Be mindful that when you move brushes around, their texture alignment will change, so for these entities it's wise to turn on Texture Locking (TL) when moving them.

Black geometry can be caused by a few things. I would need to see your compile log to point to any particular cause. The simplest is that your light_environment settings aren't right (e.g. it's pointing up rather than down), but by your description it does sound like it's being caused by a problematic brush. In my experience, using the cordon tool to narrow it down is the best approach. I start by doing half, then half again, and so on. In one recent case, my friend had a single solid that was part of a func_detail, and deleting the solid fixed it. His compile log had one hundred failed bounces in VRAD (the maximum number of loops it performs before it moves on). Fast VVIS was used and I cancelled the compile the moment I saw the failed bounces. I narrowed the problem down to an area 512x512, and had to hide individual solids. Took an hour but we got it in the end.

I believe 'displacement abutting multiple edges' can cause the compile to fail. You should fix that. Zero area child patch is not normally a cause of failure and no one on the web seems to know the exact solution (or is willing to share it). When creating displacement ground, you should only select the faces of the brush which will be seen (i.e. the top in the case of a hill, and the side in the case of a cliff). Sometimes an author will select the whole brush and create displacements from all six faces. When this is done to two neighbouring brushes which share an edge, the error will occur. Displacements can only share one edge with another, so if the top of the two brushes are displacements, and so are their sides, you will have four displacements sharing one edge.

Impressive work, by the way. Your map reminds me of Helm's deep. I can imagine it may make for some interesting games, depending on the mode(s). Given the fact you are using map-wide horizontal hint faces and func_visclusters I suspect you already know that displacements do not block visibility and you will need to create nodraw-textured solids underneath them to serve that purpose.

Good luck fixing the lighting issue.

 

[Slav K***ht Gael]

Good luck fixing the lighting issue.

Thanks for all of the advice, and it's not the first time the map reminded someone of helm's deep haha! I'll try to hunt down the displacement error.

As for the lighting error: I wanted to document this incase anyone else runs into this problem with black geometry after using Propper:
Copy pasting my map onto a new file fixed the issue. Using cordon seemed to simply not be solving whatever was going on: I could separate any section of my map, but as long as I cut out enough geometry the lighting would be fixed. I could have ~70% of my geometry loaded, cross the threshold with cordon that caused it to compile with black geometry, yet compiling with just what was included in that threshold would cause it to be fine until I once again included enough geometry.

Again copying the map seems to have fixed the issue. Wish I tried it sooner but I'm glad that's over with now lol.