Let's duscuss our findings making interior cells as exterior with land statics. I've been intrigued with it since working on my Firemoth project, which started as a concept to bring all of the cells of the Firemoth Atoll into one big interior cell. I've put a link at the bottom of this post as a reference.

Roughly, I've managed to get all 20 or so cells of Firemoth generated with Yacoby's Cell to Nif generator, and, using Blender, just combined the cells into one big mesh, reducing the total polycount of the mesh by 80-90% or so, and scaling the UV mapping way huge so that the single texture used would tile at about the same ratio as land textures (looks good, although the UV map suffered some artifacts at the joined seams). In the end, it looked almost the same as the original, albeit with a more jagged terrain and no texture variety, though the performance in the interior-as-exterior was fairly poor on my machine - about 14 fps exploring, and 8 fps in combat. Some of the testers reported signifigantly better performance, and others with signifigantly poorer or unstable performance. Another bonus is that the follower AI doesn't suffer from the cell change issues like in exteriors.
Also, I soon found out that the overhead map begins to glitch bad with interiors this big -- the water height isn't drawn on the whole map, only a small portion, so a large part of the map the player could not discern the coastline from the sea (must be a hardcoded limit, I think there's enough water to cover a 2x2 cell area on the map). There were also some other visual artifacts with the overhead map too. In play, on some parts of the coastline, you can tell there was some z-buffer fighting between the water and the land mesh, flickering as the player moves about.

I did notice most of the performance hit was mainly from collision detection. With collision toggled off, the framerates were as smooth as with an exterior cell. Reducing the poly count of the land mass further did increase the performance decently, though the low fidelity of the landmass was a distraction. I looked at other meshes, and noticed the root collision branch, and decided to play around with that. What I found was very interesting -- adding root collision to a land mesh, even if the shape data is *exactly* the same, increased performance around 50% percent! This was pretty huge. I played around more with the finding, and verified that as long as the collision mesh is fairly low in poly-count, the actual land mesh can still be high-poly -- as long as it's tested where there isn't too much of a difference where the actors float or sink into the landmesh in accordance to the collision mesh.
I did find one issue with using root collision, it seems there's a collision issue when swimming -- when the player is in swimming animation or treading water at the surface, they can swim right through the land mesh, instead of walking on shore. This doesn't happen when there isn't a root collision branch. Not sure what causes this, it only happens under these circumstances. One can work around this by limiting how far a player can wander off-shore, or just keep the water shallow enough to wade through.

I didn't test number of references in relation to performance, since Firemoth only has about 600 references total throughout the 20 odd cells. The more actors on screen did slow things down, and I'd assume that a reference heavy cell would drain performance accordingly.

Anyone else have much experience with these types of interiors? I don't have a lot of modelling experience, where it could be interesting to see how splicing the meshes for performance might work, or extensive UV editing/model splitting for texture variety (in lieu of ultra-large textures per cell). I thought that adding the root collision was pretty signifigant for these land meshes with performance on lower end machines (even given the drawbacks), wouldn't have thought much about it otherwise.

I think splicing the mesh would yield an increase in performance. I don't know the game's hierarchy on collision detection, but I assume it only checks an object against (moving) objects in its vicinity. Thus, if you have a 20x20 cell-sized mesh, it's going to check for collision along the entire thing for every object that is moving. There's a reason why the game doesn't load a 20x20 block of cells at once, and that's for performance. The game loads your cell and the eight cells around you (for a 9x9 block of cells) to check for collision and fast-loading. Checking for collision in an area twice as big is bound to hit performance.

Try breaking them up into 5x5 cell-sized blocks.. maybe that would help. But maybe not, seeing as the entire interior is loaded and I'm sure collision is checked for across the whole interior.

I'm pretty sure it's checked throughout the whole cell. I also think AI distance has a large role too. I did manage to get the perfromance signifigantly better going the root collision route. Tweaking the results, the fps now stay above 20 fps typically on my machine, more than acceptable by Morrowind standards. Then again, there's less than 600 references in the total interior, if every cell was detailed like Balmora, no doubt the performance would be crippling -- Firemoth in comparsion, majority of the cells are empty of references, and the most in one cell is about 120.

