Very true - hence the dilemma for the central plain, because it really looks rubbish with no lod objects. Some decent sized rocks will need to be in the LOD, and I'd like to see some static trees vwd, but that depends on framerate.
Another way to help is using less rocks, I know when I tested it out the central plains had a lot more rocks than was actually necessary (probably the result of using an editted region preset rather from scratch). So using less could probably give us another 1-2 Fps.
I just had a thought:
If you still want certain non-speedtree items to show up with LOD, but not every object of the same mesh in a particular region - what if you had two differently named nifs that are the same mesh model, but only one of those nifs has the "_far" nif of same name?
That way, *some* of the, say, double-bent palm trees will be viewable in the far distance, but the other double-bent palm trees only show up when the player gets closer. You might have to redo region gen some (I've no knowledge of region gen...I could be wrong), or you can handpick which of the palm trees to replace with the second nif duplicate that has _far nif - ya know, do it manually.
I know duplicating nifs for the same mesh model seems redundant, but if those models are chosen carefully and frugally, this method might help make the landscape look better, but yet save on framerates.
I had also thought of the impact of using empty "_far" nifs that are same name as real model mesh, to see if this helps make objects not suddenly pop into view as get closer, yet somehow save on performance since they are empty nifs with nothing in them. Of course, you'd see nothing at a distance, but as you get closer, things would fade in gradually, hopefully. I've not tested this method on my end, however. Just be sure to run TES4LODGen afterwards.
Koniption
Yes: when I mentioned having two models with and without _fars I was thinking about the ones without _fars being in Tenmar; and the ones with them being scattered thinly across the open plain. I didn't really think of using BOTH types in the open to make it look occupied from a distance then thicken up close to. That's an interesting idea - especially good for clumps where two or three palms seen from a distance will stand in fine for many actual ones only seen close to. I think we should do that.
My current suspicion is that the simple fact of calculating the position of a _far.nif may be a large part of the overall cost of using them at all, regardless of complexity; so an empty nif would still have a performance hit. And distant objects fade in fairly gradually anyway so I'm not too bothered about that.
The region gen is only temporary at the moment anyway: I keep redoing it to get a feel for what resources we need and to find problems like these before we commit to the final generation. I think we'd be best to generate slightly thin and clumpy using non-far trees then add a few _far ones to each clump by hand.
The region gen doesn't tick the vwd box even if it finds a _far, whereas TES4LODGen ignores vwd and creates LOD for all _far_ nifs. This means if you add a _far - enabled object and forget to manually tick vwd then it's visible when really distant; pops out of existence as you approach then fades back in as you get really close. Which looks seriously dumb! So we don't really want too many auto-generated vwd objects or it'll be a real pain auditing them for visiblility.
@TOYB: agreed about the rocks - the presets aren't tuned. I do think we need quite a few or it looks very boring. We may need more undulation in the ground to break it up a bit, and as I said, I think we need a few more large rocks and a lot fewer mid-sized ones. Can you have a look at the heightmap in that area and see if it needs more hills, please? Nothing big, just to break it up a bit.
Right now there are 900 rocks across the desert and badlands that are big enough to be worth _fars, and 300 that really need them. Of those most are the biggest non-landscape rock, 970 and only 22 are landscape-sized. I reckon we need maybe:
50 x various landscape rocks all vwd, - my retexes or new
50 x size970s
more of an even spread of models going down in size.
With the current setup that would be 100 _far models across the main plain for rocks. Allow another 50 or so for KP's idea of sparse vwd static trees and we've half as many _far models as now, plus all the speedtrees. Should make the central region look good from a distance with minimal framerate impact.
Quote:Originally posted by morcroft
Yes: when I mentioned having two models with and without _fars I was thinking about the ones without _fars being in Tenmar; and the ones with them being scattered thinly across the open plain. I didn't really think of using BOTH types in the open to make it look occupied from a distance then thicken up close to. That's an interesting idea - especially good for clumps where two or three palms seen from a distance will stand in fine for many actual ones only seen close to. I think we should do that.
My current suspicion is that the simple fact of calculating the position of a _far.nif may be a large part of the overall cost of using them at all, regardless of complexity; so an empty nif would still have a performance hit. And distant objects fade in fairly gradually anyway so I'm not too bothered about that.
The region gen is only temporary at the moment anyway: I keep redoing it to get a feel for what resources we need and to find problems like these before we commit to the final generation. I think we'd be best to generate slightly thin and clumpy using non-far trees then add a few _far ones to each clump by hand.
The region gen doesn't tick the vwd box even if it finds a _far, whereas TES4LODGen ignores vwd and creates LOD for all _far_ nifs. This means if you add a _far - enabled object and forget to manually tick vwd then it's visible when really distant; pops out of existence as you approach then fades back in as you get really close. Which looks seriously dumb! So we don't really want too many auto-generated vwd objects or it'll be a real pain auditing them for visiblility.
@TOYB: agreed about the rocks - the presets aren't tuned. I do think we need quite a few or it looks very boring. We may need more undulation in the ground to break it up a bit, and as I said, I think we need a few more large rocks and a lot fewer mid-sized ones. Can you have a look at the heightmap in that area and see if it needs more hills, please? Nothing big, just to break it up a bit.
Right now there are 900 rocks across the desert and badlands that are big enough to be worth _fars, and 300 that really need them. Of those most are the biggest non-landscape rock, 970 and only 22 are landscape-sized. I reckon we need maybe:
50 x various landscape rocks all vwd, - my retexes or new
50 x size970s
more of an even spread of models going down in size.
With the current setup that would be 100 _far models across the main plain for rocks. Allow another 50 or so for KP's idea of sparse vwd static trees and we've half as many _far models as now, plus all the speedtrees. Should make the central region look good from a distance with minimal framerate impact.
Imo, we need less rocks in general, not more on any account, and the big and the medium rocks need LOD models. And I'm not adept enough with the heightmap editor to give it the nice winding hills it needs to disguise the landscape (which it doesn't really need anyway, the desert/deadlands area is quite vast, we don't need any optical illusions to disguise it imo).