where are the reference posts about cells, actor density, and impact?

[BobWyglz1]

hey all.

so we're all painfully aware why the Strip is so devoid of population; the little engine that could, uhm, can't.

even just a slight ("slight" TO ME anyway)  increase of predefined NPCs, 20 gamblers, 10 more NCR in uniform, another 10 in civilian clothes dancing in the fountains or behaving drunkenly off-duty, 10 tourists in spiffy new vault 21 jumpsuits, 10 more townsfolk walking to and from work at their casino jobs, 10 more securitrons, etc. it just crushes the poor thing. and these are tiny cells.

and if you dare spawn in 200, or worse enemy factions 100 vs 100 where they have to calculate targets and combat, good luck even keeping it running; (though funny and one-sided to spawn 100 gomorrah hookers and 100 rampaging glowing ones all spamming their nuke blasts) it slows down everything, even the texture swapping for the animated lights; iGPUs and underpowered systems on the scale of what was available over a decade back, well... forget about it. even a modern system will dive to 15-20fps, or worse, leave you on the desktop (2 out of 10 tries just bombed out within seconds). and the input latency makes it all but unplayable. sure some of it is threading, some the 32-bit process and it's limitations, whatever...

but a game this old, there has to be reference research done by now, what can be done, what's the scripting/package overhead, memory footprint, etc where you know what's safe to add for a given scenario, even if you have to tailor it based on system resources.

I would love a spreadsheet table, tested, tried and true, of an "impact study" based on idles, packages, global script load impact, etc.

I'm all for the "try it and see" approach but that doesn't help during the conceptualizing and planning phases.

my fear is everyone just gets a "feel" for it as they go, without hard numbers, which I loathe.

anyway thanks for reading and any links you post!

 

[JimboUK]

I'm not aware of any proper research being done, I've been experimenting with pushing the limits of this for years and I've found the following to be the main issues...

Memory limits, although these can be mitigated by keeping the number of different textures down.

Scripts, they work but not in a timely manner, with large numbers of NPCs in combat some will just stand there watching until finally realising that they're supposed to be involved, however this might be a symptom of a low frame rate, not the cause.

High poly outfits and weapons, best avoided unless it's for screenshots.

Lights, combined with NPCs these will tank the frame rate quicker than anything else.

While "try it and see" doesn't sound ideal it really is the only way, if you're aware of what causes issues then you can avoid those issues while planning, you can also make use of things like occlusion planes to keep the number of rendered NPCs down. Under the hood this game is basically Oblivion, a game that started development in 2002, it's never going to be able to do what newer games can.

[madmongo]

I don't think there's a simple formula or spreadsheet that you could create that describes how many NPCs or enemies you can spawn. A lot of it depends on the area where you are spawning them and how much memory is being used for other things like textures.

When you start digging into things, you'll find that a LOT of things are poorly documented, if they are documented at all. Basic things like how to create a worldscpace aren't well documented, and good luck finding decent info about how to create animations. There is a region navmesher in the GECK that isn't really documented at all, and if you try to use it you'll find out the hard way that it rarely works and often completely locks up the GECK.

Who do you think would be creating all of this documentation? Bethesda and Obsidian moved on to other things. They aren't going to spend months and months creating documentation about their game engine. They would rather spend that time creating a better engine or developing a new game. Modders? If you are making mods, your emphasis is on your creations, not creating a full set of documentation. Sometimes people take the time to write tutorials, but not often. There is a huge amount of information here in the Nexus forums, but no one is taking the time to sort through it all and organize it.

You've been doing a bunch of experiments with large numbers of NPCs. Have you documented your findings? Where are the spreadsheets that you have created? Will you be creating and releasing this type of documentation?

Once you've been modding for a while, you start to get a feel for where some of the limits are, but most of it isn't documented anywhere. If you create a worldspace that is too large in the X and Y directions, when you actually place things in those high offset X and Y cells it breaks the game's physics engine. If your world's landscape is too low, you end up with floating trees in your LOD. Keeping your landscape height above 14,000 seems to work but where exactly is the limit?  If you place an object at too far of an offset in the X, Y, or Z directions in an interior cell, it breaks the cell and all of your objects can end up all squished together in the center of the cell. The auto navmesher for regions in the GECK is completely broken, it rarely works and often completely locks up the GECK. There is hidden info in animations which is stored in the GECK. For example, if you create a looping animation and you don't use the correct tags for the loop start and end, the GECK stores that somewhere and doesn't tell you about it. If you fix the loop tags in your kf file, the animation still won't loop properly. You have to rename the kf and re-assign it in the GECK so that the hidden information gets updated. Viewing an NPCs face and then switching to the inventory tab crashes the GECK. Taking the default heights in the heightmap editor crashes the GECK. Starting reference IDs with a number works for some things but not others. Adding too many objects to an exterior cell causes some of the earlier objects that were added to disappear. Where is that limit? Most of these things are not documented anywhere.

What are the .fid .fud and .fvd files used for in Version Control in the GECK? What issues can arise if you create an empty list when generating your bit array files for Version Control? How much memory does each record type take in a save file? What is the limit in save files before the game goes wonky?

There are a lot of basic things that need to be documented before you even get to things like how various things affect performance.

If you think things should be documented, then document them. I'm sure a lot of people will find the information useful.

 

[JimboUK]

The GECK is supposed to have something to help with lighting optimisation if it worked, but it refuses to for me, it just turns everything grey.

https://geckwiki.com/index.php/Bethsoft_Tutorial_Lighting#:~:text=Performance and Optimization,-Performance is always&text=Let's open up the preferences,appear in shades of blue.