ok, so, apparently i was doling it ALL wrong... and cap helped me out with that part by getting rid of the hint brushes, but now, as alot of people have said, the map is really choking on FPS in some areas... most of the map actually, and i have NO clue how to get better FPS on it... the other problems i can deal with, but the optimizing thing ive read up on, and cant figure it out at all. anyone able to help me out?

Can someone help me out also, please? I have no idea why there's a major FPS drop in parts of my map. Thanks

On the valve development wiki and as well as some other sites, there are tutorials on using hints appropriately. Yaknow the whole splitting-visleafs-and-rooms-apart thing that makes sense but seems like alot of work. And then some places just say to use one or two main hint brushes and thats enough, depending. When I load up dod_flash it seems they took the simple approach, with one hint plane slightly above the players head throughout the whole map. It seems like flash used area portals as the primary optimizational method - sectioning off each "area" boundary with areaportal planes.

Few hints, lots of area portals and appropriate use of func_detail and nodraw? I don't know if its that simple but I like the way that sounds.

I do agree that areaportal are very usefull. I remember when trying them at first I was getting thing all wrong. I think i did write a tutorial back then on our private forum I will see if I can find it. With then I can make whole part of my map in work disappear and still not using one hint in my map.

But areaportal can be tricky as well. some are server side calculated and can in some case create lag. But the are areaportalwindows that I think are calculated client side and will affect a lot less in multiplayer. They block brush but not props. Having many props then you need to have some ocluders to hide somes.

Now it really hard to help out unless we have access to the original file. This way we can try stuff, complile ends test FPS. If you are willing to share it then I can take a look at it. Not a pro in mapping but I did read a lot on optimisation and being a programmer I guess I understood stuff up to a point. No one really can nail it right on the button but I do know what to look for.

Anyway if you wish me to help you out let me know.

If you do want to share the vmf file make sure you add any custom content in it before sending it to me so I get to have ecverthing needed.

I will be busy until saterday night since Friday I have a alpha test on valve admin tools. But I will have free time after that. More so if the test go well :)

Pan... Not that others here won't help you, I'm sure they will! But you should really get in touch with Fuzzdad - PM him a link for your latest build and see what (if he has the time and gumption (*sp)) he can find that would help out!!!

Another thing that you may want to look at as it did increase my fps is your models.

Have you set the max and min fade distance on your models because if you have just placed them from new the game will draw them regardless of where you are in the map and whether or not you can actually see them.

If you bring down the console and type +showbudget it will give you a graph that shows how much resource different things are using. I know that before I went through what was a very long process of setting the fade distances on every model, my machine was maxing out just trying to show all the models where as everything else was fine and that was without any optimisaztion.

May be worth a look.

But hey i'm just a noob and like you just cant understand this optimisation regardless of how many times I read the tutorials. Hints don't seem to achieve alot and had no luck with area_portals as no matter what I do I get error leaks when compiling.

Seems to be a trial and error thing because as you say you can decompile 6 maps and every one will be optimised a different way.

