El_Rizzo
-
Posts
87 -
Joined
-
Last visited
Everything posted by El_Rizzo
-
Just wanted to report a possible bug with xLODGen 51 which is still present in 53. I was creating new object LOD for Fallout 4 and when I went into the game to check I noticed that all the pine tree LOD models were missing their textures, but once I got closer the none-LOD textures were loaded just fine. I'm using Boston Natural Surroundings and the LOD source files that it provides. I tested both with beta 51 and 53, both times the generated texture atlas did not contain the pine tree textures added by the LOD source files of BNS, previous versions of xLODGen were able to add these files onto the atlas, but sadly I deleted them after updating to the current xLODGen version. I double checked to make sure the source files were enabled in MO2 and I did several runs, same results each time, logs didn't contain any errors that would indicate such problems. -
You can always reduce your settings to speed up the process for testing or only create LOD for a chunk instead of an entire worldspace, that way you can test very fast.
-
Good to know and glad I was of some help.
-
I just wanted to report that something seems to be wonky in 0.43. I created Terrain LOD with 0.43 the other day and when I did a short check I noticed that almost all diffuse texture files look like this: dlc03farharbor.4.-1.1.dds or at best like this: dlc03farharbor.4.-1.17.dds Whereas the same exact files look like this in 0.42: dlc03farharbor.4.-1.1.dds and dlc03farharbor.4.-1.17.dds There were no error messages during generation and the log didn't contain any errors either. These results can be reliably reproduced and the only change was the version of xLODGen being used, I didn't change/update any mods or changed my version of Mod Organizer 2 and I didn't change any settings within xLODGen as well.
-
Yeah, well I'm already using the ones from NeuralLOD since I can't use the prebuilt ones, hence why I was trying to rebuild my LOD and came upon the issue with BNS :)
-
Ah okay, I figured it was something like that, but wasn't sure since I'm not an expert on these matters (by a long shot ) and wanted to be sure, thanks for the explanation! The ones from BNS? Gotcha, gonna take a look at them, thanks once again!
-
So correct me if my understanding of xLODGen is wrong here, but when I run xLODGen to generate object LOD, it should generate object LOD based on my currently active, personal load order, correct? I'm asking because I can't seem to get xLODGen to generate the correct LOD atlas for my current Fallout 4 load order. The specific mod I'm having issues with is Boston Natural Surroundings (BNS) and NeuralLOD. Since I'm using BNS I can't use the pre-built LOD files that NeuralLOD comes with, but have to generate my own using the resource file it alternatively provides for such cases. However, when I run xLODGen to generate new object LOD with both mods active (as well as the rest of my load order, of course), then the resulting atlas doesn't contain the green tree lod from BNS but instead the vanilla tree LOD. This is what the atlas looks like that comes with BNS: and this is the one that xLODGen creates based on my currently active mods: I've also noticed that the generated LOD .bto meshes don't contain the trees that BNS adds to the game, unlike the files that come with BNS. I've tried with BNS's own LOD files present it its archives and I also ran xLODGen after manually deleting all the LOD files that came with BNS and the result was the same in both cases. I've used xLODGen 43 and the latest dev build of MO2, but other versions of both tools get the same result. So my question is basically, is this working as intended and xLODGen simply doesn't consider mod added/changed objects during object LOD generation or is something going wrong on my end?
-
Yeah, hence why I'm sticking with BC1 :) I considered increasing the resolution further, but I'm currently at 2048 for diffuse at level 4 and I think that is sufficient enough for me, so I'll keep it that way since Sim Settlements + a lot of texture mods manages to fill up the 11gb Vram of my 1080ti at the current settings already I'm aware, but since I'm on Windows 10 and I tested with Fallout 4 it shouldn't be a problem, unless I'm somehow mistaken.
-
First of all, thanks for the informative links, as someone who generally has no deeper knowledge about textures, this was quite interesting and enlightening (tho I won't pretend that I understood all the technical aspects ^^). As for testing the different compression methods, I created a chunk (LOD level 4, 0,0) with 888(8), 565, BC1, BC7 quick and BC7 max for both diffuse and normal maps and compared them using paint.net with up-to-date dds plugin and this is what I noticed: Aside from an ever so slight shift in some colors, BC1 and 888 diffuse textures are looking the same to me, the only notable exception for both diffuse and normal maps was BC7, which has a more grainy look to it (both quick and max) than any other format used. An example of what I mean can be seen here: 888 format BC7 max format As for normal maps, I noticed a slight degradation in detail when comparing BC1 with 8888 and again BC7 looks more grainy than the rest, tho I'm not sure if it even makes sense to compare normal maps on their own? For now I'm gonna use BC1 for both diffuse and normal textures as it seems to be the best trade-off between size and quality.
-
So this might be a dumb question, but would it make sense to use bc7 for diffuse textures as well as for normals, or should bc7 only be used for normals and dxt1 for diffuse? And what is the difference between bc7 quick and max? Is it affecting quality or just the amount of compression?
-
Your link for Beta 40 is borked, it tries to link directly to the x64 exe ;)
-
What are you on about? My message you've quoted is correct, the issue I had with version 0.38 and prior was fixed in 0.39, that isn't false data, that is a fact that I've tested and gave Sheson feedback on, no idea what you are talking about, but I certainly didn't give false data.
-
Alright, I've tested the vanilla and both DLC world spaces with bake normal maps enabled and they ran through without a single error message, so everything seems to work well now! Thanks for the fix Sheson! :)
-
Uh, that sounds interesting! Will do some testing immediately and report back to you :)
-
Okay, good to know, hope you guys have success in finding the issue :) I'm aware of that, when I wrote 'by extension' I was implying that, but it might have come across differently ^^.
-
Yes, it has no problems with vanilla archives and most mod archives either, tho I had issues with it with Fallout 4 archives before, but it was an older version which just crashed instead of giving an error message. xEdit is able to extract the files, however!, it makes them unreadable in the process. I extracted marshmuddygrass01_n from Vivid Fallout once with xEdit and once with archive2.exe and while I can open and view the version I extracted with archive2, the file from xEdit cannot be opened by the same program, in my case it was paint.net with up to date dds plugin. I tested with other files that caused errors in B.A.E. and the same thing happened there as well. So it seems xEdit and by extension xLODGen has a problem extracting these files or reading the archive correctly, right?
-
Alright, so I have some interesting observations to make. First of all, there were no errors when I ran xLODGen using loose files, so the files themselves seem to be okay (as you had confirmed on your end as well). Secondly and more interestingly, when I extracted the four BA2 archives with B.A.E. (latest Fo4 version) I got this error message while extracting Vivid Fallout: As you can see it is mostly normal maps that are causing issues, including two of the ones that I sent you (marshmuddygrass01_n and marshmudfloor01_n). I re-downloaded the mod (4k version) and got the same errors with the freshly downloaded one as well. Interestingly enough, the official archive2.exe from the Fo4 CK has no problems extracting the archives and no files are missing unlike with B.A.E. I also manually created an archive from the extracted files (the ones extracted with archive2 of course, since the one from B.A.E. were missing files) with archive2.exe (DDS format, default compression, rest on default) and B.A.E. had the same errors with this archive. So I assume that there is some issue with how these archives are being read by xLODGen the same way that B.A.E. has issues?
-
I already tried with size 32 for diffuse and normals for all levels and mesh quality 30 to speed up the process and get to the warnings faster and the result was the same. Yes, I extracted the 5 files and that is when suddenly other warnings cropped up. I'll try with just loose files to see if that gets a different result and report back to you.
-
@Sheson Did you have a chance to look at the normals I uploaded for you? Did you find anything unusual with them?
-
Not sure what you mean by "one version of each different format", but I uploaded the 6 (forgot one yesterday when I said 5, derp ) normals that were causing the initial errors, hope that is what you meant, if I misunderstood you, please let me know. Here you go: https://www46.zippyshare.com/v/IvpzDQHe/file.html The mods that these files come from are: Rubbles and Trashpiles HD Quarry HD Vivid Fallout All-in-One Fo4 Landscape Overhaul HD
-
Yes I'm using MO2, tried 2 different versions with the same result. OS preventing access does seem very unlikely since these textures are stored in archives and the rest of the archive's content is apparently accessible, or can Windows block individual files within archives? Aside from that, recent builds of MO2 are specifically checking all mod files for access when a 3rd party program is being run through it and fix any issues that arise. As for Antivirus, I'm only using the integrated Windows Defender and I specifically excluded my MO2 as well as my game and xLODGen directories. No, with purely vanilla textures it doesn't happen. My main issue isn't that there are 5 normal maps that apparently can't be read, but that when I remove the 5 files in question that suddenly a whole bunch of new errors appear that weren't there before, which strikes me as rather strange. I can provide you with the 5 initial files and from which mods they came from if you want to take a look at them. Yeah that explains why I don't get errors when de-selecting bake normals, makes sense. Thx, good to know! :)
-
One additional observation to my previous report, it seems that only when I tick the box for backing normals that the warning messages appear, I've tested without that box being ticked and xLODGen finishes without any warnings, in case that might help.
-
I ran into some weird issues while trying to create LOD for Fallout 4 using version 36. While xLODGenx64 was running and generating texture files, I noticed several warnings about an error reading a few normal maps, 5 different normals to be specific. After xLODGen had finished I checked the log and tracked down the mods that provided the 5 normal maps in question and temporarily removed those 5 files to see if xLODGen would then run without warnings. To my surprise however, I got a whole boatload of new warnings about normal map reading errors from files that I didn't get any warnings from before and the program grinded to a halt while throwing whole pages of errors, forcing me to kill it with the task manager. Putting the 5 files that originally caused warnings back into their respective mods didn't reverse the situation though, when I ran xLODGen afterwards it still gave me tons of errors about the other normal maps that ran fine the first time... Since all my mods are packed into BA2 archives I also tried to extract the 5 normals in question to see if having them loaded as loose files would have any effect, but that didn't change the situation either. Any idea why removing the 5 files that initially caused errors suddenly created a lot more and causes the program to hang up? Also, where does xLODGen save its settings? I want to reset it to its default settings but simply deleting all the files and reinstalling it doesn't reset my manuall settings.
-
Since 0.35 doesn't require to be run in admin mode anymore the issue is fixed, MO2 only had issues when an application required admin rights to run, but even that has been fixed by LostDragonist already, tho it hasn't made it into a new build yet, but the updated exe can be found in the testers channel.
-
Alright, I've tried with a shortcut that gets executed in MO with the shortcut's target line looking like this: "J:\Tools Updates usw\Patches & Mods\Fallout 4\xLODgen\xLODGenx64.exe" -fo4 -o:"F:\FO4 LODgen Output\" and now the output goes straight into my overwrite folder, am I missing something or should this work and MO2 has another problem?
