PRieST
-
Posts
212 -
Joined
-
Last visited
-
Days Won
1
Everything posted by PRieST
-
I'll download it again today and let it run. Only Tamriel will work here? (save a bit time for testing) After it's done, I'll report back. Or could the version number be checked anywhere?
-
I was sure I clicked *select all* worldspaces to generate lod with dyndolod... But ok, as These worlds are missing, is it enough to Update the plugins with only selecting These two worldspaces?
-
Found this in the FAQ: I am using Alpha 22.The SKSE folder is there, with all the files. The message itself seems to point to a missing world - it want's to find the world 'none' ? DynDOLOD_Worlds.txt DynDOLOD_Worlds.json These two files look fine to me? PapyrusUtil Log (is loading the .json) Bunchofnumbers is also correct (I looked it up in the MCM first...they are identical) Haven't changed anything concerning PapyrusUtil (with alpha 20 I didn't hat this error)
-
I created DynDOLOD from scratch (changed something in my loadorder and so I thought it was the best to rerun it). Everything seems fine, no errors, all was genereted. But DynDOLOD won't be enabled on Dragonsreach Porch...I only get following error message: 'DynDOLOD can not find master data in DynDOLOD_None' 'DynDOLOD can not read data from DynDOLOD_None' And because of this, DynDOLOD stays deactivated as soon as I am in this cell. I haven't had this error when I posted the screenshots about the grass billboard colors. As mentioned above, I changed my loadorder, but I also did the whole LOD generation process from scratch. Only change is I swtiched from alpha 20 to alpha 22. DynDOLOD_SSE_log DynDOLOD_SSE_Debug_log
-
Just load it into ck and save it, this should solve it. Had to do the same. The record which is causing this error has to do with the navmesh. This error has to be fixed by the author.
-
Forgot about that option, will test around a bit, thanks again for your help.
-
Thanks for your answer, maybe I'll play around with it, but I don't think it's worth the try, because it's very dependent on weather/lightning. Anyway, if I reran LODgen again, as mentioned in your second post, I'll only have to generate the grass LODs for testing different settings? May be plain obvious, but I wanted to be sure about this.
-
Grass LOD generation and the rest worked out fine now, but I noticed a slightly color variance between full model grass and LOD grass (sometimes depending on time of day and weather conditions) these are some examples where it is very noticible (seen from dragonsreach great porch - so from a child world to tamriel worldspace): Generated grass chache, genereated lodxgen billboards and than dyndolod. TexGen generation was with standard settings. Logs: DynDOLOD_SSE_log DynDOLOD_SSE_Textures_Used_Tamriel DynDOLOD_SSE_Object_LOD LODGen_SSE_Tamriel_log DynDOLOD_SSE_Tree_LOD From Export folder: LODGen_SSE_Grass_Map_Tamriel LODGen_SSE_Textures_Used_Tamriel LODGen_SSE_Object_Atlas_Map_Tamriel As mentioned before, as TOD or weather seems to compensate it sometimes, I don't think it makes sense to play with brightness/colors in the settings of LodGen, but maybe I am wrong. Also I am using an ENB so it's even more visible (but still there/visible if ENB is disabled). Sometimes it looks way off and on other times in blends in perfectly, so I'll leave it. I do have read, that this was mentioned before, so my conclusion is: It is as it is, due to the different lightning of the grass LOD, right? But I still wanted to post it, because maybe it helps you to find something what could be done about this. I had no errors while generating everything, so no error logs were created, do you need something more?
-
Now that I saw the grass ingame: Wow! Thanks for your help, even if somebody like just not always doing this: RTFM Now I'll look araound how to make the 'almost perfect' balance between performance and quality. I had no problems (beside the selfmade ones, which were all solved) with DynDOLOD 3 Alpha 20 in genereting LODs, Hybrid 3D trees or grass billboards.
-
Thanks again, and sorry, I indeed haven't read the second post good enough. So I'll recalculate the grass object bounds, that seems to be the thing.
-
Ok, maybe I'll have to generate again, to get the logs back, so they could help. Beside that, the '\textures\terrain\lodgen\TexGen_[GAMEMODE]_[Tree|Grass]_Billboards.txt' looks like this and I don't know, but I think there are too many 'False' in it, but I don't know why: And this seems to confirm it '\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Grass_Map_Tamriel.txt': Ohh...wait...Alpha 19 had difficulties with reading billboards from bsa, right? I have most of the grass.dds files packed in .bsa Yep, checked again, the 5 billboards which are in use are those, which are loose files...ok, so unpacking files and let it run again.
-
Create custom hybrid 3D trees for SFO:s trees?
PRieST replied to Southman's question in DynDOLOD & xLODGen Support
Vurt has also released hybrid 3D Tree LODs...you can these also download under optional files, did you just overlooked it? -
I know this may be a dumb complain, because I don't have the logs anymore. I wanted to test the new grass LOD feature with DynDOLOD 3.19, everything went through and I got no errors, these are the steps I did: 1. Tested on a New Game (coc command from mainmenu), to be sure whatever is in my savegames, doesn't matter 2. Genereted Grass Cache from 'No Grass in Objects' with following settings 3. Genereted LODs with TexGen64 with these Settings: 4. I made the following Settings inside the DynDOLOD_SSE.ini 5. I let DynDOLOD do it's work with following settings (loaded 'High' rules): 6. I generated Occlusion with LodGen After these steps I teleportet from mainmenu to 'coc whiteriverwatchexterior03' and I just have this result: If I change the setting in 'No grass in objects' to DynDOLODGrassMode = 1 I get this: With set this to 0 I have the normal grass fading. I know I know, I can't give you the logs, but if I would do this all over again, which logs do you need, to see what happened, that I don't have any grass LODs (in the Texgen output I have the grass/tree billboards)
-
Those were files from HD LODs Textures SE, for example. And some other mods, but it's ok, I leave these files unpacked. Thanks for your answers. I'll let DynDOLOD work again. I don't wanted nor have I packed files from TexGEN Output or DynDOLOD itself.
-
Ok, thanks, will try this out. Another questions: With version 2.87 it didn't matter if 'textures\terrain\lodgen\[worldspace]' was loose or packed in a .bsa archive. With version 3 I got erros because of 'texturename_RefID.txt' was missing. After I unpacked the corresponding files everything worked as it should. So, I think this is your intention, but I wanted to ask why (Now that I know, it's ok, so I let the files being unpacked)
-
I'll run it again, in version 2.87 the command window of lodgen64.exe was running till the and, but now it seemed that there was no progress at all, so I got nervous. My bad :/ Ok, I still posted in the other one the error. For now I'll keep a 'clean' copy of the plugin from Immersive Armors for generating LODs as I won't change it for actual gameplay and as it never was a thing before version 3.
-
I just used DynDOLOD 3.18 and the only thing I have to complain about (all other aspects were due to errors made of myself) is this: If you're using Immersive Armors and decide to let the config spell being removed (via MCM menu), there are some records/entries inside the plugin 'deleted' which leads to 'unresolved errors depending on [refID]'. I relate to this (checked for errors via xEdit and also the same error why dyndolod will not work further) It may be the wrong way to get rid of the config spell, but as this is an 'intended' error, would it be possible that DynDOLOD can ignore this one? I had to redownload the whole mod again, to get the plugin where the entries weren't already edited or it would not have been possible for me to create the LODs at all. Also, does the LOD generation longer in the background? Everything seems finished (no plugins are in the output folder at the moment), but I think something got stuck? This is the picture I have since 30 minutes now (RAM usage was 11GB at and is fallen down to the value seen in the picture and is starting to get higher again) Edit: As there were no Logs with any errors inside it beside 'aborter by user' as I closed the LODGEN64.exe, I start over and will do Tamriel worldspace alone and at first.
-
Yeah, sure, I'll use this fix the next time I have to rerun DynDOLOD. I just wanted to look for an solution where only the giant fires/everything effecting the glow of the giant fires had to be edited. Every other (fake)glow looks normal/less intrusive to me, so with your fix I'll reduce their visibility, too. But I think this will be the lesse evil.
-
I thought it were LODs, because if you are coming closer the glow disappears. But I'll make it a topic at the volumetric mist site. I appreciate your help though, thanks for that.
-
So I tested a bit further. Deleting or editing the records inside DynDOLOD.esm/esp doesn't change anything ingame. I even tried to edit the original glow, which is coming from ELFX - Exteriors, but this huuge glow is still there. I can't find any references inside DynDOLOD which points to volumetric mists, so there I can't do anything. I made some screenshots of the 'talking rocks camp' where I had to delete 5 or 6 'misttest_1.nif' meshes until I even could see the 'FXGlowFillRndLitBrt.nif' (which infact isn't causing the bright, huge glow, as I disabled it with a little patch, and loaded the save again, the little glow was gone, but not the huge one. I haven't any more ideas, so I think I'll let run DynDOLOD again with the suggested setting by Zanderat.
-
Ok, wanted to try it, but I think I found whats causing the bright shine (at least in my case): It's because of VolumetricMists.esp with it's 'misttest_1.nif'. I deleted all of them around a giant fire and the glow was gone, I deactivated the plugin itself -> no bright shine. So I think only workaround for this will be 1st Deleting volumetric mists or 2nd edit the DynDOLOD_SSE.ini to reduce the brightness of all the fakelights and see if that helps or 3rd delete only a few records from volumetric mists, but as it are only about 25 records or so all in all that would destruct the whole sense of that mod.
-
Will try this the next time I'll run DynDOLOD. Ok, maybe I edited the wrong records as I saw no difference ingame...or maybe I did something wrong. I copied one of the 'fxglowfillrnd' records inside the DynDOLOD.esm (first I created a copy of one of the meshes to make use of it for the giants) and pointed the record to my 'new' mesh. After I've done this, I searched for the 'sleeping tree camp' record (I took a look at the 'referenced records') and there I set the 'new' base record. After doing so I had to save both files (DynDOLOD.esm and .esp). But afterwards I think I edited the wrong records/meshes, because the orange glow is applied by one of the 'fxglowdefault_dyndolod_lod.nif', isn't it? So, where can I find the records which make use of these meshes (in my case it has to be 'fxglowdefault6_dyndolod_lod.nif' as the 6 was set in the DynDOLOD_SSE.ini in the last run)?
-
I let DynDOLOD ran a second time and there were no errors and the same with creating occlusion data via xLODGen. But I habe another question about fake lights: Is it somehow possible to just disable them for giantfires? I know I could reduce the brightniss of the FXGlow mesh inside the DynDOLOD_SSE.ini or edit the meshfiles (in resources) direct per hand or I just could disable all fake lights. The reason I ask explicit for the giant fires is, because the fake light on these look so off...they are too huge/bright. And I don't want to mess around with the settings, cause the rest of the fake light glow lods look just fine. ENB off: ENB on:
-
I had never a problem with it before, while it was 'inside' the Skyrim folders (cause Skyrim is installed on an SSD), but I'm going to put it into another folder/partion/hdd or ssd. Yes, that was given. I'll try this and will look up whats possible messing up with the pagefile -> it is and was managed by windows. Edit: Seems, that it has to do with Occlusion calculations. Disabled them in the DynDOLOD_SSE.ini and DynDOLOD run through it. After that I calculated them via xLODGen which worked out as intended Although There were 3 messages about *.bto files which could not be loaded -> out of memory. but xLODGen finished the process wihout any further errors or problems and created the occlusion.esp.
-
Ok, so I wanted to let rerun DynDOLOD SSE (2.82 with newest Resources available on Nexus) with ne new update of Majestic Mountains 3.10, but everytime I let DynDOLOD run nearly at the end of the process I get those erroer: DynDOLOD SSE Log: https://pastebin.com/ZtgDWVNU Bugreport: https://pastebin.com/FJeZyNeV I tried many different things (unticked the 'bashedpatch.esp' before starting DynDOLOD - through MO2, do one Worldspace after another - the error mostly does come up with the generating of the tamriel world, closing every other background processes which are not needed to have more free RAM - I use 16GB DDR4) and I don't know what to do. Sometimes it does went right through, but as it takes more or less 45 minutes everytime I let it run, its very annoying. I hope that there is a mistake on my side, so it will be easy/fast to 'fix' and if not, I hope someone or Sheson has any idea whats causing this.
