z929669

This is how I set it up. I just use the folder structure expected by the script and run xEdit via MO. The output will be a meshes folder in the xEdit Output adjacent to DynDOLOD-Source. Right click the Tree node in xEdit for each relevant plugin, and the renamed tree NIF will all be generated. If your tree mod replaces vanilla trees and those trees don't have references in the mod plugin, you need to be certain full tree meshes from your mod exist under DynDOLOD-Source folder "as-is" but renamed like "TreeFile01_passthru_lod.nif" and you will need to also run this on the vanilla Tree nodes for each vanilla plugin (Skyrim, Hearthfires, Dawnguard, Dragonborn, TreeModPlugin ... all of them to be sure). When finished, all trees with LOD from your mod will have the CRC32 under the meshes output folder. These are the only ones that need to be made into hybrids, and the file names are accurate. Be certain all of the base models are 'final' before you do it or the CRC will be wrong later after edit of the base NIFs.

I would post on sheson's alpha 3 topic for Qs relating to DynDOLOD in your env.

That should be fine for LOD. Just check in game to verify. Both are more/less destructive, but that is the point. You can also look at the UV map and delete tris not used commonly or if associated with inner branches. You can also delete the polys that may not show much like those lower ones near the trunk or anything underground, etc.

If you are using MO, don't put anything but ENB files into your \data folder. Install as mods in MO. DynDOLOD DLL NG comes with the scripts I think. Just install that one higher priority than DynDOLOD Resources SSE. Be sure all of your plugins are cleaned to use NG. GOG version of the game may not be compatible with NG, IDK

