sheson

Great! Just for completeness sake: with the last update I added a text file that tells you how often each LOD mesh is used to determine if the reference specific customizing makes sense from a performance standpoint TES5Edit\Edit Scripts\DynDOLOD\cache\DynDOLOD_tamriel_mesh_count.txt Generate with 'high' once and then look for the LOD mesh you are interested in. Rockcliff03 is used over 2000 times. That is already a considerable number and the reason why it is not used with low and medium settings. What if I told you that I only did the memory fix so I could finish this DynDOLO0D thing, because it needed more memory to work?

I will update the behaivor, thx for the feedback it helps to make this as painless as it can be for future users. The next update will fix the error you have about number not being a valid integer. Yes the rules really require indepth understanding. Keep in mind that mesh rules address base element, STATS etc. The mesh name always only matches the full model path and name or part there of. Because of the partial match the order matters. e.g, just 'rocks' match any directory or file having the 'rocks' anywhere in their name. A skyrim.esm;0002e2ad rule addresses references, REFR, and they always trump mesh rules. Their order does not matter. At the start ofthe script it should mention the rule, and then when it actually scans the world it should show the rule matching once it encounter the reference. Now your example of LODGen48=Skyrim.esm;0002e2ad,,,,,Unchanged,0 means to not do any LOD at all, because LOD4/8/16 and the Grid rule are all empty. Try LODGen48=Skyrim.esm;0002e2ad,Static LOD4,Static LOD8,Static LOD16,,Unchanged,1 Since there is a LOD mesh for that rockcliff it will show. The LOD mesh filename _1 defines that its defult use is LOD4/LOD8. So if you wanted it to show in LOD16 as well would need to set LODGen48=Skyrim.esm;0002e2ad,Static LOD4,Static LOD8,Static LOD8,,Unchanged,1 And just in case: the numbering of LODGen48= needs to be in perfect sequential order starting at 1 in the rules.txt file.

If static LOD changes, yes. That will be the case if you add/remove mods that add objects with LOD or if rules changes that affect static LOD. If only dynamic LOD changes then no. That is why it is asking about the overwrite. I guess it requires some experience to know beforehand if it changes. Normally always generate. Static object and tree LOD, the *.bto, *.btt, *.lst and *.dds are just files that do not affect save game, so they can always be updated without having to do anything special.

Regarding the 'already generated LODs' that is OK. It is the export file for LODGen.exe withthe object data for Tamriel (or whatever worldspace). If you say yes it will be completely overwritten with new data. Typically it is Edit Scripts\LODGen Tamriel.txt, of you click on advanced it is the file in the first field on top. I think I will move it into the cache folder as well so deleting it is easier. Should just overwrite it in wizard mode without prompting, in next version :)

Please also post last few lines of the message output in TES5Edit. You will find a copy of it in TES5Edit\TES5Edit_log.txt so you wont have to run it again I know right :)

Just delete all files in the cache folder. Copy DynDOLOD.esp.bak to DynDOLOD.esp to start from scratch. Copy and paste the last few lines of the log with the error if it persists.

I sent you a PM with an alternative link to download 1921

DynDOLOD 0.57 Updating There are some ini and rule updates, so if updating from older version delete 'TES5Edit\Edit Scripts\DynDOLOD\' directory and all its contents first. As always just overwrite everything in Skyrim data directory when updating meshes and textures etc. New DynDOLOD Worlds.pas now also creates tree LOD as part of the process. Tree and object LOD are generated in one go. Get latest TES5Edit from https://www.afkmods.com/index.php?/topic/3750-wipz-tes5edit/ Manual and videos have been updated to reflect the changes. DynDOLOD Worlds.pas now adds and uses custom rules for specific mods automatically when clicking default, low, medium or high. Check the list of compatible mods in the manual. DynDOLOD Worlds.pas now starts in a wizard mode that hopefully is less intimidating to new users not familiar with the process. The new DynDOLOD_QuickStart.html covers the wizard mode - complete with videos - to get started. Experienced users can either press the advanced button, or set Wizard=0 in DynDOLOD.ini to start in advanced mode right away. Note that meshes, textures for both tree and object LOD *AND* also the skse\plugins\StorageUtilData\*.json files are now all created in the select output path. Just as before copy or move everything from output path to mod in MO or into game data directory. See DynDOLOD-Changelog.txt for full list

I don't see any problems by just using RealShelter. Both dynamic LOD and shelter seems to work as intended. I will have to test more with the patcher and order of things. For now I would suggest not to load either mods when running the scripts. So when you run DynDOLOD Worlds.pas do not load any real shelter mods, and when running RS patcher do not load DynDOLOD.esp. Usually LOD objects don't need shelter (unless "Replace" is used on an object that qualifies as shelter, which is not the case with the default rules and its use is intended for a few animated things). Vice versa references added by realshelter are not visible objects that would need LOD AFAIK.