The most anoying thing is that one (and i'm not going to name it) has no optimisation and is similar in size and detail to mine and runs sweet as :angry: :angry:

Yeah its annoying isnt it :| I just turned off entities and compiled to see what difference it made. I went no lower than 80fps, averaging well over 100 (from a low of 25 to a high of around 60). Obviously the only optimising I now need to do is with model fade distances, I do have a lot of models in the map and Ive only set the fade on about half of them, so its gonna take a while :D

I set the fade distances on a load of models in a particular closed in area so they were all JUST visible at the right time, and I gained 20 fps at least.

The single most effective ways of optimisation are:

- Vis Blocking! Its the way to go baby!
- Making non-vis blocking and complex brushses func_detail. In fact, if a brush is even the slightest bit complex, make it func_detail and block it off with another brush textured nodraw behind it!
- No Draw texture on non-visible surfaces.
- Removing unecessary props
- Setting fade distance on props correctly
- Placing a hint brush along the height most walls come to (try to make as many walls as you can come to this height when making the brushes in the first place). Make sure the hint brush is above player height and that there isn't too many locations where the player comes above this brush.

Then theres:

- Placing hint brushes CAREFULLY across door entrances, and to seperate areas. Since most maps don't have long hallways, I won't go into the depths of angled hint brushes, etc but the typical open map hint brush placements:

http://dodnetwork.com/el/hints.jpg

- Placing areaportalwindows over the windows

- Place area portals in doors (they must seal the door - remember dont put against a func_detail)

I would say take a look at Flash but I really don't have any idea why half of them are really there. I'm talking about the func_occluders here....I think they have something to do with locations (%l) but am not exactly sure!

El Capitan maybe you can answer this question for me.

If you optimise your map and compile it with BSP = Normal VVIS = Fast and RAD = Fast does the compile take into account the optimisation you have done, or does it only take it into account if you have the settings set to VVIS = Full and RAD = Full.

The problem I seem to have is if I set VVIS and RAD to full the map takes forever to compile with my processor maxed out. When my map was half built I tried this and after 10 hours it had only done 50% of the lighting.

Bit concerned it could damage my pc and the map aint worth that would rather play with crap fps.

p.s. My processor is AMD 2800

p.p.s You say about putting area portals in doors/windows but the problem I have had is that if I have a house which you can enter by two doors with say five windows you can look out of and I seal each of these with an area_portal I still get a leak error?

1. I think Vis and Rad would take into consideration optimisation, although I'm not sure. You should NEVER compile a final version of a map on fast settings. If you are worried about your computer, just send it to me and I'll compile it for you although it won't damage your computer, I can tell you that much!

2. Make sure the room is completely sealed. Displacements don't seal. Make sure you have sealed all windows as well and other holes into the room! Load the pointfile and it will tell you where the hole is if its poor brushwork.

Rad is for lighting, it couldn't care less about optimization. VVis and VBsp is where it's at.

Thanks for that guys appreciate the offer and I may take you up on it.

Is there any guide as to how long it should take to compile a map and I know that it would obviously depend on map size etc, but you here about "doing this will save hours on compile time" but typically how long should it take.

For example my map currently when compiled with RAD = Fast and VVIS = Fast ends up at about 18Mb with no optimisation and as far as size is concerned is maybe a bit bigger than Donner.

So when I did do it with optimisation when half built and it took ages and maxed out my processor was it because of my noobish poor attempts at optimisation or is it to be expected?

By the way if I bring up Windows Task Manager even when doing a fast compile it tells me that Hammer is not responding even though it's running fine. Is this unique to me or does anyone else get this. As you can appreciate if i'm doing a full optimised compile and bring up Windows Task Manager i'm going to get the same thing and as it's not obvious due to the time it's taking i'm not going to know if it is still compiling or has crashed :confused:

Even though hammer appears to not be responding, its fine. Its vvis.exe and vrad.exe you need to worry about in "processes" - If you don't plan on using your computer whilst compiling (which isn't recommended) right click on them when its compiling and set the priority to above normal or high. It will compile quicker as it uses more CPU cycles.

Rad doesn't take into consideration the optimisation as such, but it uses the data that vvis produces. If you are running vis on a fast compile, you will get less light bounces and lighting won't be as good.

18mb sounds about right for an average size map on a fast compile. This file will be much bigger on a full compile as it holds more vis data, however.

You can never predict a compile time based on map size. It solely depends on what is a func_detail, how complex brushwork is, how open the map is, the skybox, the lighting (light_spots, dynamic lights, light_environment, HDR, lights) and all sorts of factors! It also depends on your computer specs, mainly the CPU and RAM.

Some maps take 30 minutes, some take 12 hours+ - Its the way of compiling!

Also, if you are unsure how to use hints, occluders, areaportals, etc properly then leave them out. More often than not you can end up causing more damage. When I looked through panfries map pretty much all the hints that were placed were incorrect and would have caused FPS decrease and longer compile times. He had the right idea though, and with a bit of learning you can find them to be very useful!

I must admit I am tending to lean in that direction to be honest as we have play tested my map and the fps isnt that bad compared with the official maps.

