572 replies to this topic

[Fkemman11]

Well. The lighting in particular is what causes me headaches in interior cells. If I use the lights out mod my framerate doubles. I hate doing that because some of the interior cells look great with the lighting effects. Personally I think their might be a way to tweak the lighting and shadows just enough to achieve much better performance without sacrificing too much visual integrity. Ini tweaks work for me by decreasing shadow volume and quality. Suppose you can do this with lighting as well but I have yet to try. As I said though there has to be a more sensible solution. I mean other than just upgrading your hardware to handle the extra load. Not everyone that likes playing games with many mods can afford to spend thousands of dollars on their setup.

 

I have included a link to try and explain the performance issue with lighting in the game. Don't know if it will help or not. http://www.gamersnex...ark-and-disable

[chucksteel]

You could try to re-work the Roombounds and Portals in the interior cells that give you the most trouble but, I can't say for sure how much it would help due to the Pre-Combined system. I have had issues in some cells with the vanilla Roombounds and have had to adjust them for myself. (Issues where I could see out into the void that no one else seemed to have.) but, further optimizing the cells may help. 

[Giggilyomeromicon]

I've done a pretty good deal of testing out exterior optimization, and outside of some Creation Kit related technical problems, I've had a large amount of success.

 

First, pregenerated visibility used outdoors will massively improve performance in certain circumstances. By blocking off visibility of portions of downtown Boston I've been able to more than double my FPS, from the 30s to the 60s.

 

Second, precombined meshes are not all or nothing. When the game regenerates meshes for a cell not all of them will contain mod information. I've created an entire building that sat between two cells (without any open world interior) and the footprint was less than 3mb. I have safely deleted all non-mod related, but still regenerated precombined meshes without any technical issues.

 

What this means, more or less, is that it's possible to to delete all of the precombined meshes you have generated for a cell, except for the ones containing new information. Any other mod that edits that cell, but not the exact area which your changes have been made, will be compatible, so long as it also only includes only the precombined meshes containing its mod information.

[Urtho]

Exactly how sensitive is this system, meaning what constitutes enough of a change to a reference for a precombine to be disabled by the system?  Is it any change at all or are there small changes that are able to be made before the need to regenerate previs/precombines or disable the system for a specific cell becomes true?

 

Interesting reading to be sure, something I'll have to keep in mind if/when I move over here to making Fallout 4 mods.

[chucksteel]

An ITM on a ref that is included in the Pre-Combined meshes will disable the Pre-Combined system. So any edit to any object that is included in the vanilla Pre-Combined  system will disable it. 

 

You can add new objects, statics and NPC's so long as you don't touch anything used by the system. 

[Urtho]

Well that is... annoying.  Certainly something to be aware of when doing any landscape or location editing in this game I suppose, thanks for the information.

[VIitS]

A quick tip: if you look at a cell in FO4Edit, any reference that is part of a precombined mesh (i.e. will disable previs/precombineds for that cell if your mod includes them) will show up as

 

[Placed Object]

 

while references that aren't part of a precombined mesh will just show as

 

Placed Object

[zilav]

What this means, more or less, is that it's possible to to delete all of the precombined meshes you have generated for a cell, except for the ones containing new information. Any other mod that edits that cell, but not the exact area which your changes have been made, will be compatible, so long as it also only includes only the precombined meshes containing its mod information.

Unfortunately preocclusion system works not on per cell base like precombined meshes, but on 3x3 cells blocks, and mods that don't change the same cells still can conflict if they include those regenerated precombined and preoccluded files. They can make changes in worldspace which are two cells apart from each other, won't show any conflicts in CK and FO4Edit, but if they happen to be in the same 3x3 preoccluded block and change the same uvd file, they will conflict and cause visual issues. This is the biggest flaw of that system. In previous games mods had to change the same cells in exterior to conflict (or at least neighboring cells if landscape, pathgrids or navmeshes were involved) and such conflicts were easy to detect and create compatibility patches. It is no longer true in FO4.

 