Just using real shelter or with the RS patcher? I only know it exists, never tested it yet, but will look into it. Whatever details you might have help.

The problem you have with the Palace is because 2E4D0 actually only exists in the town child world and not in Tamriel. In addition DynDOLOD uses some build-in logic when it scans the child worlds for new objects added by mods which will prevent it from changing most vanilla models in child worlds and their siblings in the parent world to avoid things getting messy. So whatever rules you set for it will most likely be filtered out anyways. Instead, address the Palace that is added to the Tamriel world Skyrim.esm;0007ADF8 which uses meshes\architecture\solitude\sbluepalace_lod.nif for when the cell is attached. So even when the cell is attached it will always use a LOD model for it. Worse, this is the LOD16 version and not the LOD4 version (DynDOLOD fixes it to keep using the LOD4 version) To make sure it also uses the full model for when the cell is attached, copy meshes\architecture\solitude\sbluepalace.nif to meshes\architecture\solitude\sbluepalace_lod.nif or update its base element 0008E2CE to use the full mesh Then try the "usual" mesh rules you use on Skyrim.esm;0007ADF8 Let me know if it worked or not, as I haven't tested it. This is just from top of my head :) You are right, the best option would be to create windowglow neverfades as Bethesda did with meshes\architecture\whiterun\wrbuildings\wrlodwindowglow01.nif Note the mesh rules 'windowglow' with all empty columns to make sure DynDOLOD leaves it alone

It has its own way how it is implemented, it would be difficult. First lets add the shrubs and bushes to the tree LOD. That can be done already if someone takes the time to work on billboards for them... @darksynth0 and @jbvertexx Good to read your feedback and my respects actually, because my load order is much smaller and I haven't even begun doing all the other modifications to the game mechanics like you did. I am collecting mods since over a year for my next play through... It is very encouraging to hear that the game works as expected with all the mods and patching. The next DynDOLOD update will make the process even easier, as Zilav helped to add tree LOD generation right into DynDOLOD Worlds.pas, so tree and object LOD can be generated in one go.

Most of your question are answered in the intro part at BETA - Dynamic Distant Objects LOD - DynDOLOD But no, if texture replacers are used that dramatically change landscape or buildings a compatibility options might be needed, e.g. some LOD texture might need updating to match the new looks. A COT Winter Edition option is included for example. Unless if the texture happens to be the mountainslap. Then all close LOD mountains/rocks mostly already match.

I can only speculate about the reasons, but I put my money on small memory consoles. We are on PCs with graphics cards having 4 to 8 times the memory than those consoles... Vanilla game uses the full texture strictly only in LOD4 and never in 8/16. The LOD texture version is used in LOD4. Since I created only 1 version of the meshes with the tiled textures there are no versions with the LOD texture for higher LOD levels. For some there are version with reduced polygon size but they also still use the full texture. Edit: what happens if you set LOD8 in the LOD4 column depends on the LOD mesh file name(s) (refer to manual 'How to add your own LOD models') If there is no LOD8 mesh defined, it means nothing can be used/shown Edit2: If texture memory is of concern you can use some or all of the smaller LOD textures provided in Options\textures.128\ it will reduce the dimensions/files size of the generated atlas texture. On a modern graphics card with 3 or 4 GB of memory it shouldn't matter and it all comes down to draw calls AFAIK. Then triangles. You may want to start with TES5LODGen first to get the hang of the 2 step process of generating tree LOD and object LOD. DynDOLOD only replaces the object LOD part. 1) Download and install DynDOLOD files 2) Download and install tree LOD billboards 3) start TES5Edit 4) Create LOD for trees 5) execute DynDOLOD Worlds script 6) select worldspace 7) choose low/medium/high 8) click OK to create object LOD In fact it will get a bit easier. For tested mods it will add custom mesh rules automatically - if any are needed. No more adding rules manually from the manual. Unless Open Cities or Skyfalls.

Just like the vanilla LOD mountains in LOD4 all new LOD rock meshes in DynDOLOD use one (not plenty) full texture: textures\landscape\mountains\mountainslab02.dds This texture is already always loaded because it used everywhere in the game already. Including vanilla LOD for mountains. All you could potentially gain by using the LOD texture instead would be one or two (snow/no snow) draw calls per loaded BTO. But only if there are no LOD mountains using it either. The result is really, really, really - and I mean it - ugly rocks sticking out because of wrong color tone and non-matching texture. The only reason the vanilla game does it this way is, that CK LOD generation would not allow mixing full textures with LOD textures in the same mesh file. Maybe it is because of game consoles? LODGen.exe doesn't have that limitation and so the DynDOLOD rocks join the vanilla mountains in the BTO for one draw call. No performance gain can be achieved from that. However you may want to update the textures\lod\mountainslablod.dds with a better matching version from whatever texture replacer is used for when this LOD texture actually is used.