I have tried sealing my buildings that you can get into with area_portals but keep getting an error on one brush "Brush 730704: areaportal brush doesnt touch two areas" and I just can't see for looking why I am getting it, and as this is only the second building out of about eight that you can get into it could take some time.

As you say its a learning curve and as it's my first map maybe my brush work wasnt what it should have been to start with but you learn as you go :mad:

However the map itself has had a great response during playtesting and plays well so maybe I will release it as a beta without any optimisation and see how it goes. You know what its like you want it to be perfect but it is my first attempt.

My only concern with doing that is the compile time if I do a full compile with no optimisation which I haven't attempted as yet :(

To be honest, adding in hints, areaportals, etc shouldn't really affect compile times greatly at all. I wouldn't worry about optimization at all, only as a last resort if people complain about the FPS!

I dont know if this will help,

You will get alot more people complaining about your map and its low FPS if you don't do a FULL compile, a fast compile doesn't calculate VVIS at all, it just draws everything, thus crappy FPS.

But the more complex brushes etc you have the more "CUTS" VVIS makes when compiling your map. You can reduce the time of compiling a map from 14 hours down to 3 or 4 just by changing your complex shapes (brushes) into func_detail.

By this I mean, Rooftops if they aren't displacements, curved shapes, triangular shapes, footpaths etc etc if it doesn't need to block visibility then make it the brush a func_detail (you do this by pressing CTRL+T, if you didn't know how)

When VVIS compiles your map it makes 3d Boxes based on the Brushes that surround it. It then calculates which 3d boxes can see each other and thus draws what is around the player and not what is on the other side of the map.

Anyway there are plenty of sites that could probably explain this better.

Just make sure you do a FULL compile before a release, I would suggest forgeting about area portals and just work with changing your complex brushes into func_detail and changing every models start and end fade distance (that way the game engine wont be drawing a window frame on the other side of map that you cant even see).

Have fun

Originally posted by TOP GUN Mav
You will get alot more people complaining about your map and its low FPS if you don't do a FULL compile, a fast compile doesn't calculate VVIS at all, it just draws everything, thus crappy FPS.


A fast compile on VVIS does calculate vis, its just very basic and only makes one pass. Without any vis calcs, Rad wouldn't work.

Well thanks to the advise you guys have given me I think I am going to go with no optomising and see what feedback I get regarding fps.

Just one question regarding func_detail.

You say make any complicated brush that doesn't block visibilty func_detail. What I dom't understand is that most brushes block visibilty to something so how do you decide what to make func_detail.

i.e. if you have a house made from solid brushes in other words a house you cant enter do you just make the roof func_detail or is there any point in making the walls func_detail as well ? Is a func_detail solid or can you shoot through it?

I have made most of my roofs and footpaths func_detail already but I have a suspicion that my compile time was very high as I had part optomised my map which was probably confusing vvis and making the compile time very long

Detail brushes act exaclty as world brushes,they have collision,lightmaps and stuff but they just dont cut the vis nor the world brushes.

Ill draw some stuff tonite to explain how it could be used effectively.

Originally posted by [SAS]==Dirty_Harry
Well thanks to the advise you guys have given me I think I am going to go with no optomising and see what feedback I get regarding fps.

Just one question regarding func_detail.

You say make any complicated brush that doesn't block visibilty func_detail. What I dom't understand is that most brushes block visibilty to something so how do you decide what to make func_detail.

i.e. if you have a house made from solid brushes in other words a house you cant enter do you just make the roof func_detail or is there any point in making the walls func_detail as well ? Is a func_detail solid or can you shoot through it?

I have made most of my roofs and footpaths func_detail already but I have a suspicion that my compile time was very high as I had part optomised my map which was probably confusing vvis and making the compile time very long

Decompile the official maps to see what should be func_detail or not. A lot of the time it's just extraneous brushes that add detail to the basic map geometry (hence func_detail). So, for example, a building is just a big cube type shape and a couple of extra func_detail brushes to make it less cube-ish. Those func_detail bits have (or rather, would have, if they weren't func_detail) very little impact on visblocking compared to the basic cube shape of the building itself. That is one type of func_detail that you see a lot of, but there are others.