That's a real time saver, and I never discovered or tried it. Will do so next time. I also use Sniff for this work. Note that you don't need to alter the root node: BsLeafAnimNode is fine, for example. Just ignore nodes with skinning. There is always a non-skinned corresponding node you can use (but sometimes the skinning node has info that I want on the unskinned node, but I'm not sure how to add it to the corresponding node). As sheson mentioned just previous, I now use Sniff to set root node scaling to 1.0 after separating the crown. So based on what he said above, my new workflow will be: Get all relevant tree CRC values into the file names using DynDOLOD_CRC32Gen.pas This yields the "WIP LOD Crown NIFs" and helps to sort out NIFs under meshes/landscape/trees/ that don't have LOD in addition to adding the CRC32 Use Sniff to set all root node scales to 1.0 (I've only seen this issue on about 5 of hundreds/thousands? of trees I've done) Use this principle: "Translation from NiNodes can be applied to child blocks and then also to vertices from The NiTriShape/BSTriShape in NifSkope with a right click, Transform, Apply" on all WIP files. Maybe Sniff can help, IDK Copy these to 'trunks' folder under \DynDOLOD\Render\Billboards\DynDOLOD\lod\trees\ in the WIP tree LOD mod and strip them down to just the trunks Might be able to simply remove the crowns only, since they are rendered, but full stripping reduces file sizes a tad. Sniff helps Strip all but crowns in the crowns WIP Sniff helps Optimize the crowns using SSE NIF Optimizer Manually optimize crowns larger than ~500 Kb using a 3D app # triangles is a better cutoff reference (≥ 15,000 tris), but file size seems to be a good-enough indicator. Run TexGen Render mode Construct hybrids using hybrid.bat/txt I will also experiment with "Flatten Hierarchy" for skinned trees or those having nesting. Maybe Sniff can help. Question: I always convert BSLODTriShape to BsTrishape in the full model before making hybrids. Is this advised or even necessary?

It seems like you are saying here that if the full model is used as the treeModel_CRC32_trunk.nif, one would still get trunk billboards when using Render option. I've never tried that and always have removed crown/collision. I've also found that leaving the Tree_Anim shader flag doesn't hurt anything, and not messing with removing this flag is a big time saver. Scale and relative positioning of crown/trunk will be off if you copy the crown/trunk with 1.0 scaling and 0.0 transform/rotation when it's a child of a parent/grandparent node that has scaling != 1.0 or transform/rotation != 0.0. You must extrapolate that info from all parents, summing the transforms/rotations and multiplying the scales from all parents. You can optimize the crowns using a 3D app like Blender, Maya, or 3Ds Max. That's a whole other ball of wax though. There's also things like InstaLOD, but that's not free or easy to get a trial

I re-imported/exported again using these settings and no alterations to the relevant NIF properties in NifSkope once finished. This seemed to resolve my scaling/transform issues: I believe unchecking the two items indicated in the export dialog did the trick for me. Could you share where you got the beta3 version? The nexus only has the beta2 and the download from this page doesn't work for me. Looks like beta3 really only fixes the Weld Vertices on the importer, so likely not that important to me, but IDK.

Linux/Unix doesn't use DLL, so not sure exactly what that is, but it may be relevant.

Yeah, that's abnormal performance loss obviously. It should be more on the order of a 25% performance drop rather than 80% performance drop. Linux open-source display drivers of the past were notoriously inadequate, so I'm not sure how much better they are for your GPU. I'm assuming ENB is also developed and optimized on/for Windows use.

I would load up what you have with the patches enabled in MO and sort through each of the missing masters warnings using that helper script. I don't think any of the CC dependencies are too complex. Also note that you will want to avoid specific mod instructions to install CC-related patches, as there may be a few such mods.

It's pretty simple if you know how to use xEdit with this helper script.

If you are following the guide, the XP32 plugin isn't used. In fact, the Ice Skating mod only applies to 3rd-person gameplay anyway. We only include these mods and Nemesis for those that want to build out animations atop the guide build.

To run 2.2.0, the simplest approach is to disregard Nemesis entirely and simply don't install "Ice skating fixed for real - No more attack sliding movement", which is the only mod we use that Nemesis configures. This has no bearing on LODGen or other aspects of the build.

CRC32 of the full tree model always changes when the NIF is edited and saved. It has noting to do with the plugin or edits of the plugin. If you change the full NIF, then the LOD must be updated with the new CRC32 ... and probably should be rebuilt completely, depending on the change.

Please read the OP. You are running in FO4 mode: Rename xLODGen.exe to [game mode]LODGen.exe (TES5LODGen.exe for example) or start with command line parameter -fnv, -fo3, -fo4, -fo4vr, -tes5, tes5vr, -sse, -enderal, -enderalse

Install priority matters. In your mod manager: Make sure you uninstall previous versions prior to updating all of these, including DynDOLOD 3 Alpha, which should not be installed in a UAC path (like Program Files). Uninstall everything. Don't overwrite. Check that you have no conflicting mods/versions overriding the latest.

Thanks for the confirmation. False flag, and can be ignored, I guess.

It could be the alpha opacity or the alpha test cutoff. Reach tree branches have NiAlphaProperty of 30, which is really low. Assets - I can take a closer look in the future, but it's probably reasonably simple to fix

Thanks for the explanation. I was able to remove it easily from the MO integrated editor without issue. In the meantime, I posted a 'bug' on the mod for Doodle to consider updating in the Nexus file. I don't know if this encoding 'breaks' the config file or not.

I'm guessing it may have something to do with your ENB or post-processing configuration effectively overriding effects of Soft Shadows. You may want to check that Nexus topic and let us know if that's the case and what may be the specific cause. I agree that Soft Shadows does diffuse the shadows a bit too much by default. I think making some adjustments to the INI will resolve, but I haven't taken the time yet to optimize that for Step. [GameSetting] fPoissonRadiusScaleBase = 4.00 fFirstSliceDistanceBase = 2000.00 fFirstSliceDistanceScale = 0.50 [Diffusion] bEnabled = true fDiffusionBase = 1.05 fDiffusionCurve = 4.00 fDiffusionMin = 1.00 fDiffusionMax = 10.00 fDiffusionInterior = 1.00 [ENBSeries] fDawnMultiplier = 1.00 fSunriseMultiplier = 1.00 fDayMultiplier = 1.00 fSunsetMultiplier = 1.00 fDuskMultiplier = 1.00 fNightMultiplier = 1.00 NOTE: when I looked at the INI via Mod Information in MO, I found three strange characters at the beginning of the file before the left bracket of [GameSetting]. I suspect these are non-ascii chars hidden in many text editors. i removed them in case they nullified that setting or possibly the whole INI, so you may want to verify. Re-downloaded to illustrate: TextPad and NotePad++ don't reveal this issue

So after toying with this a bit more, I've confirmed that scale should be set to 1.0 on the root node. I assume translation and rotation should be set to zero on the root node? But I'm also finding that if a crown is imported into 3ds Max, optimized, and exported, then the translation/rotation are set to zero and scale set to 1.0 for ALL nodes. Changing ANY of these (root node or BsTriShape nodes) to match the original crown values also results in incorrect LOD model. I assume that it's because all of the "bounding box" and other defining parameters are 'refactored' or 'normalized' at some point in the import/export/optimization process in the 3D app. Setting translation/rotation/scale on any node after such transformation to match that of the original actually must cause deviation from the original? It likely also depends on the importer/exporter. I don't think Blender has this issue, but that again may depend on the third-party importer/exporter. I'm mentioning all this because never in the past in my experience has scale, rotation, or translation needed to be altered on ANY node in the LOD model. The LOD model always uses the values of the source, since it's a direct copy. Also, I likely never had a situation where the root node of the source was scale != 1.0. So the lesson is: don't worry about rotation, translation, or scale in the LOD model UNLESS it's setting translation and rotation to zero or scale to 1.0 ON THE ROOT NODE ONLY?

Thanks. I will test this with the affected trees.

The mod linked in the guide is "DynDOLOD DLL NG" and is the correct version, so you have either not installed this version, or your DynDOLOD version is incorrect. The DynDOLOD online documentation describes version requirements and installation of all things DynDOLOD. We provide specific instructions where necessary for the Step guide requirements. For example, we use "DynDOLOD DLL NG", which is not readily available or supported to the exteni that "DynDOLOD DLL" is in the documentation.

Posting here, since I don't think this is a DynDOLOD 3 Alpha issue specifically. Hoping to get some assistance troubleshooting an issue I have with certain tree LODs scaling incorrectly between LOD and full tree (LOD tree is scaled as expected, but full tree is much smaller). I made the LOD model myself according to standard procedure I've done thousands of times now, so it doesn't seem to be an issue in this regard. Logs with full/LOD models My question is rather basic: What --if anything-- impacts LOD tree scale relative to the full tree scale as defined in the plugin? For example, this particular tree's NIF root node is scaled at 2.2, and the child BsTriShape is scaled at 0.8 (same as full model). The plugin reference scales this particular tree at 0.46. How do these two scale sources play together in determining the scale of the loaded tree, and why might that differ for the resulting scale of the LOD model if both are the same? Is scale then 0.46 * 2.2 * 0.8 = 0.8096? I've never seen this inconsistency between LOD and full when LOD is generated properly for the mod list and LO, so I suspect it's an issue with the plugin. Here's the offending reference:

You have provided no context. Are you following the SSE guide? Reinstall DynDOLOD DLL using the proper version as described in the DynDOLOD documentation.