Improving FPS of meshes -- general question

[syscrusher]

General question: I have a large complex house interior (base mesh and its contents of furniture and clutter) that I want to optimize for FPS. Given a finite amount of time, should I focus more on optimizing the collision mesh of the house itself, the visual mesh of the house itself, or those of my custom furniture and clutter objects? If polygon counts are equal, does the game engine spend more time calculating collisions or rendering textures?

Do the phantom lights really save CPU versus the "practical" light sources? If so, is it a large difference or incremental?

Thanks for any advice. I'm just looking to focus my efforts where they will make the biggest difference.

[Hanaisse]

FPS hits in interiors is negligible. Upon entering the cell everything renders once and that's it. Done. Unless you have 100 NPC's running around with constant AI.

That said, you will want to PyFFI all your meshes before you release.

[AndalayBay]

Over cluttering an interior will impart a performance hit though. I always mix real lights and fake lights to try to keep things runnng smoothly. The problem is determining what over cluttering means.

I've seen some good examples of this though. I'll have players who use my Imperial Furniture Renovated mod to clutter their homes. At first everything is great. Then they'll report that they're starting to see a performance hit. Basically they've added too much clutter. Ultimately they put up with it or move some items to another location.

One thing that was fairly easy to test is the miniature ship I created as a clutter item. It has a huge number of vertices because ships in the game are comprised of separate meshes. I combined all the meshes into a single mesh. I created a custom collision that wasn't too bad on the polly count, but I don't have the modelling skills to fix the mesh of the ship properly. On it's own it's not a problem. But if you place that ship in a cell with a bunch of other clutter, you'll see the drop in FPS. I found I could see the hit when I had the ship and about 6 other statues, plus furniture in a cell. There were quite a few furniture pieces as well.

So it's hard to quantify, but there is a hit if you manage to put enough stuff in a cell. And I've seen all this without any NPC's in the cell.

Edited May 4, 2011 by AndalayBay

[syscrusher]

One thing that was fairly easy to test is the miniature ship I created as a clutter item. It has a huge number of vertices because ships in the game are comprised of separate meshes. I combined all the meshes into a single mesh. I created a custom collision that wasn't too bad on the polly count, but I don't have the modelling skills to fix the mesh of the ship properly.

[AndalayBay]

That would be great! Thanks! I'll send you a pm with the mesh and textures. You could download IFR - link is in my sig, but all the resources are in the BSA, so that would be a bit of a pain.

I was able to see the change when I did the last update to IFR. Basically I was using Battlehorn Castle as my testing area, so I would buy all the items I had added and place them in the main hall. Since I was running back and forth and adding more and more clutter, I could see the impact on the frames. There are a couple of NPC's there, but they would come and go. Basically it was a fairly good environment for seeing the impact.

I had purchased all of Loth's weapon racks and filled them. I also had a bunch of statues, rugs, tapestries... But it seemed to be the ship, miniature lighthouse (yes I have one of those too ) and miniature priory chapel that really seemed to affect the performance. Now in my new game, I've just got a few pieces of furniture and the ship in the IC shack and that's fine.

So yeah, it appears it's important to test your house in-game as you add clutter and see how it's doing.

[Hanaisse]

Just out of curiosity, what gauge of impact are we talking about?

[AndalayBay]

I didn't take actual FPS measurements, but the stutter was really noticeable. After testing I went back to a previous saved game and things returned to normal. I still had some stuff in the great hall, but during testing it was filled with statues and furniture. I also don't get a lot of complaints (about IFR) from players. I've just had one or two admit that they noticed an effect after cluttering their houses with a lot of stuff.

I do think you have to clutter a cell by quite a bit, but it's hard to quantify.

[DarkRider]

Not on this rig but on my old rig (which was toward the mid low end) the performance hit in an over cluttered interior could be dramatic, especially with using certain objects like lights, havoked items, and items with transparencies like ivy. Normally I had about 50 fps in an interior cell, a single house interior with lots of ivy, crippled my fps to 1 (true story )

