Had quite a scare with my rainforest test region: the framerate was bottoming out at around 12-15 FPS. My PC's no supercomputer but it's no slouch either and I'd like to see 25-30fps minimum.
I think I have it worked out. There were two problems. The lesser one was an excessively complicated mopp collision (c. 400tri) on a set of palm tree models. I've temporarily replaced this with a simple list of boxes. (I'll probably apply a simpler mopp long term.)
Some improvement, but not much.
Then I tried cutting down the alpha blending on the same models using Nifscope - and that's the issue.
Basically, with all the frondy stuff we have in Tenmar, it looks really nice with
NiAphaProperty.Flags = 4845
NiAphaProperty.Threshold = 128
This blends out the fronds and lets you see one part of the mesh through the gaps in another so I'd set this for several models.
But performance stinks.
On the other hand, with
NiAphaProperty.Flags = 4845
NiAphaProperty.Threshold = 0
the gaps in the mesh won't show other parts of the same model - basically palm fronds look all gappy.
So, what to do? I think we will have to set the alpha blending threshold to 0 for all the Tenmar resources, or the mod's performance will be terrible. I'm wondering if it is worth maintaining a second resources bsa for high-performance machines and for screenshots.
Opinions / suggestions / workarounds ?
Hi Morcroft,
I hope I'm not beating an already dead horse, but just on the off-chance you didn't know this already -
Are you by any chance using this date palm tree model in your all's forest?:
http://img87.imageshack.us/gal.php?g=dat...glecou.jpg
(If you can't see all three pictures at Imageshack linky above, be sure to tell me..I can reupload the pics elsewhere. Me and Ibsen were having some prior trouble with Imageshack...)
You mentioned "palm" in your OP, so I was thinking that maybe you were.
This palm is massively polygon intensive, especially the leaves - 16,000 triangles for the leaves alone. Plus the nif of this palm has over 1,000 "Num Strips" for the leaves when in NiTriStrip form - this very BAD. The "Num Strips" should be "1" for all NiTriStrips. Running through most recent PYFFI will fix this, though, but will not fix the polygon count of the leaves. We have this date palm over at Blackmarsh, too, and I foresee it causing trouble unless it is optimized.
The good news, is that someone made an optimized version of this palm tree, because I remember reading about it in a Bethesda thread. I think they made it for the Elswyr: Deserts of Anequina mod.
If this date palm is indeed also causing problems for you guys (besides the alpha thresh-hold thing - never heard about this before, so thanks, I'll keep an eye on that just in case), how abouts whoever makes an optimized version of the date palm first, sends the other mod project here the optimized version as well???
Koniption
Thanks for the info Koniption - I sort of knew if I titled a post "optimisation" I'd catch your eye!!!
Actually we're not using that date palm model. I can see how that one could be pretty high-poly. The ones I'm looking at come in at around 1300 overall which isn't too bad, really. The 400 tri collision was probably much more of an issue, and complete overkill. I think it started out with multiple NiTriShapes which got cleaned up automatically into a NiTriStrips with num_strips = 1 when Blender exported it. I do like it when my computer does the thinking for me.
The alpha blending property seems to be a complete killer, though. I'd noticed I got much better visual results with Threshold > 0 and couldn't understand why people seemed not to use it. Now I know! I'm now looking at some of the textures to sharpen the alpha transitions to cut down on the odd "gappy" effect.
I'm trying to keep the poly count as low as I can because we're planning to pack the plants in pretty tight in the rainforest - not much point otherwise.
Quote:Originally posted by morcroft
Thanks for the info Koniption - I sort of knew if I titled a post "optimisation" I'd catch your eye!!!
Actually we're not using that date palm model. I can see how that one could be pretty high-poly. The ones I'm looking at come in at around 1300 overall which isn't too bad, really. The 400 tri collision was probably much more of an issue, and complete overkill. I think it started out with multiple NiTriShapes which got cleaned up automatically into a NiTriStrips with num_strips = 1 when Blender exported it. I do like it when my computer does the thinking for me.
The alpha blending property seems to be a complete killer, though. I'd noticed I got much better visual results with Threshold > 0 and couldn't understand why people seemed not to use it. Now I know! I'm now looking at some of the textures to sharpen the alpha transitions to cut down on the odd "gappy" effect.
I'm trying to keep the poly count as low as I can because we're planning to pack the plants in pretty tight in the rainforest - not much point otherwise.
We talking about my ponga tree models here? haha.
Ahh, ok. Thanks for clarifying!
KP
Quote:Originally posted by The Old Ye Bard
We talking about my ponga tree models here? haha.
Actually hadn't checked the Ponga - but it does have the threshold set so probably exhibits the problem.
OK: this is starting to look like a false alarm.
Well, actually a very real alarm, but a false diagnosis.
I created a new worldspace and put about 4000 Palms into a 5x5 cell patch of it. I tested with and without the alpha blending in the nifs - and the difference was really only a few fps - down from 60 to 56 or so. And I'm not convinced by that either.
Some other experimenting points to the LOD objects. Because Elsweyr has such long sightlines in the central plain I've created _far nifs for the bigger rocks and run TES4LODgen to create the DistantLOD for all the _fars and the trees. Works fine, looks great, but the engine calculates the objects from everywhere so the frame rate is really not good: bottoms out at under 20 fps.
Doesn't seem to matter whether the _fars are actually visible or not: if they're in the field of view behind a hill I still see the low frame rate. And distance doesn't matter: which I suppose is the point.
I've optimised the _fars as well as I can: taken out the collision, decimated the meshes so they're all < 100 polies and stripped any extra data nodes. Only thing I haven't tried yet is creating low-res textures for them.
Do I just have to accept that we either have a low frame rate or reduce the number of vwd objects?
They should be even less polys to start with (100 is too high for LOD meshes, try under 40 -even as low as 30), and secondly a low-res texture is definetly needed.
OK: I'll get on it, ta.
Is there an issue with the number of LOD meshes as opposed to complexity? Obviously fewer is faster, but how does it scale - is
10 _far nifs each 200-faces
better or worse than
50 _far nifs each 40 faces?
[ EDIT: ]
So I've decimated down all the _far rock meshes I have and down-sized the textures from 512 to 64x64 . All the "rock numbers" here refer to my retexes of the Great Forest set, for which I've kept the original numbering scheme.
My test region gen covers Tenmar, the desert / badlands, and the scrub in between. It has:
12 x rock 1650 @ 78 faces
10 x rock 1400 @ 84 faces
284 x rock 970 @ 50 faces
14 x rock 645 @ 55 faces
578 x rock 560 @ 42 faces
Appearance-wise, definitely still fine so no need for higher resolution meshes or textures and could probably go a bit lower if it seems worth it: good steer, TOYB.
The frame rate is a tiny bit better but not great. Low 20s when looking North in the middle of Tenmar.
So then I removed the _fars for rocks 645 & 560 - leaving just the 306 objects the size of rock 970 and bigger - and regenerated the LOD.
Now the frame rate picks up substantially: there's one particular angle due north from Tenmar where it drops to 32fps, but otherwise it's up in the 40s and 50s. Definitely playable.
So there seems to be a practical limit, even with really pretty low-rez meshes and textures, somewhere between 300 and 900 LOD objects in the view field.
I don't think my machine's too bad, so if I'm not missing anything else then this has design implications:
To make the central landscape look interesting from a distance it's better to have more large rocks and not start adding _fars to any smaller ones. I think rock 970's about as small as we want to go, and we should have fewer of them and more rock 1125+
I was thinking we should have _far nifs for most of the static trees - palms and such - so they can be seen across the open regions, but I'm having second thoughts now. We definitely can't afford to use _fars for anything in Tenmar so if we want palms visible across the central plain, and I think we do, then they should be a differently named model with a matching _far. We can use the same model in Tenmar, just named differently and with no _far.
Interestingly, the speedtrees really have no impact whatsoever that I can discern. Which means Oblivion's LOD is optimised to handle loads of them quickly. From a resource point of view it's not surprising: they're 2 triangles with a tiny texture. Guess I need to make more speedtrees.
SpeedTrees work a lot better because the engine handles them in a different way to the usual meshes, hence why you can have reasonably thick forests without encountering a Fps drop (within reason of course).
But more importantly, at this point we really do want to be getting rather good Fps, not just 'okay' Fps, given over top of this we're going to have scripts running, pathgrids, Npcs, creatures, other AI, and also the added LOD of regions outside of Elsweyr (Valenwood, Cyrodiil, Blackmarsh, etc).
While we do want to have it looking pretty-as-possible, we also want everyone to be able to play it with reasonable Fps.