529 replies to this topic

[VIitS]

 

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.

 

You can't scrap a precombined object (and many precombined objects have associated occlusion data stored in the .uvd file), so Scrap Everything (and Spring Cleaning before it) just disables it, but only for the cells in (or near, for previs) the vanilla/DLC settlement cells. The only problem this causes (for exterior cells) are to be expected when you disable performance optimization measures (i.e. reduced performance, mainly only noticeable for Bunker Hill and to a lesser extent Hangman's Alley). This means no occlusion issues, and the only mods you'd need to make a patch for are the aforementioned lighting mods. For everything else, it acts as a sort of lazy compatibility patch.

 

You do want to be careful scrapping in Hangman's Alley though, Bethesda didn't really make a full landscape there, so scrapping certain parts of the surrounding buildings will let you see below the ground (to the secondary ground layer far below). No weird trailing like you get with the Void though.

 

And, as mentioned before, disabling previs reveals Bethesda's lazy room bounds/portals system underneath, so for interior cells you have to either regen the previs or fix the room bounds/portals. SE's first attempt at regening previs/precombineds for the interior DLC settlements seems to be hit or miss (works for some, not for others), but we will be attempting to fix that once we get the other planned features working.

[Madcat221]

Is there any procedure to regenerate precombs and previs for interior cells that doesn't result in huge file dumps?  The vanilla precomb pile for Vault 75 is only 8 MBs or so, but what I get generated is over 116 MB. I'm trying to regenerate precomb/previs data after a mod that replaces overseers' desks in vaults with proper classic ones essentially disabled those systems and brought framerate to a crawl in at least Vault 75.

 

These precomb meshes I'm trying to generate also seem to be malformed in NIFSkope; there's huge slews of orphaned data sub-blocks.

[VIitS]

Is there any procedure to regenerate precombs and previs for interior cells that doesn't result in huge file dumps?  The vanilla precomb pile for Vault 75 is only 8 MBs or so, but what I get generated is over 116 MB. I'm trying to regenerate precomb/previs data after a mod that replaces overseers' desks in vaults with proper classic ones essentially disabled those systems and brought framerate to a crawl in at least Vault 75.

 

These precomb meshes I'm trying to generate also seem to be malformed in NIFSkope; there's huge slews of orphaned data sub-blocks.

 

No idea if it would work, but if you want to try:

1) Generate the new precombineds/previs for the cell

2) look at the new cell verse the old in FO4Edit, note the new precombined meshes* (don't change anything)

3) delete all but those meshes from the precombined\YourMod folder

4) Check to see if the precombined meshes still work in-game (if you don't have the bUseCombinedObjects=0 ini edit, trying to select a precombined mesh in-game should give you a message about a non-ref object)

 

If that doesn't work, then the game requires the precombined meshes to be in your mod's folder. Looking at the Automatron .ba2, I think it should be fine though. It seems to only put precombineds into a separate folder if the cell they go in is created by a different plugin, and the DLCRobot.esm ba2 only has a handful of the precombined meshes for the vanilla cells it touches. So it looks like the vanilla way it handles precombineds is to only include changed ones, so the above method should work, I would think.

 

Anyway, if it doesn't work even though it should, extract the vanilla precombineds for that cell (all the meshes that start with 000c01a7. Don't extract all precombineds for the whole game into a single folder, or you will trouble deleting the folder, or even searching it) and copy them into your mod folder. Since they are smaller, that should help with mod size. 

 