I have one question though -- okay, making things into func_detail will lower compile times, and change the way the leafs (leaves?) are made (by not cutting up geometry, plus lower the leaf count). But does it actually have a positive effect on fps? It seems like if there are more leaves, then the engine would be able to calculate more accurately what a client needs to render. However, I realize many of these leaves are redundant and don't have any purpose. The question is, does the extra leafcount have a greater negative impact on performance than the occaisional benefits of more accurate vis-blocking/rendering? I'm guessing it does, but I just wanted to ask the pros. Hope that is understandable... :p

Zook, func_detail doesn't block VIS, and therefore doesn't cut vis leaves. That's their purpose. In that sense, they'll ALWAYS be a help for performance as they are to be used on small brushes (detail brushes as you so clearly put it).

Seen as it doesn't block VIS, the question is not whether the engine would do a better job by giving it as many leaves to decide with as possible, but more "Do I want the very same scene to be rendered with 10 or 100 leaves". And that's because Vis does a very poor job to start off with, which is where one needs to start telling it how to do its job (i.e. with hints)

Simply because the big world brushes that form your building will always be considered by VIS whether you func_detail your map or not. The rest as you put it is redundant faces, which are always cut into triangles. The more triangles one needs to render the worse it gets, it's the same principle for models and their poly count.

Keep It Simple Stupid (aka KISS) definitely applies to a map's architecture. It's all an illusion though, a good mapper will add layers upon layers of detail on a very rough skeleton.

more leafs = more CPU times sorting them :)

The engine "prefers" having a few leafs with many entities and faces than many little leaves with a few entities and faces in them.

It has a real impact on fps.
check the CViewRender bar on the +showbudget dev table.

Hey, thanks. Hmm, while I'm thinking of it, anyone know about lightmap scales and their hit on performance? I don't know if any custom mappers have even toyed with this tbh, but a lower lightmap scale on a texture/surface is supposed to make lighting and shadow effects look better/smoother. However, compile times increase quite a bit I'm told.

http://developer.valvesoftware.com/wiki/Advanced_Lighting

Also, lower numbered lightmap scales create more "patches" -- there is a limit to those that you can go over. But disregarding that, does anyone know, for sure, if there is a performance hit with high resolution (low number) lightmap scales? Because it'd be nice for a final compile to lower the lightmap scale for a lot of prominent surfaces to achieve very high quality lighting, as long as the fps hit wasn't big. The compile would take ages, but the quality of lighting would be great. Anybody know if there's an fps hit?


Originally posted by Furyo
Zook, func_detail doesn't block VIS, and therefore doesn't cut vis leaves.

Ah yea I know -- I worded that wrong. Reworded previous post. ;)

Dod maps usually dont have a really important contrast between dark areas and lit ones. execpt a few places like sniper nests etc...

I usually use 64 as default scale then I turn all the receiving shadows faces at 16 or less if needed.
This is tricky and takes time,you can end with a odd looking map.

Good candidates for sharp lightmap scales are; ground surfaces,arches (or they go mad and each face of the arch gets a different shadow intensity.

Also using lightmaps at 64 lowers the bsp size and reduce memory usage you can check that in the +showbudget_texture or something.

For a bsp thats about 25mb,tweaking intelligently the lightmaps can reduce its size up to 15mb or to 20mb.

I'm curious about this 64 value, the default being 16. I guess my question is why 64 and not 32 or 128? Is it just a good medium value?

I haven't played with lightmaps yet, and from the looks of it I could have on Dijon. It's just one of these things I still need to learn more about :)

My philosophy was that 16 was a maximum and to get even better effects, one could get down to 8 or even 4, for example for a very nice skylight sun beam

I'm quite sure there is no performance hit with lower values on lightmap res.

The downside is just larger file size (longer loading times) and longer compile times.

:)

Furyo,64 is fine because its large enough,it still get some variations on large surfaces unlike the higher ones.

Like we say in France;dont spend your time f**k**g the flies ;)

They really say that in France? LOL

Is this regarding light entities that you place through a map?

Also, love the light on Furyo's church in Dijon -- were these done with a light beam entiity?

Volumetric lights:

http://www.akilling.org/akg/tutorials/wiseVol.asp