If I had the skill, I'd try splicing and redoing the UV maps, but my modelling experience is limited, as is my free time as of late. Not sure if performance would be impacted (unless Morrowind handles smaller meshes more efficiently), but it would do wonders for aesthetics, and texturing.

Heh.. I typed that whole paragraph, then by the last sentence, I realized that collision is whole-cell. Kinda voided what I typed, but I left it there.

I do agree that the whole of Firemoth is a bit excessive for an interior cell (it was 24 cells, which I've paired a lot of the outer cells down so that it's more along the lines of 20 cells). I did it as a concept to see if it's even possible. If I was to finish that project up, I'd probably just cut down the size to just the "fort" islands, which would shrink the total size to somewhere around 2x3 -- most of the cells aren't really utilized to any signifigant degree.
I'd say a 2x2 interior-as-exterior would work best, with a 3x3 pushing the limits, running into a lot of the anomalies I've ran into. If you don't care about the overhead map, or water height issues, then 4x4 I would recommend as the maximum if there's a moderate ammount of refs.

I'm just curious as to why performance improves greatly when adding root collision to the land mesh, even if the collision mesh is exactly the same as the land mesh. I'm wondering if anyone else had any experience with this too. It probably doesn't matter much on newer processors, but it made a huge difference on my Celeron.

I wouldn't recommend combining the meshes. You may even get better performance be diving the cells up, as the inbuilt terrain engine actually divides each cell into 16 meshes. The reason you may run into issues in that it is always rending a huge mesh so not being able to culling the objects outside the http://en.wikipedia.org/wiki/Viewing_frustum. By having smaller meshes it can avoid rendering most of the landscape.

I've only combined the meshes as I don't have the ability to reduce the polys of the individual cells without causing alignment issues, as well as the UV wrapping so the textures are seamless. Even with the huge mesh, performance is more than acceptable using the root collision -- in contrast, utilizing the cells straight from the utility plunged my framerate into the low single digits (the huge mesh itself is about the same size as one cell generated, maybe a bit less). I really aught to try using the cell whole and combining it with root collision, and see the performance increase. My tests yielded 50% increase on my mesh, so who knows.
I am however, now curious if splitting the mesh into much smaller pieces would increase performance. I'll need to, erm, contract that out to someone else since that is well beyond my ability and capacity. Who knows, if it yields even more performance, then who needs exteriors? (just kidding)

(Any chance your utility can also grab vertex paint on the terrain in the export?)

1. Combine into huge mesh
2. reduce polys
3. Split
4. ???
5. Profit!

Really though.. did you try splitting it up after you reduced the poly and corrected the UV wrapping? I'm not a modeler, but I think you'd have to cut the UV map accordingly as well, right?

I have no clue how to, I'm not a modeller by any means, and I'm not as young nor have as much free time nowadays. I'm picking up more things hear and there when I get the chance, but working on large meshes, and large UV maps is just beyond my capacity. But yes, figuring out that 4th step could be a great breakthrough, or at the very least an interesting novelty.

In whatever 3D modeling program you're using, there should be some kind of splice tool that you can use to "cut" the model into pieces. So I think. Then just take the UV map and "cut" it into equally sized pieces.

I use Blender, which isn't exactly that intuitive. I'm getting a little more proficient with it, but in combination of my slower computer, and lack of skills -- editing large objects in 3D is time-consuming and confusing. Loading the original cells from the utility took about 10 minutes, while reducing the polys took probably half-an-hour. Not to mention how long it took to resize the UV map.

I'm curious to hear others' experience using interiors as exteriors.