Not sure what to tell you about them being malformed. I took a look at a vanilla one, it is structured somewhat normally (although the base NiNode just has a second NiNode as a child, and everything is within that second one), but when I looked at the ones generated for Scrap Everything (Vault 88 and Mechanist's Lair), they were the same as yours. That might explain why so many people can't get it to work (having seen the nifs, I'm surprised it works for anyone). I'd guess that probably means the system is broken, and the only way to do it right now is to look at how the vanilla ones are structured, and fix the generated ones manually (especially the flags on the NiNodes, which probably are affected by the things that make them up, both meshes and object types). And I'm not even sure that would work. Nevermind, the orphaned nodes have no info, and there is a missing BSPackedCombinedCharedGeomDataExtra block. So you have to track down a vanilla precombined mesh that included the original mesh, get some info from that, and also figure out what needs to be changed for the precombined you need. I'll think about making a guide on that, but with how much work it would be I doubt it would be worth it, considering how many you'd need to fix for the average cell.

 

F*** you Bethesda, F*** you very much.

 

 

*Top of the XCRI field, the list of .nifs

[VIitS]

Is there any procedure to regenerate precombs and previs for interior cells that doesn't result in huge file dumps?  The vanilla precomb pile for Vault 75 is only 8 MBs or so, but what I get generated is over 116 MB. I'm trying to regenerate precomb/previs data after a mod that replaces overseers' desks in vaults with proper classic ones essentially disabled those systems and brought framerate to a crawl in at least Vault 75.

 

These precomb meshes I'm trying to generate also seem to be malformed in NIFSkope; there's huge slews of orphaned data sub-blocks.

To update: what I would recommend:

1) Copy the XCRI data from vanilla into your mod (you need the new PCMB data, I think you can use the vanilla VISI data, as the desk shouldn't be part of it, but it shouldn't matter as long as your .uvd file works)

2) find the precombined mesh that contains the desk (info should be visible in FO4Edit when you go to the Placed Object reference for it in Fallout4.esm)

3) Remove that precombined mesh, and find all mentions of it in the "references" part of the XCRI field and delete them

 

Based on my testing, this should disable the precombined mesh for the desk (and anything else in the same precombined mesh), but still use most of the precombined meshes, and still use the previs info. So the performance impact should be unnoticeable, and it should use the different mesh you want.

 

 

More generally: 

 

To update after way more testing than I should have done today: those funky-looking precombined meshes still work fine, they are just a lot bigger. Nifskope can't read them properly (it required an update to read precombined meshes when FO4 first released), but the game can. The problem with Scrap Everything is related solely to the previs file.

 

You would want to use the updated CellID_physics.NIF, that contains the collision data for every single precombined mesh in the cell, so using the old one would use the old collision data. And if you really want, you can edit the vanilla precombined nifs to remove things (visibly, as I said collision is all one nif), but that requires you figure out what info matches up to what placed object. As far as I can tell, it doesn't actually stop any part of the combined meshes from rendering, though it would need more testing for me to be certain. I couldn't find any instances of parts of a mesh actually not being rendered. Maybe the game can handle the data more efficiently wit hit in the format, but there didn't seem to be any vertices or polys that weren't being rendered.

 

tl;dr, you can pick and choose what precombined meshes you want to use, but you have to delete both the mesh and the references that point to it from the cell data (and need to use updated timestamps if you want to use different previs data, and possibly even if you just want to edit the precombineds)

[Zzyxzz]

Hello, i just checked my loadorder for mods that disable pre-combined meshes and i found something else:

 

VISI - PreVis File timestamp

 

There is a mod that adds a MK14 to DiamondCityOrigin. This change was done before the Far Harbor DLC and now provides a conflict.

 

Timestamps:

Fallout.esm -> 24 1F ; DLCCoast.esm -> AD 20 ; MK14 -> 24 1F

So the MK14 carries over the vanilla PreVis File timestamp and overwrites the new one by Far Harbor.

 

Now the question: What does this mean for the PreVis files?

 

Edit: It does not break the precombined meshes. I verified that with the TPC command / the Precombined Mesh Timestamp is still the vanilla and DLCCoast also uses it.

[Giggilyomeromicon]

I haven't quite been able to figure out what the PreVis timestamp means, other than deciding which PreVis files get used when there are two conflicting sets present.

[VIitS]

I haven't quite been able to figure out what the PreVis timestamp means, other than deciding which PreVis files get used when there are two conflicting sets present.

As far as I can tell, this.

 

Also, it's involved with the game deciding whether or not your mod referencing a precombined mesh should break previs/precombineds. Not exactly sure the specifics, but I am 99% sure that if your timestamp matches your mod's edit date, you'll be fine.

 

 

Hello, i just checked my loadorder for mods that disable pre-combined meshes and i found something else:

 

 

So the MK14 carries over the vanilla PreVis File timestamp and overwrites the new one by Far Harbor.

 

Now the question: What does this mean for the PreVis files?

 

