z929669

You need to enable the DynDOLOD resources as described in the guide. In fact, you need to enable all mods that you install. Please revisit the mod instructions for DynDOLOD under 03-Resources.

Yes yes not necessary, but fine yes should work fine if you follow the instructions probably ... but there is a lot of detail and gotchas in between the steps you've listed. If you know how to run the tools and install mods, then you should be fine. Otherwise, I suggest that you follow along with our setup guide just to be sure you have the infrastructure set up correctly. Else you will be stuck on things that have nothing to do with DynDOLOD. You might also consider running with the beta version, since this is a thread for DynDOLOD 3.00 alpha (for testing and helping out with development). My advice is to forget about installing multiple tree mods that don't necessarily work together without some custom patching. Myrkvior alone is a big tree overhaul. If you want to learn how DynDOLOD works and how to use it, you don't need any mods at all. If you have a working mod list and just need to get the proper LOD, then you can try your steps above, but it sounds like you could potentially have a lot of questions and issues that are not likely related to this topic. If a stable LO is what you want and developing a general understanding of how to build one, maybe try following the Step guide as a first measure and post questions on our guide forums for help ... or just follow along with the LOD section in that guide using DynDOLOD 2.xx. As sheson will undoubtedly say: See first post about logs to include when posting. Also, see the links above.

The settings under the spoiler here work well for Cathedral Landscapes grass. You can test with ENB and lower all by, say, 0.1 if they are still too bright.

Sounds good. Will adopt those changes in my setup

Awesome. We need a FO-knowlegeable (and interested) party to do this, so it looks like a good thing from all sides if you are into upgradeing an FO guide. There is no PHP that you will see. It's all handled by Semantic Mediawiki functions, forms, and templates. Just have a look at the Step Portal as mentioned, click through to the FalloutNV home page, and go to it's portal page for all you need to create the mod pages and the guide. We will step in to help as needed. I will grant you the necessary edit perms to get started. You can edit most pages as a member, but using the guide infrastructure requires more.

Are you using an FPS monitor? DynDOLOD and NGIO both can cost enough in performance to cause stuttering. In my testing, terrain LOD costs me 5 FPS, and DynDOLOD can cost me a minimum of 10 FPS on the very lowest settings (and I have a pretty beefy box). Add ENB, and you are losing at least another 5-40 FPS. If you have lower than 40 FPS, you can start seeing some stutter or 'lagginess'. Look at the second post and try some of the recommendations under the 'performance' section. If that doesn't help with the stutter, check that DynDOLOD works as intended by generating LOD without NGIO active in your mod list. If that doesn't have stutter, then try disabling the DynDOLOD mod (created from your output) and run NGIO using the recommended settings. These WIP instructions for DynDOLOD w/wo grass LOD should help (sheson has not yet fully vetted, so take his advice over ours if conflicting)

You can choose to either adhere to the Step mandate to create an official guide, or deviate from vanilla FNV to create an unofficial guide. Both use the guide framework and allow other guides in the framework to reuse mods. This benefits all of our wiki editors. As an example, I just looked at SRB's guide and found 'NVSE', which had a bad link in his guide. I determined where it is being maintained by a quick Google search, and was able to add the mod page. Now this mod can be linked from any wiki page by simply using the following wiki markup and can also be listed in any FNV guide via the framework. [[FalloutNV:NVSE|NVSE]]