Splitting the mesh will (almost guaranteed) help performance. Having a single huge mesh will hurt the culling engine. If you've ever noticed a slow-down in Balmora, try looking at the ground. It speeds up again (on the first comp I ran Obvs on, there were areas I had to run through looking at the ground, otherwise it would slow and crash).That's the culling engine coming into play, filtering out what you couldn't possibly see to draw only what you might see (saving time). A single huge mesh is harder and slower to process.
Splitting each cell into at least 4 chunks would probably be a good ratio. You can also use some simple scripts to watch for the player being out-of-range and dynamically enable/disable chunks of land (emulating the engine's exterior loading system).

As far as collision, the increase you noticed there is probably related to the difficulties of calculating per-triangle collision on a concave mesh. Speed is directly related (linearly at least) to complexity. Morrowind's engine also has some issues with collision when the player is inside a mesh (you would get a speed boost if all the vanilla tilesets were remade into 4 segments (floor, walls, ceiling)). Making smaller chunks will help with that (fewer triangles to run). In an exterior cell, using per-tri collision isn't terribly slow because it's pretty well optimized (I think Yacoby's mention of being divided into 16 segments is related to that).

I'd suggest recording your speeds with the full merged mesh and pre-tri collision, then the merged mesh and box collision, then the split mesh and per-tri. I'd almost bet the 3rd option will give you the best speed (which is nice, since per-tri collision will give the best visuals and play too).

Interesting stuff! Now I'm curious enough to see just how much performance can be had from all of this. So for splitting, does this mean as seperate pieces within the .nif, or as seperate statics? How well does an interior cell cull data?

From everything I've seen/heard, the Gamebryo engine has always had pretty good culling (and I think for the latest, they're bringing in a middleware that will do it better).
I don't know if splitting it into chunks within a single NIF will do it. It's definitely worth a shot. I know multiple NIFs will allow the culling to work at it's max.

The main problem (and why you saw the biggest increase) is collision. If you were to test a flat plane or even a hill, it would probably be faster than a valley. I don't know the exact reason, but concave collision meshes usually have a performance hit (has to do with how they test). If you've played with Havok, for example, they have a half dozen hull options for convex meshes and a half dozen hull optimizers for concave ones.

So is there a reason why just adding rootcollision to the mesh which is exact to the shape data of the mesh, increased performance greatly?

---

I've found an easy way to split the mesh within the .nif, and split it into 16 parts. The performance is about 10-20% faster than with the root collision! It also eliminated the z-buffer fighting. The overhead map issue still persists as it's an area issue. I'm now in the process of splitting the mesh into 64 pieces to see if there is anymore benefit.

After splitting the piece into 64 pieces, the performance was as smooth as an exterior. Splitting further than 64 didn't really increase performance, but did make loading a lot smoother.

Here's the link for the proof of concept: http://www.gamesas.com/bgsforums/index.php?showtopic=1077863

I think next step is to see if adding root collision to the split mesh parts yields any noticable results. Would be tedious work, for what could be little gain. It might be worthwhile if using more complex landmass meshes, or complex interiors, to squeeze a few extra fps. I'll post any notable updates.

you know, i wouldn't mind seeing a lot of the older landmass mods turned into interiors. like castlevania.

I find that if you make a very detailed interior-as-exterior, it really doesn't perform well at more than two cells in size - c/f the Mournhold Docks cell of Mournhold Expanded. It would be impossible to split that cell without compromising the look and feel of the place, but were I to design something like that from scratch (in fact, as I am with Suran Intended), I'd have more invisible walls and make it geographically a lot smaller, using gates to connect small and densely detailed areas together.

Morrowind's problem is that it doesn't have optimised "rooms" like Fallout 3 - special rendered zones within a cell so that you're only loading the visible area at a time. It's not so much a problem with the engine as it is with the way the engine's being used by the game.

The way I got around it with my Aldbarrow mod was to have two cells - the island around the city, and the city interior, and use the portcullis (from Ghostgate) as a door. That way you only have to have in each cell what you can physically see through the portcullis, and can safely delete anything that's out of your line of sight. That massively cuts down on the number of objects per cell and thus the framerate. You also only need to have 1-2 visible NPCs in the bits you can't access. Then you walk through the gate-door into the cell so all you can see of the town outside the gate is whatever is within your line of sight; the rest of it simply doesn't exist. I used the same trick in my Leyawiin mod - but actually, Bethesda used the same technique in Oblivion with its gated cities i.e. you only see the rooftops from outside the city gates.

i believe it, i've played some of those random generated dungeons with large single levels which would make my system crawl. i think anything above 1200-1500 refs per cell begins to cause some conniptions.