It was in RST's early days that I learned about light objects/static objects vs static lights. Lighting Sancre Tor is a big job, especially with ambient lighting at a minimum. Takes a lot of lights to light those nooks. The first cell I reclaimed, I used about 40 light objects and was getting between 6-10 fps in that cell. Swapped them out for static candle objects with non-flickering light objects and fps went up to 35, cutting that number down to about 20, brought my fps back up to it's normal 50. It's not a lesson I easily forgot as there was a lot of testing to get something playable on my rig that still looked decent. I could enter some cells and just know by the fps hit that too many lights were in that cell.

I'm not saying this is canon, I'm sure for many folks it's not a difference one way or the other, but in my experience it did make a sizable difference and it's something I always teach to others. Static candle objects with light objects for their light source trump static lights. On a purely aesthetic level, they also are more pleasing to the eye as you can adjust their proximity to walls without sacrificing light radius.

[Arthmoor]

If you're going to concentrate effort on reducing polygon counts, focus on collision. The actual gemoetry portion of the visual mesh is handled by the GPU, but havok is handled by the CPU and Oblivion is a heavily CPU bottlenecked game so anything to reduce collision poly count will help dramatically.

As far as light sources, it's been my experience that the difference between "true" light sources and "invisible bulb" light sources means nothing. It's all in whether or not it flickers. You can have 50 non-flickering sources and be just fine, but could have 25 flickering sources and cripple things. It also depends on how large the radius is, and what the vertex and face count in the CS is showing you for a particular cell.

One other thing that's almost never touched on is that many visible static light sources also have attached sound, especially flames. Sound can be a major drain even on a PC with a dedicated sound board. The fake bulb sources of light have no sounds attached. Smaller flame sources benefit greatly from having those sounds removed as well.

[DarkRider]

One other thing that's almost never touched on is that many visible static light sources also have attached sound, especially flames. Sound can be a major drain even on a PC with a dedicated sound board. The fake bulb sources of light have no sounds attached. Smaller flame sources benefit greatly from having those sounds removed as well.

I never considered that but that's a good point, I reckon it applies perfectly to what I encountered on my other rig.

[AndalayBay]

A thank you too! This confirms my suspicions. I've been using a couple of real light sources for ambience, but using fake lights with light objects for the rest. With a couple of real light sources you can see and hear the flicker, but with the rest being fake, you get the performance.

[Arthmoor]

The main reason AN-Real Lights isn't as much of a beast as it could be is because most of the sound effects have been removed from the light sources. The smaller torch flames don't really have much need, so only the larger flames and fires still have them.

[AndalayBay]

Aha! Secrets revealed. I wondered how you guys managed it.

[syscrusher]

The first cell I reclaimed, I used about 40 light objects and was getting between 6-10 fps in that cell. Swapped them out for static candle objects with non-flickering light objects and fps went up to 35, cutting that number down to about 20, brought my fps back up to it's normal 50.

This is really valuable information. The specific numbers are less important than the fact that this verifies a *significant* difference. My house has 20+ light sources in it, so I'm going to start by swapping all of them for statics+phantoms. My other thread about getting the scripting to work on those now becomes more important. How much difference this will make remains to be seen, but it is obviously going to be measurable.

[Vince]

One thing you would not normally think about is the position of the center of the object relative to the center of the mesh.

I have a small shack (the Abandoned Mountain Shack) and work hard to keep the FPS up as it is an exterior home where everything counts inside and out. While I was working on this with my old computer (which shows FPS hits better than my newer ones), I noticed while one of the vines was taking up most of the FOV that the rate was about 3 FPS! It turns out that I had moved the object center to the center of the shack with the idea of being able to rotate the vine to use it on two corners of the shack. After trying several things that didn't change the frame rate, I tried moving the object center to the center of the mesh. That improved the frame rate to about 10 FPS, a more than 300% increase! Your mileage may vary.

[syscrusher]