Much different meshes than the ones in DynDOLOD? I am confused, are you saying it has LOD meshes? If a mod adds new meshes with new file names the mod author should also create the LOD version if needed or else it won't have static LOD. Alternatively set the neverfade flag on the reference in the mod or create a custom rule to use full model. Only for select objects. House mods are a good candidate for that. If a mod actually overwrites existing meshes the 3D hopefully is generally still the same so any existing LOD still matches the shape. If a mod overwrites existing meshes and the 3D is really different the mod author should instead do it the correct way. It should have a different mesh name, add a new base element, update references to use new base element. And then rule #1 applies ) Changing textures in a mesh also means it should get a new filename. The better method is to use texture sets though. If meshes overwrite existing vanilla meshes you simply have to compare them to determine what to do.

Delete almost all split tree LOD dds/txt files, generate tree LOD for those few remaining then run DynDOLOD Worls.pas and let it do the other trees as static LOD. Maybe you probably already did that? I will look into this some more in the future if time permits. I have misspelled a command, So sorry! DynDOLOD 0.56.00 fixes it "Load order messed up!" message You need to generate tree LOD for the load order first before running DynDOLOD Worlds.pas for it.

Right back at you. Keep spreading your amassed knowledge and wisdom across all forums as you do since years actually. I read your stuff everywhere ;) As a final thought, I guess my intention for the createmod function of DynDOLOD was for a mod author to easily add LOD data for like a handful of new assets used in that mod, but basically stay true to the ugly but performant vanilla LOD. But when have tools ever be used only for their intended purpose anyhow? I am first in line to abuse and misuse said tools

So many posts to go through :) @EssArrBee Regarding trees on the map. Zilav alreayd had the right idea. DynDOLOD World.pas will add trees as object LOD in case they are not LOD trees already. That is why it scan the BTT files at start. Any tree their is a LOD mesh for that is not in the BTT files will be done as object LOD. Low/medium use the billboard mesh. High uses more details version for LOD4 and the billboards for 8, 16. I also assume if there are ever trees shown on the map, they must be object LOD... I know the map can show objects in in lower Levels, but do not know without testing what needs to be done exactly. Maybe play around with uLockedObjectMapLOD in ini... Regarding the windmill not updating even with clean save means there is left over data in the save. It is not really clean then. Maybe you can retrace your steps, so we know any pitfalls for the future. Default is the same as High, but it pre fills the path fields with default values as well. The difference between High, Medium, and Low is the mesh rules. The addtional rules of medium and low set more and more of the new objects to not be used for LOD. Nothing in LOD4/8/16 columns means no LOD for the meshes that matched. Like small rocks for example. @keithinhanoi Maybe we should start a second thread with TES5LODGen/DynDOLOD for mod creators somewhere? I hope I am not contradicting anything that Zilav already answered. If between the two of use we missed something just keep asking :) 1. Landscape .btr Just works like any other overwrite, last mod wins, loose files win over bsa. So if a mod overwrites only a couple files LODGen.exe will use those and for all others it will use the vanilla. The default is always to remove unseen. It really reduces file size and triangle count a lot. 2. STAT/MSTT/TREE etc and VWD First of all the scripted dynamic object LOD does not require VWD flag. It uses in own set of new STAT/MSTT/... base elements. So when you run DynDOLOD Worlds.pas as normal but uncheck 'Generate DynDOLOD' the result will be that all base elements that have static LOD have their VWD set and nothing else. At run time the game use the VWD flag of base elements to know that an object using that base element has LOD in the BTO file. This has 2 results: 1) these objects do not 'bleed' (no idea how to call this) into neighboring cells that are not attached - because there is LOD shown instead. 2) When the cell attaches the game waits a bit of time before showing the full model. Because the game also waits before it removes the object LOD for that cell. Contrary to that for example, tree LOD and showing full model tree does not wait. Unless you set the VWD on a tree base element. So if you don't have VWD flag set for base elements that do have LOD in the BTO you will sometimes see full models on top of LOD model causing z-flicker between the 2. AFAIK the only things that use the LOD mesh data of base elements are CK object LOD generation or our TES5LODGen. I have not seen anything else requiring it yet. The normal DynDOLOD Worlds.pas process skips adding the data to safe time and hopefully memory in game. It should overwrite existing LOD assignments when the 'Use original LOD assignment' checkbox is not set. I will double check. Though my general idea is, if you want to deliver LOD with a mod it should be with the lowest performance impact, which typically is with 'Use original LOD assignment' checked. 3. LOD data TES5LODGen uses that data to find the LOD meshes, so it is required. Bundles There obviously could be drop-in packages with the new/updated models for TES5LODGen, but I have no plans to create or maintain them. It is a matter of time, resources and patience :) Compatibility with other mods have the potential to make this into a maintainers nightmare quickly. Because of compatibility I offer enthusiast modders tools and resources to create their LOD based on their load order - in my eyes they are better equiped to resolve these type of compatibility issues. I consider the step from generating object LOD with TES5LODGen to generating it with DynDOLOD relatively small and doable by anyone who is into modding. There also is quid pro quo. All the good people here on S.T.E.P. contribute back with valuable questions or reports that move things ahead and improve the tools and documentation to make this process better and as easy as possible. Having said all that, everything I create is free to use by anyone for anything (as far as I can give that permission for LOD meshes/textures derived from orginal game content from Bethesda - as a general rule only use for Skyrim), so if anyone wanted to create packages for TES5LODGen go right ahead. Just credit where credit is due. Good Luck :) Documentation Anything that helps modders use these tools for their mods. I already added some options and features, but I do not really use that for my own endeavors and so it is not properly documented yet. You might even discover new options/functions that we need to add to make the process complete. Yes this may take some time, but then the whole TES5LODGen and DynDOLOD thing is already over a year in the making, so no rush. Generally I document things while discovering or creating - like taking notes. Then later we can go back and refine. CreateMOD mode I suggest to merge the result with the mod in question. Then generate LOD and ship merged version. @keithinhanoi and @Kelmych Textures I think the ball is in the hands of the creators of texture replacers to also supply updated LOD textures for at least vanilla/TES5LODGen. Some already do. A lot of are just 1x1 or 2x2, or 2x/4x 1x1 If it is not involving mini atlases it is rather straight forward. Whoever creates any textures I happily add them to DynDOLOD and give credit. I do create some mix/mini atlas myself, so those have to be redone. A lot of times it can be enough to take an existing [LOD] texture and just adjust color/tone.

