Jump to content

Fallout 4 Optimization and Performance Systems Explained


Recommended Posts

Thats interesting about issues with narrow gaps - is this a generic fault in the previs system or just a bug in 'our' version of the CK?

I don't remember seeing any such problems in the base game's Previs (though I may just have ignored it as 'yet another game bug')

I think it's a vanilla bug, you can see the gap bug in many places around the commonwealth (like Diamond City ext, behind the columns)

Link to comment
Share on other sites

  • 5 weeks later...

 

Thats interesting about issues with narrow gaps - is this a generic fault in the previs system or just a bug in 'our' version of the CK?

I don't remember seeing any such problems in the base game's Previs (though I may just have ignored it as 'yet another game bug')

I think it's a vanilla bug, you can see the gap bug in many places around the commonwealth (like Diamond City ext, behind the columns)

 

In my experience when dealing with these narrow gaps, I think it's floating point related calculation errors. Known issue with the CK, and I'm trying to patch them as I see them. (The refs usually just need a subtle nudge to work around it.)

Link to comment
Share on other sites

I hope this is the right place to ask. I'm currently working on a rather large interior cell, we're speaking >7000 objects, with some custom NIFs. I planned the whole layout with previs and precombines in mind and when it was time to do generate my first precombines for the cell, the CK just crashed. Is there some kind of way to tell which NIF might be the problem? Is there some kind of precombine generation log where I can see which NIF or group of NIFs it was processing when it crashed?
Link to comment
Share on other sites

I hope this is the right place to ask. I'm currently working on a rather large interior cell, we're speaking >7000 objects, with some custom NIFs. I planned the whole layout with previs and precombines in mind and when it was time to do generate my first precombines for the cell, the CK just crashed. Is there some kind of way to tell which NIF might be the problem? Is there some kind of precombine generation log where I can see which NIF or group of NIFs it was processing when it crashed?

Unfortunately it comes down to a binary chop approach.

It will be a mesh that causes the issue, and 99.99% chance it is a new mesh you added (the F4 base game ones are normally reliable).

The log will only display things that worked - so any reference (and thus it's mesh) that is listed can be excluded as a problem too.

That, and only precombineable References will cause the issue, should reduce the number of references you need to check.

By binary chop I mean remove half those new meshes from the meshes directory - try the precombine phase again (just use the CK GUI - it's quicker for testing one cell) and see if it crashes. Repeat.

 

I am assuming the crash occured in the Precombine phase. If it is Previs phase - so much harder!!!

Link to comment
Share on other sites

 

I hope this is the right place to ask. I'm currently working on a rather large interior cell, we're speaking >7000 objects, with some custom NIFs. I planned the whole layout with previs and precombines in mind and when it was time to do generate my first precombines for the cell, the CK just crashed. Is there some kind of way to tell which NIF might be the problem? Is there some kind of precombine generation log where I can see which NIF or group of NIFs it was processing when it crashed?

Unfortunately it comes down to a binary chop approach.

It will be a mesh that causes the issue, and 99.99% chance it is a new mesh you added (the F4 base game ones are normally reliable).

The log will only display things that worked - so any reference (and thus it's mesh) that is listed can be excluded as a problem too.

That, and only precombineable References will cause the issue, should reduce the number of references you need to check.

By binary chop I mean remove half those new meshes from the meshes directory - try the precombine phase again (just use the CK GUI - it's quicker for testing one cell) and see if it crashes. Repeat.

 

I am assuming the crash occured in the Precombine phase. If it is Previs phase - so much harder!!!

 

Thank you for your input. Where do I find said log? I already checked any folders and text files that looked like something that could contain a log without any success. And I find it weird that Bethesda implemented it that way. It doesn't really sounds that helpful, lol. Anyways, I'll give it a try.

 

Regarding the binary approach: That's what I already had in mind, I just wanted to avoid doing it because it's actually quite a few meshes, but I guess I've no other choice other than just going with room bounds.

Link to comment
Share on other sites

 

 

I hope this is the right place to ask. I'm currently working on a rather large interior cell, we're speaking >7000 objects, with some custom NIFs. I planned the whole layout with previs and precombines in mind and when it was time to do generate my first precombines for the cell, the CK just crashed. Is there some kind of way to tell which NIF might be the problem? Is there some kind of precombine generation log where I can see which NIF or group of NIFs it was processing when it crashed?

Unfortunately it comes down to a binary chop approach.

It will be a mesh that causes the issue, and 99.99% chance it is a new mesh you added (the F4 base game ones are normally reliable).

The log will only display things that worked - so any reference (and thus it's mesh) that is listed can be excluded as a problem too.

That, and only precombineable References will cause the issue, should reduce the number of references you need to check.

By binary chop I mean remove half those new meshes from the meshes directory - try the precombine phase again (just use the CK GUI - it's quicker for testing one cell) and see if it crashes. Repeat.

 

I am assuming the crash occured in the Precombine phase. If it is Previs phase - so much harder!!!

 

Thank you for your input. Where do I find said log? I already checked any folders and text files that looked like something that could contain a log without any success. And I find it weird that Bethesda implemented it that way. It doesn't really sounds that helpful, lol. Anyways, I'll give it a try.

 

Regarding the binary approach: That's what I already had in mind, I just wanted to avoid doing it because it's actually quite a few meshes, but I guess I've no other choice other than just going with room bounds.

 

when you say it crashed...Where you doing it in a cell by cell or loaded area ?.. I had this issue a few times and in most cases it was a scol with a window/glass etc....... So i backed up my esp and I went building by building in the problem cell deleting the whole building and trying again and again... When i narrowed down the buildings to the problematic one i started doing it floor by floor and finally object by object... MANY reloads with the backed up esp where involved :tongue:...

Edited by greekrage
Link to comment
Share on other sites

when you say it crashed...Where you doing it in a cell by cell or loaded area ?.. I had this issue a few times and in most cases it was a scol with a window/glass etc....... So i backed up my esp and I went building by building in the problem cell deleting the whole building and trying again and again... When i narrowed down the buildings to the problematic one i started doing it floor by floor and finally object by object... MANY reloads with the backed up esp where involved :tongue:...

As I mentioned, I did it in an interior cell. And yes, finding the culprit by a process of elimination is probably my best chance at this point.

Link to comment
Share on other sites

 

when you say it crashed...Where you doing it in a cell by cell or loaded area ?.. I had this issue a few times and in most cases it was a scol with a window/glass etc....... So i backed up my esp and I went building by building in the problem cell deleting the whole building and trying again and again... When i narrowed down the buildings to the problematic one i started doing it floor by floor and finally object by object... MANY reloads with the backed up esp where involved :tongue:...

As I mentioned, I did it in an interior cell. And yes, finding the culprit by a process of elimination is probably my best chance at this point.

 

One more thing to check...

Make sure you have sufficient memory available before you start.

I say this because i noticed you said something about a lot of objects.

Imagine i have 16GB and sometimes CK crashes just by moving around in the cells im doing because i have many objects with a high poly count... Leaving me with less than 10% ram .

So i have to close down anything eating up memory like a browser or even nifskope if i have too many objects open in it...

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...