The second problem is that precombination info is stored in the cell record itself, and if you regenerated precombination or just simply disabled it, this will work only if your mod is the last one in load order that changes that cell. So every mod author had to add "load my mod last" or "make sure nothing overrides it" in the description. Imagine a poor user with lets say 30 mods installed that change interior or exterior cells with updated precombination, each telling him to be loaded last. Add here conflicts from lighting mods which also have to change information stored in cell records, and they also will tell to be loaded last to work properly. Yes you can still create patches and forward conflicting cell information in FO4Edit, but if author of one of the patched mods will regen precombination, even if his new changes don't cause additional conflicts, all patches will have to be remade anyway due to changed precombination info.

 

The system is flawed. It worked for Bethesda and their game plus DLCs aka static, fixed and predictable load order, but it doesn't work for modding. At all.

[Giggilyomeromicon]

You're right about occlusion information being stored on a 3x3 cell basis being annoying, and that is a problem that's tough to get around, but the performance benefit of occlusion culling seems mostly centered around urban areas. There just aren't a huge number of mods than touch downtown Boston right now, for example.

As for precombined objects, they're stored in the cell record as mentions of specific meshes and the name of the precombined object they belong to. It's a single entry for each mesh. xEdit can update and solve conflicts in this information pretty painlessly. It's been a few weeks, but if I recall correctly xEdit updates the total number of precombined objects for each cell automatically, as well.

I'm not sure how this would be more difficult than creating any other kind of patch in xEdit.

[Fkemman11]

 

What this means, more or less, is that it's possible to to delete all of the precombined meshes you have generated for a cell, except for the ones containing new information. Any other mod that edits that cell, but not the exact area which your changes have been made, will be compatible, so long as it also only includes only the precombined meshes containing its mod information.

Unfortunately preocclusion system works not on per cell base like precombined meshes, but on 3x3 cells blocks, and mods that don't change the same cells still can conflict if they include those regenerated precombined and preoccluded files. They can make changes in worldspace which are two cells apart from each other, won't show any conflicts in CK and FO4Edit, but if they happen to be in the same 3x3 preoccluded block and change the same uvd file, they will conflict and cause visual issues. This is the biggest flaw of that system. In previous games mods had to change the same cells in exterior to conflict (or at least neighboring cells if landscape, pathgrids or navmeshes were involved) and such conflicts were easy to detect and create compatibility patches. It is no longer true in FO4.

 

The second problem is that precombination info is stored in the cell record itself, and if you regenerated precombination or just simply disabled it, this will work only if your mod is the last one in load order that changes that cell. So every mod author had to add "load my mod last" or "make sure nothing overrides it" in the description. Imagine a poor user with lets say 30 mods installed that change interior or exterior cells with updated precombination, each telling him to be loaded last. Add here conflicts from lighting mods which also have to change information stored in cell records, and they also will tell to be loaded last to work properly. Yes you can still create patches and forward conflicting cell information in FO4Edit, but if author of one of the patched mods will regen precombination, even if his new changes don't cause additional conflicts, all patches will have to be remade anyway due to changed precombination info.

 

The system is flawed. It worked for Bethesda and their game plus DLCs aka static, fixed and predictable load order, but it doesn't work for modding. At all.

 

 

How does this work with the scrapping system? A mod like Scrap Everything would be causing problems everywhere- wouldn't it? Must have disabled pre-combination like you said. I don't use the mod myself as I had heard of issues. I use something similar though that sets up a workshop area anywhere. Like you said adding to world-space seems to work fine. But scrapping outside intended areas causes problems and sometimes CTDs. The amount of variables to consider for altering a significant amount of content is staggering to say the least.....and then in combination with a rather lengthy load list it is a wonder that the game works at all. If nothing else, the game is certainly more stable than say Skyrim.