OMG we need to figure out how that happened! There is nothing really different between 0.52 and 0.55 in terms of how LOD is done. Was it the billboard trees? Across the whole map or just around where you were? DynDOLOD 0.52 https://mega.co.nz/#!5N5CyRyQ!-ibs4zLSLZuH69ohlOhGrLNjivsA1e1B2HcTPRP6GNY

Anna NPC adds a world without anything in it. Probably a left over edit or for future updates. In any case, next version of DynDOLOD will ignore it and complete without error.

Can you tell me which mod adds these worldspaces? AN_DruidGroveWorld An_Lothlorien An_SancreselWorld

Trees on the map? No idea what you talking about. Are you saying you saw trees on the worldmap? No clue about that :) Windmill missing? Maybe botched update of save game? If with new game then it is something with the rules.

If you still have the tree LOD billboards installed from the TES5LODGen process and also still have the tree LOD generated by TES5LODGen you already did half the work! Unpack the data folder from the DynDOLOD archive to a mod in MO so you have all the extra LOD objects to be used in place. Install the TES5Edit scripts from the DynDOLOD archive to your TES5Edit installation. Now you just have to start up TES5Edit from MO with your load order and then execute the DynDOLOD Worlds.pas script. Here you have to do each worldspace 1 by 1 though. Select a worldspace and then either use 'low', 'medium, or 'high' buttons, set the 'Output Path' (it is like -o: parameter of TES5LODGen) to a directory not part of the game and not part of MO to avoid overwriting/nasty error messages. Then click OK and let it run. If needed, start DynDOLOD Worlds.pas script again, select another worldspace, click OK Save DynDOLOD.esp after completion and move files generated to the output directory selected above to a mod in MO.

Can you also post the log from TES5Edit that shows everything that lead up to that error. I will probably need need your load order too. Yes you are late, but I see you posting everywhere :) Yes, TES5LODGen will really only use LOD meshes that are properly added to the STAT records. DynDOLOD has a mode to create a mod that adds LOD meshes to the STAT and set the LOD flag. Set CreateMod=1 in DynDOLOD.ini It will then use the rules to update the STAT records, so you need to adjust the rules considerably to match what you want to achieve for that mod. Eventually the mod created by DynDOLOD should be merged with the main mod, because the updated STAT record with the set LOD flag is needed for proper object LOD switching. I would really appreciate if you could take notes of this process for documentation ;) One the reasons why we all needed these tools! You can easily replace existing LOD textures with your own. You just have to check if it is a 1x1 or a 2x2 LOD texture etc. Just look for the original road texture textures\landscape\roads\road01.dds and compare to the LOD version textures\lod\road01lod.dds. You will notice it is the same, just resized. So just to the same with DDSOpt for example, take your custom road texture and resize it both the dds and the _n.dds and overwrite the LOD texture with it. Then create Atlas again. In case of the landscape texture like textures\lod\fieldgrass01lod.dds, they are tiled 2x2 from the original, so if you wanted to update them you need a image program like photoshop.