One other thing that's almost never touched on is that many visible static light sources also have attached sound, especially flames. Sound can be a major drain even on a PC with a dedicated sound board. The fake bulb sources of light have no sounds attached. Smaller flame sources benefit greatly from having those sounds removed as well.

I'll check into that. I do notice that the fireplace objects make a dent in FPS; I assumed it was the animation, never thought of the sound effect being a problem. Thanks!

[syscrusher]

One thing you would not normally think about is the position of the center of the object relative to the center of the mesh.

Actually, I stumbled upon something like this on my own. I noticed that the FPS rate is high when I first enter the house then drops as I move around. Apparently the game engine loads its cache as you pan around the scene, rendering what is in the field of view. I did a game load at one end of this fairly long building, noting a high FPS rate that didn't change until I moved toward the center. As I did so, it dropped noticeably and stayed low until I next reloaded the game.

I have a small shack (the Abandoned Mountain Shack) and work hard to keep the FPS up as it is an exterior home where everything counts inside and out. While I was working on this with my old computer (which shows FPS hits better than my newer ones), I noticed while one of the vines was taking up most of the FOV that the rate was about 3 FPS! It turns out that I had moved the object center to the center of the shack with the idea of being able to rotate the vine to use it on two corners of the shack. After trying several things that didn't change the frame rate, I tried moving the object center to the center of the mesh. That improved the frame rate to about 10 FPS, a more than 300% increase! Your mileage may vary.

I have a room with a lot of indoor potted flora; this may be the source of my problem! I may need to move that to a separate cell. I didn't realize plants smaller than trees could make that kind of impact.

[Arthmoor]

Plants in general are beasts and when you get a lot of them together in a small space, or even in a relatively small outdoor space, FPS can suffer. Not sure what it is about them either because it doesn't take very many in a decent sized garden plot before you start having problems.

[Khettienna]

For most flora and shrubs and trees, all but the trunks, thick branches, and stems are shaped by the texture. Take away the texture, and you'll see that the meshes themselves are quite blocky. Since the game won't render overlapping transparencies, it will have to recalculate how much of which to show everytime the camera moves or the objects in question move, and that could easily strain a slower machine if there are many overlapping in one place.

On top of that, all shrubs and trees are affected by wind, so that will add to the CPU load when those objects are placed in an exterior (or an interior with exterior weather that includes a wind speed).

Collision does make a big difference, even on statics - I can vouch for that. To give an example, I had a mesh whose collision model was a duplicate of the original. Anytime an NPC or creature got close to it, my game would quickly grind to a halt and eventually BSOD. This was due to a tiny nick in the model (to give it a worn look) that wasn't smoothed from the collision model. It was just too much for the engine to reconcile. Not everything has to be a simple box, but I would definitely recommend removing any nicks, grooves, insets, and other details as much as possible.

There are some tricks to handling large or highly cluttered interiors. One is to make havoked objects static as much as possible, to cut down on physics calculations (such as static vases for tables). Another is to combine multiple static meshes into one and give them unified collision (such as filled bookshelves, place settings, or planters of multiple flowers). You can also add a fog distance to large interiors, as the game will stop rendering non-LOD objects beyond a certain point in fog (I have heard, but I have never confirmed this personally - Arthmoor probably knows for sure). You can turn your ambient light up high enough to get the corners lit and cut down on lights. You can remove the flicker from lights, and as mentioned earlier, also the sound. Make sure lights aren't overlapping; if you need overlap to get the place lit enough, refer to my previous suggestion about raising the ambient light.

If your single cell has multiple areas or rooms separated by doors or long hallways, consider also using teleport doors and stacking the areas vertically in the cell. Unless the player pans the camera vertically, the objects far above and/or below are much less likely to be rendered. You can also use this trick to move things out of the game's general draw distance, depending on what the player's video settings are in-game. The game will still treat it all as a single cell, such as for NPC use and what not.

[syscrusher]

