Need help with optimization Created 12 years ago2012-02-21 20:54:41 UTC by Azin

Hi,

I'm having trouble reducing my w_polys, and after reading every fairly available tutorial on optimization and hints especially I have come to the conclusion that I really need to bug all of you competent mappers with my pity situation.

I've been working on a relatively small map for the past two weeks, one of them intensively during a week-long break. The maps is a recreation of an earlier version, which was much more messy and full of bugs, created before I knew much about optimization.

The problem(s):
-I have up to around 3500 w_polys being rendered at times
-Most of the map is showing at all times.
-I use a relatively big amount of transparent walls (windows/glass), making hint placement extremely difficult, at least for me.

I don't know if you would categorize it as a problem, but I am very reluctant to changing the layout of my map. Therefore I am left with basically just the hint option, which however, should be able to do the trick, afaik.

Here are images of two spots in my map incl. an oveview:

Thank you very much!

If any of you would want to have a look at the .rmf, please pm me
-Azin

Wow gorgeous pics sir! The second one made my jaw drop.

The only way i can think of would be to make the windows opaque world brushes. Have you experimented with hints at all? (i've never been able to make them work)

3500 for a map of this size/complexity is no that bad. I think you can also boost wpoly by reducing texture scale? If so, it's just another trade-off: wpoly for prettiness.

It might be a fun to host a mini-mapping-competition out of this map or another one with tough optimization, and see who could get the wpoly down the lowest? =)

Haha, I hope you're talking about the bad numbers on the left corner - I wouldn't want to disappoint you

I always heard that 6-800 is the magic number in w_poly? I am running it fine at >3500 though, so I guess it's not that bad, but lowering it would be nice.

I don't want you, or anyone else, to put too much work into this. The map is made for a few of my friends who would like a cs version of a real location, so that's basically why the layout can't be changed. I already spoke with this guy, fr33pr0d from cstrike-planet who suggested that I made a solid wall in front of spawn, keeping the player from seeing all the way to the other side of the map. I guess that might be one of the things you could do, as of changing the layout.

Hints didn't really work out. I might have been able to hide some of the glass in the ceiling from being seen where it shouldn't be possible with hints, however that might just as well be caused by vis being rendered full rather than fast as I did before.

So, if you're up for it, go ahead and mess around with it. If you come up with something ingenious, I might change it to that. Just keep in mind, that I'm overly critical about it. I just don't want to waste your time, that's all, really (I've sent you the .rmf, I might also just upload it here later)

6-800 is a software mode guideline from 1998. I don't think it applies anymore.

Shrink the density of detail. Make the pipes with less sides. Scale up textures somewhere (for ex. grass). Use NULL. Use -subdivide 256 on BSP. You can't do a lot because your map is very open.

Anything above 2000 w_poly would be too much for cs, Have you put bevel texture on all invisible faces? have you used func_wall or seperated objets by 1 unit to prevent them from cutting each other in your map?

You can use func_detail, separation by 1 unit tech, cut map into sectors with sky box method...

Try the first 2.

I have used NULL on every face that can't be seen, except for glass, as I was worried it might mock it up. I have also used func_wall on a lot of stuff, but not on walls and similar thigns, separating rooms and such, basically I have just used it on on details like chairs, bookshelves and complicate stuff like stairways and pipes. I have also separated the func_walls down to it making sense, like adding each but the whole of a chair to a func_wall.

What is the -subdivide 256 and sky box method? Does the first one have something to do with texture/brush scale?

So I'm on a bit of an optimisation course at the moment with the TFC map I've been working on for a while - anything above 2000 wpoly seems to be an issue due to the explosive nature of the game, so I'm trying to cut back a bit. I'm currently testing the effect of nodesizes on the map but I'm also curious as to what -subdivide does? The ZHLT page hints at it possibly decreasing r_speeds but with potential problems..

Also, with covering unseen faces with Null, am I right in thinking the main gain from this is it removes intersecting faces that would otherwise cause csg to cut up a brush because most of the faces the player can't see are removed in the compile anyway? Would making these bits into func_wall have the same effect so long as they weren't important VIS blockers?

And while I'm here I may as well ask about the HLRAD -maxintensity number to save a lot of trial an effort.. What kind of value would I be looking at here, 100s (like standard light), 1000s (like texlights)?

Cheers

I have used NULL on every face that can't be seen, except for glass, as I was worried it might mock it up.

There's your problem. Use BEVEL instead of NULL, and for floors use sky rather than NULL or BEVEL.

I remember reading about the difference between those three, and the conclusion seemed to be that the difference wasn't really that big. I doubt it's a real issue on my map, unless the difference between NULL and BEVEL has something to do with blocking vis. I base this on the fact that my problem isn't that I have too many faces overall; it's that too many of those I have are being rendered when they shouldn't be.

In case I'm wrong about BEVEl though, and it has to do with the compiler figuring out when to render stuff the way I pointed it out, then please let me know, and I will try using it and SKY instead of NULL

And smellycat, I don't know about most of what you're asking, but about the func_walls: I guess the point is exactly to use that on things that aren't important in any way for vis blocking, like details and small complicated things, again, unimortant for vis. The point of using func_walls is to avoid brushes being cut into smeller bits at intersections.

However, you have to keep in mind that since it doesn't block vis, it all will be rendered, so you want to use it on small complicated stuff, that otherwise cuts up it's surroundings (Remember the 1 unit method as an alternative to func_Wall). A general rule is to never use it on actual walls, ironically.

Also, the way I've come to understand it, the engine just renders the func_walls as epolys instead of wpolys, so don't turn things into func_walls if you don't have to.

So to answer you question: I think the MAIN reason for using NULL is to avoid rendering faces that you can't even see, but I guess also, as you point out, to avoid those faces cutting up things (I'm not really sure if it's actually the edges that cut things and not the faces themselves though?). So no, you won't gain the same if you add your object to a func_wall, as the whole object will be rendered, and that as epoly instead of wpoly. What's better is up for you to decide in the specific situation.

I'm still pretty new to the whole optimization though, but hopefully you will get a reply from someone who actually knows these things for sure.