Marcurios

Yeah, i guess you're right, now i know it doesn't matter. Once you know what happens, the next time it happens you immediately know what's going on, so that's ok. It's probably better too that it shimmers if you don't provide a spec texture, atleast that way you know that something is wrong. If it would be dark gray and you didn't notice the comment in the lodgen log, you probably wouldn't know the spec is bad if it where a grey texture. So it's good as it is. Well anyway, i'm back up to speed with xLODGen again for FO4, so thanks for that. Now i can go back to making some trees again..

It's fixed now, it was indeed the spec from the trees that was missing from the atlas, it's on it now and the shimmers are gone. Now to find those pesky vanilla textures and fix them. Thanks Sheson, you saved me a lot of time figuring it out myself.

Ah, now i see what's going on with the spec and gloss, the file had a _ (underscore) too many in it so it didn't get used. But when xLODGen says it uses a flat replacement, does it than use a white flat replacement for the red and green channel ? Cause red and green are white, and blue (not used) is black, isn't it better to provide a 2x2pixel dark gray texture bundled with xLODGen and use that for when it misses a spec texture ? I also noticed that a quite a few vanilla textures have this problem going on, cause i have 6 vanilla blocks in the atlas with the same problem, and 1 actually uses a 128 color grey texture from what i can tell, the rest all have normal spec textures. i'm going to unpack all the texture archives to see which lod spec textures are missing or have a white flat one, time to fix some stuff. i have been playing the game up until now but i guess it's time to get modding again cause this kinda annoys me a bit. There is also a lot of doubled stuff on the atlas so i guess a bunch of textures that are the same have a different name and are referred to by separate meshes, so i need to fix those meshes too to save some real estate on the texture atlas so i can enhance some other lod with the newly reclaimed space.. EDIT:just noticed the diffuse has different colors, so i guess it's needed the doubled stuff. Thanks again for your help !

no, it doesn't happen with vanilla trees, even with ENB it doesn't happen. I determined that ENB makes it less when enabled, if i disable ENB it's like a lightshow. Since i already suspected it might have something to do with specular or gloss i checked the specular yesterday. So yes,I had a missing specular texture indeed for the trees, but rezised the original and renamed it to the lod variant and rendered again but that didn't fix it yet. Just woke up so now i'm going to try to darken my spec texture, cause right now it's as bright as vanilla textures, and i often find vanilla somewhat to bright to look just right. I'll also darken the gloss layer a bit to narrow the gloss.

Everything renders OK now, but i have a question, did you ever get shimmering lights on object lod after you rendered it ? Cause the trees look OK, but at certain angles i get all dancing white lights on the trees, flickering like crazy, i never seen this before in any modded game. i can't even begin to guess at what is causeing it too. I had working objectlod before without this phenomenon. You have any idea what it is and how to get it fixed ? It's not z-fighting, i know what that looks like and how to alleviate that. I't looks like bloom flashes, but it happens on dark objects (tree canopies) only, so that's not what bloom does, still, it looks like bloom flashing on and off rapidly.

OK, i feel completely stupid now, cause i did RTFM, but when it said install in a different directory i thought to myself, that shouldnt make such a big difference. But when it comes to rendering correct terrain, it obviously does...sigh..banging head against wall.. Thanks for your help Sheson, sorry to take your time needlesly..

Thanks for taking the time to reply.. The xLodgen log is too big for the allowed filesize, its almost 5 mb. It is full of texconv errors like these; 01:00] 0: VID:10DE, PID:2484 - NVIDIA GeForce RTX 3070 [01:00] 1: VID:1414, PID:008C - Microsoft Basic Render Driver [01:00] Error: Executing Texconv failure 00000001: "E:\Games\Steam\steamapps\common\Fallout 4\Edit Scripts\Texconvx64.exe" -nologo -y -aw 256 -sepalpha -f DXT1 -bc d -o "e:\games\steam\steamapps\common\fallout 4\data\textures\terrain\commonwealth" -flist "C:\Users\Marcus\AppData\Local\Temp\FO4Edit\Texconv_Commonwealth_112_0.txt" [01:00] e:\games\steam\steamapps\common\fallout 4\data\textures\terrain\commonwealth\commonwealth.4.92.-68_msn.dds [01:01] Invalid value specified with -f (DXT1) [01:01] Microsoft (R) DirectX Texture Converter (DirectXTex version) [01:01] Copyright (C) Microsoft Corp. All rights reserved. [01:01] Usage: texconv <options> <files> Maybe 1/3 of all texture converts have this error, the rest renders ok it looks like. link to the file in my onedrive; https://1drv.ms/t/s!AnB6a-bT8xxukAP_xvDO2fj4ThmM?e=tJvsCG With the suggested procedure to load plugins with the xLODGen version it's not possible to generate terrain lod, only object lod. There definitely seems to be a difference in how the program loads texturefiles depending on how you use it. If you use it as FO4Editx64 it renders object lod with loose textures fine, and you can select plugins, but it can't render terrain lod. if used as FO4LODGenx64, you have the option to render terrain lod, and you can't select plugins, but if used like this without the option to render terrain lod it doesn't load the loose files for my trees (3d object lod). It even loads completely different incorrect files for the objectlod atlas without changing anything when it comes to referenced files and where they are. So with terrain lod option enabled it renders unusable terrain dds files that make the game crash, and if you delete the terrain dds files and terrain chunks so you only have the objectlodatlas textures and the objectlod meshes left, they (textureatlas, not meshes) are completely wrong as well. Cause it does something weird with the objectlod atlas file, it takes the wrong messed up textures from i don't know where, but not from the specified referenced textures in the lod meshes and their material. (see screenshots) I have a exception in my antivirus for my gamefolders, so they don't get scanned by the realtime scanner. And both programs are in my Fallout dir, so none of the two are being handled by antivirus program. I also checked the programs set up in windows , there is no security settings on them, they have full privileges. The only thing i haven't done is set them to run as admin, should i perhaps do that ? Otherwise i can't imagine Windows messing with them programs, since all other programs i install work perfectly fine. And if i say the regular xEdit, i mean the version this xLODGen is based on, so 4.04 (i said 4.14 in my earlier comment, but i ment 4.04 ofcourse) Also, I did use the default setting for the textures, right out of the box, tried multiple times with the default settings. I don't think i made any stupid mistakes here (but you never know, not saying i'm 100% certain about that), cause i rendered LOD for FO3 and FNV hundreds of times when i made WFO, so i do know what to do when it comes to referring to textures from nif files, the only difference here is that there is a material added in FO4 that has a reference to the used textures as well, and it is referenced from within the meshes itself. I used the material with the name unchanged so i didn't have to change the path in the mesh, and also used the same name for the texture, only used them as loose files to override whats in the ba2 file of the Treesredux.esp mod that i wanted to change the leafcolor from. I also unpacked the meshes and lod meshes to see what the mod author did, but it doesn't matter if i keep tehm in the ba2 file only or also place them as loose files, i already tried that. I actually tried a bunch of stuff, so i already rendered terrain lod and/or object lod for atleast 30 times now, with the same result no matter what i do. I'm going to go over all my files once again to see if i did make some mistake somewhere just to be certain. Otherwise i'll probably forego terrain LOD alltogether. xEdit mode renders fine object lod, everything correct, xLodgen mode does not looks like, and also refuses to render usable terrain textures, meshes are ok it seems. maybe there is something wrong with the format of my terrain textures ? I think i made them al BC5 and BC7 if i'm not mistaken, i'd have to check that..