If you want to work on updating a Fallout guide, it would definitely be best to work on an official or unofficial guide using our guide framwork. EssArrBee's guide is pretty outdated and does not use the new framework. We could help you get the structure set up and the mod list based on his most recent one. What would need to happen is that guide's mods would need to be added to the wiki. @EssArrBee's guide belongs to the site and the community, so you can legally edit it; although, it should probably be left alone to preserve it's original intent. We version guides for that reason. You could alternatively reproduce it into a new version of that same guide and update it, as you indicate by 'fork'. This is just as much work as using our framework though, and does not benefit the site or other guide creators like you, because data pertaining to mods hard-coded into user pages cannot be 'reused' in other guides without directly hard coding them into another page. This is both redundant and unhelpful to all. Either way, it will be a lot of work, so it is for this reason why I advocate creating your own guide under the new framework using his guide as a reference. If you are willing, we can assist where needed (like the 'technical' instructions for modding tools, etc ... we have a reusable System Setup Guide that applies to all Bethesda RPGs for that purpose. We need guide curators for Fallout games anyway. First step is to identify all of the mods you want to use and what mod groups they belong to so that they can be added to the wiki. Just copy the info from mods in SRB's current guide into new mod pages for FalloutNV namespace. See instructions for doing this work on the Step Portal. It helps to use two browser tabs: one for the reference guide, and the other to work on the mod pages for the new guide (in fact, I often have multiple tabs open for this work). What is your timeline?

Just finished the 3D trees for Aspens Ablaze. Shared with mindflux, so hopefully available soon. I am amazed that this mod only uses one trunk texture and one branch texture having only a couple of branches (both with with normals). All that detail from so little. Meshes handle the color variation.

The NIFs say differently: Anyway, added the ",True" to end of line, and still no dice: TexGen_SSE_Debug_log.txtDynDOLOD_SSE_TexGen_Billboards_aspensablazeesp.txt Do I have the file name, location, and string content correct? I found an example in Configs folder, so changed from: AspensAblaze.esp;03000D61;TreeAspen07,True to Aspens Ablaze.esp;03000D61;TreeAspen07,True EDIT: Adding that space did the trick!

I will try adding ,"True" to the end of the text definition. If this does change things, I think you will either want to revise the documentation or let "True" be default as the doc impies without explicitly adding ,"False". Regarding your tree volume: Did you download the Aspens Ablaze main file, and are you referring to the volume of TreeAspen07 as define in that? I downloaded this file as of May 24, and this tree along with 08/09 have '0' object bounds in Aspens Ablaze.esp as shown in my post-2 When I loaded This plugin into the CK, these three trees had 'blank' Size in the Object Window for Tamriel > Trees. I then right clicked the records of all TreeAspen01-09 to "Recalc Bounds" and saved. I have also looked at TreeAspen07 in Nifskope, and it is indeed small compared to the others (going from memory, as I am not at my home PC right now). ... perhaps I must also load the DLC objects to check those as well in the CK?

So adding the bounds actually did allow the billboards to be created for two of the three new trees. The log:TexGen_SSE_Debug_log.txt ... has lines: [01:37] <Debug: Processing Aspens Ablaze.esp TreeAspen07 [TREE:29000D61]> [01:37] <Debug: Ignoring Meshes\landscape\trees\treeaspen07.nif bounds volume 237.533157348633 Aspens Ablaze.esp TreeAspen07 [TREE:29000D61]> Since the volume is < 512 (default) in TexGen_SSE.ini, I created a reference to test if I could force billboard creation for this tree, but no dice. Plugin name is "Aspens Ablaze.esp", and I placed the following file in: {modRoot}\DynDOLOD\DynDOLOD_SSE_TexGen_Billboards_aspensablazeesp.txt DynDOLOD_SSE_TexGen_Billboards_aspensablazeesp.txt My guess is that I have the file/path nomenclature wrong.

Doh! I neglected to look at the references tab ... duh. I was opening up all the subblocks and not finding them. Thanks!

I'm going to expose my lack of xEdit and plugin-management prowess here, but I need someone else to confirm: Examining in xEdit, it appears to me that the Aspens Ablaze plugin is defining but not placing any TreeAspen07, TreeAspen08, or TreeAspen09. TexGen is not creating billboards for these, and I determined it's because they don't have defined Object Bounds, so I used "Recalc Bounds" in CK for these and TreeAspen01-06 (because I assume the MA did not set these for the replaced vnilla aspens either). Can anyone confirm placement and status of object bounds? I assume that Aspens Ablaze is replacing the vanilla trees, but I don't see the records for these in the plugin, so does this mean that it's only replacing textures and meshes for the vanilla aspens? The mesh bounds are surely different, no? When I recalc bounds in the CK, these 'size' values indeed change, but I am not certain if this is appropriate:

@sheson I created 3D Hybrids for Aspens Ablaze. I haven't generated object LOD yet, but the LOD meshes and trunk billboards were created as expected for all trees in that mod, so I expect no issues. I need a quick reminder about TexGen tree-billboard creation. Aspens Ablaze mod adds three new aspens via ESP, and all seems kosher with the plugin (but for '0' value for all object bounds). However, TexGen only created billboards for treeaspen01-treeaspen06 (i.e., the vanilla replacements). TexGen did not create tree billboards for the new ones (treeaspen07-treeaspen09). Is this an issue with the new tree records in Aspens Aplaze.esp? I'm guessing that I need to set something there. EDIT: I think I have found my answer in ../DynDOLOD-3.00/docs/help/TexGenConfiguration.html .... I believe that I need to set the object bounds to trigger TexGen tree billboard creation. So If I load the plugin into the CK, I can use this method to write the prober object bounds(?): ... and then save the plugin and re-run TexGen? EDIT2: Well I did that to no avail. Even with defined object bounds, I get no billboards. Please see this post and provide me some direction if so inclined. Thanks in advance.

We support Mod Organizer here rather than Vortex. You should probably post about how to set this up on Nexus Vortex support.

You can either promote those mods to ESM via CK, not use the mods, or just ignore the warnings. Most of the large ref issues I have tracked down were for objects that I would not notice anyway. That said, mod authors should be made aware how/how not to carry forward their changes with respect to LOD.

OK, I will work on Aspens Ablaze LOD if we agree to accept this one conditional to that. Agree that it would be the best option for the next Step iteration.

I like grVulture's aspens and Aspens Ablaze as a vanilla replacer. Of course, I prefer the look of Aspen Realism, but agree that I need to soften the brightness a bit. I will fix that soon. I can create 3D hybrids for Aspens Ablaze and share them with the author to take care of that ... or upload as a separate mod if the author isn't interested. DynDOLOD 3 will handle the billboard1 and 2 nicely.

Thanks for creating this!

This means that the test output has no conflicts in the MO load order. Otherwise you would see conflicts in that middle pane under "Losing file conflicts" As sheson mentioned, you can check the game directory as well, but that is a manual process. MO works in the virtual game directory, but it can do nothing about those files in the 'real' game directory. See sheson's previous post.

You need to tell NGIO via the INI, but that mod highly advises to use precached grass to avoid stuttering and other issues. I would precache grass always with that mod, regardless of whether or not you are using it for DynDOLOD grass LODGen. This is our WIP instructions for running without grass LOD: Precaching grass will still benefit performance. To increase performance further, disable grass LOD generation completely by making the following configuration changes prior to generating (or regenerating) object LOD: In MO, make the following changes to No Grass In Objects GrassControl.config.txt: DynDOLODGrassMode = 0 OverwriteGrassDistance - Set to something between 4000 and 24000. Higher values decrease performance while increasing quality. Grass will be full-rendered to this value as per default behavior of fGrassStartFadeDistance in Skyrim.ini OverwriteGrassFadeRange - Set to something between 1000 and 18000 (depending on OverwriteGrassDistance) to transition linearly from full grass to no grass. Higher values increase performance while decreasing quality. Grass will begin fading from this value as per default behavior of fGrassFadeRange in Skyrim.ini ExtendGrassCount - Set to 'False' only if OverwriteGrassDistance ≤ 7000 Set Grass=0 in ../DynDOLOD/Edit Scripts/DynDOLOD/DynDOLOD_SSE.ini

The general consensus is to use xLODGen for Occlusion. From our guides: Run xLODGen from the MO2 executable drop-down list. Select only the Tamriel and DLC2SolstheimWorld worldspaces. Ensure only the Occlusion box is ticked. Use the following settings: Quality: 3 Height: 0 Radius: 100 Mode: -Flat +Borders Click [Generate] to run the process. Once the completed message has appeared, click the red X to close xLODGen. Occlusion.esp is saved automatically and will be placed in the Overwrite folder in MO. Right-click on the Overwrite mod listing and select, [Create new mod]. Name it Step SkyrimSE - Occlusion or anything unique. Ensure the new mod is active (ticked). Ensure the Occlusion.esp is the last plugin in the load order just after DyDOLOD.esp and that it is enabled, else run LOOT and sort plugins.

Again, I would drag the contents of TexGen_Output into a new mod and not bother with packing it into an archive. Click on the tool icon: Right click on the new empty mod: Drag contents into that and hit F5 to refresh MO. Then double click that mod > Conflicts tab, find conflicting mod

Me too, but I forgot to mention it. I discovered the issue when all of my embers were orange and waxy