Edit: It does not break the precombined meshes. I verified that with the TPC command / the Precombined Mesh Timestamp is still the vanilla and DLCCoast also uses it.

 

At a guess, it means the game will use the original vanilla (i.e. not the DLC) previs. This should be fine as long as they only added things, and didn't remove any previously occluding objects. Although it would also have the PCMB (precombined) timestamp for vanilla (and more importantly, the XCRI data from vanilla), so presumably it would use the vanilla precombineds. So you're fine unless one of the vanilla precombineds blocks something placed for Far Harbor.

[Giggilyomeromicon]

I'm fairly curious as to what would happen if you changed the RVIS tag of a cell to belong to a different cell. If it worked in such a way that you could change the RVIS tags for the cells edited by a mod, tie them to a cell off in the ocean or something, and then generate a previs file for them, that would be very useful.

[VIitS]

I'm fairly curious as to what would happen if you changed the RVIS tag of a cell to belong to a different cell. If it worked in such a way that you could change the RVIS tags for the cells edited by a mod, tie them to a cell off in the ocean or something, and then generate a previs file for them, that would be very useful.

 

Based on what I know, nothing in the cell would have previs , and either the same would happen for the surrounding cells (i.e. it'd be like previs was disabled), or everything outside your current cell would be treated as if it was blocked (i.e. it would disappear, and reappear as soon as you left the cell).

 

If you are talking about generating previs for the cell as normal, then changing the name of the .uvd file to that of a cell in the middle of the ocean, it would probably act the same as if you edited the cell record and told it to not use the previs from the cell it normally would. This would either work fine, or cause the same occlusion issues I mentioned at the cell border (or break previs completely), I have no idea.

 

Feel free to test it, but I wouldn't recommend implementing it in a mod.

[SMB92]

I had intended on making a thread about my findings into this system, but seems here we all are. Good that it's getting out there for all to read. 

 

I believe the Previs system is fine on it's own, as it's easy enough to just turn it off, yet provide the biggest boosts in the heaviest areas.  If it were completely dynamic it would be really good, but I think that it would require too much calculation given the sheer time it takes just to generate UVD files to begin with. Possibly if it were implemented on it's own thread that worked directly behind the main thread before GPU handoff, but I can see instability written all over it. Maybe with the likes of low level APIs this can be a possibility in future. Bethesda should have never jumped on it this early. Ambitious alright.   

 

In case this isn't known, I have been able to determine that your previs only loads one UVD file at a time, for the 3x3 grid your in. Every object that has calculation stored in this UVD file acts as an occlusion box for everything beyond it, this in itself is not a bad idea as a system. Unfortunately it relies on the cell data not being changed much like your precommed meshes but at least has some level of potential to becoming dynamically implemented.  

 

Precommed meshes on the other hand, they f*** modding completely, given previs can't really be made without them. And as it was mentioned earlier in this thread, Bethesda have based interiors very much around them.  I haven't played with interiors much but I had an understanding you wouldn't need portals/bounds with properly generated precull data, but what fuckery that is. 

 

 

Now I'm not sure if it has been clarified just from a couple posts I saw here, but any mod that contains only ITMs of cell data, and does not pre-date DLC, has no problem now loading in. Precoms and Previs work fine. Obviously only when a reference that is precombined is poked it will disable.

 

Another point I saw was about the timestamps, they are more or less just markers to tell the game the old data has been updated, and to point to the new data with that timestamp. This is in accordance with the last, overriding mod loaded, so you can have multiple BA2s with existing new data and the game will only load the ones it is pointing to. However, this is completely voided by having any precom/previs files present as loose files, given the system takes priority of loose files. 

 

ANd just to mention it in case anyone didn't notice, but if you install some custom meshes, say a SMIM type mod, and go regenerate all your precommed meshes, they actually get fully baked in. As in you can pretty much remove the original mesh from your data folder and just run with the precoms. Whether this is the main difference between our version of CK and Bethesda's, I don't know. 

 

These are my findings, hope you get something out of it. I can generate 11 ugrids of data just fine in one go these days, a PITA sure, but I've worked most of this out. BTW Thanks Bethesda for sticking that f***ing occlusion box in monsignor plaza just to piss me off, there's a couple hours of life I won't get back.