i get a consistent CTD in game after i rendered terrain LOD with the extremely experimental version of xLODGen 4.14 for FO4. The only logfile i have on this crash is from Buffout 4; E:\Repos\f4se\Buffout4\src\Warnings\CreateTexture2DWarning.cpp(60): [critical] A call to ID3D11Device::CreateTexture2D failed with error code 0x80070057. This will crash the game. If i remove the textures created for the terrain by putting them temporarily in a separate folder the game doesn't know the game starts fine with the rendered LODChunks from the terrain, ofcourse without the new textures. Also, the object LOD doesn't use the texture files specified in the lod material and lod meshes that are referred to by my esp file. the regular version of FO4Editx64 renamed to FO4LODGenx64 does use those specified textures correctly. But it can't do terrain ofcourse. Also, the ability to choose plugins that you want to enable/disable in the regular xEdit is very convenient too. having to do that all in a mod manager before you open up xLODGen is a drag, especially since i use a very rudimentary mod manager, cause all the fancy ones are more a nuisance cause they have badly written mod install routines, so i always install mods by hand, that way i'm sure files get placed in the right directories. The downside is that the simple mod manager doesn't have mod profiles you can enable/disable. So if you could implement that (enable/disable plugins on load), that would be cool. But right now, the extremely experimental version sadly doesn't produce a workable result for me. It doesn't read the loose texturefiles and materials for objects and treelod (3d treelod) it looks like, it looks like it gets the stuff needed only from the ba2 files. the regular version uses the loose files first. So i'll still have to use CK for terrain i guess.

Been testing stuff for a few days, FNV and FO3's Stutter remover suffer from the same problem, when (in the older version) bFix64Hertz = 1 or (in the latest version) GetTickCount = 1, the camera starts to drop IF your FPS is the same as your monitor's refreshrate, if they differ, the camera stays aligned at all times. If you disable the gettickcount, the camera will never go out of alignment but you get microstutter. The solution i have found acceptable for myself is to set gettickcount to 1 and set my monitor refreshrate to 50Hz, and my Fps cap (in stutter remover ini file, NOT in ENB or AMD settings !!) to 60Fps, then it's almost smooth, and you have a tiny bit of screen tearing (not really tearing but it looks like it a bit) fixed 1 cm on the bottom of your screen (more like a tiny line when you move around). I posted my findings on stutter remover site, cause Ironsights have nothing to do with it, Vanilla Ironsights animations (the ones that just adjust FOV, not really ironsights but the animfiles are named with a is suffix) are also bugged as in, the camera shifts there too, so it has nothing to do with RH's Ironsights mod, it's purely a stutter remover problem.

I have no solution as of yet, but i do know that the camera slowly shifts up or down (mostly down) and it seems related to the aiming animations, cause they hold camera position info for the guns. What i also know is that when Bethesda's gamebryo engine goes above 60 fps, you are going to get nasty bugs in the game, every single Bethesda Gamebryo game does it. So making sure the FPS never reaches 60 fps would ensure it won't happen, someone said 54 fps limiter, but 56 is also good, cause every limiter has a slight variance in framerate, so if you'd set it to 58, it would occasionally touch 60 fps, and then it can happen again. It looks to me like the animations are not completely played out and blend into the next iteration too early, but i also know that when it starts you only have to aim and move your mouse up and down and you see it drop down pixel by pixel with every move you make, and it only stops when you limit your fps again below 60, i tested it with ENB limiter, cause you can enable disable that while playing. Also, if you play for a while without limiter, after a while in first person you get smaller and smaller, but if you then go into 3rd person you see that the player's scale is ok, it's just that the first person camera has dropped. It isn't related to stutter remover, cause if you limit your fps with other software then stutter remover, it works fine too. It is most likely a Gamebryo fault, so you'd have to device a workaround for that, as in, control the position of the camera, someone like the guy from enhanced camera could probably make that happen in a fose plugin, or you might be able to edit the animations and remove the camera positioning from the animation or something like that.