Khettienna, this post of yours is worth its weight in gold...many thanks! Comments below. Some of what you suggest I'm already doing, but the things I am not yet doing are real gems.

For most flora and shrubs and trees, all but the trunks, thick branches, and stems are shaped by the texture. Take away the texture, and you'll see that the meshes themselves are quite blocky. Since the game won't render overlapping transparencies, it will have to recalculate how much of which to show everytime the camera moves or the objects in question move, and that could easily strain a slower machine if there are many overlapping in one place.

That blocky-and-textured situation was my expectation, though I hadn't actually looked at them in Blender to verify it.

On top of that, all shrubs and trees are affected by wind, so that will add to the CPU load when those objects are placed in an exterior (or an interior with exterior weather that includes a wind speed).

This one I knew, though it's not an issue here in my interior cell. :-)

Collision does make a big difference, even on statics - I can vouch for that. To give an example, I had a mesh whose collision model was a duplicate of the original. Anytime an NPC or creature got close to it, my game would quickly grind to a halt and eventually BSOD. This was due to a tiny nick in the model (to give it a worn look) that wasn't smoothed from the collision model. It was just too much for the engine to reconcile. Not everything has to be a simple box, but I would definitely recommend removing any nicks, grooves, insets, and other details as much as possible.

I didn't know that about the engine getting confused by a porous collision mesh! I'll check my clutter objects to make sure none of them have that problem. I'm also seriously considering completely re-collisioning the house mesh from scratch, now that I know more Blender than I did when I originally made it. Your comment here adds some weight to my decision, in favor of undertaking the re-collisioning process (painful though it will be).

There are some tricks to handling large or highly cluttered interiors. One is to make havoked objects static as much as possible, to cut down on physics calculations (such as static vases for tables). Another is to combine multiple static meshes into one and give them unified collision (such as filled bookshelves, place settings, or planters of multiple flowers).

I agree completely, and also these techniques avoid the problem of Havoked objects getting knocked around by the player or just occasionally deciding to fly off of shelves and such. The approach I have been taking is to (1) use such premade objects from resources when I can, (2) make them myself as needed, and (3) use mostly static clutter in the house, but leave a few shelves empty for the player to fill as they wish. It's been my experience that you typically have a very few things your character wants to put on shelves. I am allowing a lot of display cases, though, which I find to be easier to manipulate in-game. Meo's rendition of the Umbecano cabinets has been really valuable here, as the vanilla display cases are too small for things like helmets and some weapons. I've made a couple of customized versions of that cabinet based on Meo's resource.

The bookshelf sets from Meo and Korana have been exceedingly helpful here, also. I've set them up as container objects so the player can either store books in them, or simply ignore them as if they were static clutter. Player's choice.

You can also add a fog distance to large interiors, as the game will stop rendering non-LOD objects beyond a certain point in fog (I have heard, but I have never confirmed this personally - Arthmoor probably knows for sure). You can turn your ambient light up high enough to get the corners lit and cut down on lights.

The fog idea won't work well in my house interior, but I am already using it in one particularly large dungeon level. The dungeon has one corridor that is so long that with certain video settings, you could see out into space at the far end because the game wouldn't render the distant walls even at highest-distance setting. A little fog hid that nicely, and interestingly enough I am having no FPS problems in that cell at all. Even on my modest video hardware (my laptop where I mod is much slower than the "real" gaming machine where I play), I'm getting around 60~80 FPS in the large dungeon level. On decent video hardware, that will be much higher.

I have been thinking about bumping up the ambient and reducing in-game light sources; your comment pushes me a little further in that direction.

You can remove the flicker from lights, and as mentioned earlier, also the sound. Make sure lights aren't overlapping; if you need overlap to get the place lit enough, refer to my previous suggestion about raising the ambient light.

Flicker is already gone from most of them, for performance reasons, but I will probably remove it from all the others also. I didn't know overlapping lights was a problem. It makes sense now that you mention it, but I hadn't considered that before. I have that situation a lot, so I will take a very careful look at that with the CS set to display light radii.

If your single cell has multiple areas or rooms separated by doors or long hallways, consider also using teleport doors and stacking the areas vertically in the cell. Unless the player pans the camera vertically, the objects far above and/or below are much less likely to be rendered. You can also use this trick to move things out of the game's general draw distance, depending on what the player's video settings are in-game. The game will still treat it all as a single cell, such as for NPC use and what not.

I've done the trick of teleport doors within a cell for other situations, but I had not thought of using it in this *vertical* way. That's a really cool tip! It's particularly nice because the vertical separation won't show up on the player's local map.

Some background info (which Khett already knows; this is for other readers)... I know it's a little unorthodox to have such a huge house cell, but I set this as a strict design goal at the start. I find it very irritating to come into a player home and have to go through one or more cell loads just to drop off my loot or reach my alchemy station or sleep. I knew there would be a performance hit, but I decided early on that (1) I could live with a modest FPS hit in an area that would seldom if ever see battle, and (2) I could optimize away much of the problem by careful implementation. This thread is really helpful toward #2. I've been an engineer for 25 years, so I keenly understand that there are always compromises. My decisions here may be different from what other modders do, but as has often been pointed out, the player has the ultimate choice whether or not to live in this house. :-) (In fact, the mod is designed so they could play the quest and utterly ignore the house if they want.)

Thanks again, Khettienna. I think you've got the start of another great tutorial here, if you wanted to do so. This thread in general has certainly been helpful to me, and this post is one of the thread's most useful highlights. :-)

Syscrusher

[syscrusher]

It occurs to me...

I am in the process of moving my modding environment from a dual-boot Windows on my normally-Linux laptop, into VMware on the same machine. If I can make my mod perform well in a virtualized environment underneath modest physical video hardware, nobody else should have performance problems with it. It will be a good test case.

[Arthmoor]

You can also add a fog distance to large interiors, as the game will stop rendering non-LOD objects beyond a certain point in fog (I have heard, but I have never confirmed this personally - Arthmoor probably knows for sure).

Yes, this works nicely in larger dungeon interiors. Even better if you set the fog color to pitch black. Then you'll get a nice fade out to black with it instead of the nasty greenish color that a lot of vanilla dungeons have.

[AndalayBay]

Yes, this works nicely in larger dungeon interiors. Even better if you set the fog color to pitch black. Then you'll get a nice fade out to black with it instead of the nasty greenish color that a lot of vanilla dungeons have.

That is cool! Just tried that with a large interior area and that looks really neat. Makes it super dark though... Guess black has a tendency to do that

[syscrusher]

I've set up a test cell with *just* my house mesh in it, and only ambient lighting. Inside that cell, I'm reliably getting 160~200 FPS on my relatively modest video (mobile NVIDIA). In the real house, I'm getting 10~20 FPS. By comparison, walking around outdoors in a wilderness cell I see 60~70 FPS on this hardware. What I conclude from this is that, although my house collision may not be perfect, it's also not what's killing FPS. So rather than re-collisioning in Blender, I'm going to start in the CS with the lighting modifications and clutter tuning that several folks have suggested.

"Shoot the elephants first, then come back for the gnats later." :-)

I'll post again when I have some further results. I think I have lots of overlapping light sources, because I didn't know that was a problem. I'm seriously considering blasting away *all* my lighting in CS and re-lighting from scratch.

Syscrusher

[Khettienna]

I think I have lots of overlapping light sources, because I didn't know that was a problem.

Address this first and see how much improvement you get without touching anything else. It takes a lot of work to light an object; it takes that much work again with each additional object; it's twice as much when two lights have to duke it out, much like overlapping transparencies. Except it's not just two objects, it's every single object affected by both lights having to be recalc'ed when the camera moves or the lighting changes/flickers. In a cell cluttered vanilla-style with just a few objects, you can easily lose 3-5 fps per overlapping light. Multiply that as needed for how many objects you have, if you have AA and/or HDR enabled, and all your high-rez normal maps.