z929669

test again

test

The test version fixed it. Thank you.

But rather maybe adjust the display in SSE Tweaks accordingly and just disable it to prove it's the cause.

Yes, thanks. Second link in OP corrected.

Did your smoke test pass previously? Are you strictly following the guide without any deviation like adding mods not in the list or skipping others? If the answer is 'yes' to both questions, then you missed an instruction somewhere. Most likely, you downloaded the wrong version of a mod or forgot to hide a plugin or not all installed plugins are enabled. There's too many possibilities to provide anything more specific without more detail.

Hey sheson, I'm hoping you can assist with an issue with constructing hybrids where I'm finding trunk billboards are not positioned correctly with the crowns. Backstory: I'm working with Veydogolt Trees, and this mod is interesting in that it is purely a mesh/texture replacer and relies solely on vanilla (or whatever) plugins for tree definitions (i.e., this mod has no plugin). So the replacement trees are not necessarily like those references being replaced. For example, treepineforest01 might be referencing a completely different custom tree using the model name defined by the vanilla plugin, so object bounds are going to be different between the NIF and the vanilla reference in most/all cases. This is what I think the problem is, but I want to verify with you. Link to assets - I'm providing all source, intermediate, and hybrid output assets for review. This particular tree is not a good candidate for flat trunk, but that's beside the point. I'm using this as an obvious example of the issue. I'm using DynDOLOD 3 Alpha 122. The billboards are not correctly aligned with the crown, and I'm assuming to fix would require a proper plugin be created with Tree overrides and object bounds properly defined. The crown adopts all of the xyz and positioning of the base model, and so does the trunk, but since the flat trunk is taken from the rendered trunk, the hybrid lacks any specific xyz and positioning defined by the 3D trunk. Can you sort me out?

See if you have bugreport.txt in your xLODGen folder, and also post SSELODGen_log.txt

Only if you have G-SYNC of Freesync-enabled hardware and your driversoft settings configured to support that. Explicit Vsync and frame-rate caps should be disabled everywhere that it can be enabled in this case to allow these NVIDIA/AMD features without redundancy or conflict.

Thanks for letting us know. You might want to post this for Sparrow-Cockerel and other users on the ERM Nexus page so that he can speak to the finer points of what's expected with parallax.

It's not clear exactly what files you changed for ENB or where you made the changes. ENB is manually installed in the actual game directory, and the binaries (DLLs) do not need to be changed. Only the preset files/folders need to be swapped (technically, only enbseries.ini is different among the presets). Just swapping this one file in your game directory shouldn't cause this issue. This is a DynDOLOD DLL error and has nothing to do with your ENB. Removing ENB files from the game directory should not fix this error. You have made other changes that we cannot know. It seems like you borked your SKSE or DynDOLOD DLL/Resources installation. Revisit the Extenders guide instructions to make corrections.

I assume those are not LOD trees, since they only appear in the foreground. It's most likely a combination of the textures and the normal faces of those areas of the mesh. You can try changing the branch textures you are using with that mod.

If you are using Step, you already have the mod needed. You just need to configure it to your liking. We don't offer suggestions: Skyrim Skill Uncapper for SE and AE

Cool. let us know what you find. I'll also be testing ERM with several different texture replacers to see what works best. All that matters is that the texture resolutions are standard units 1x1 or 1x2, etc. so that the UVs map correctly. Any textures with lots of striations may be inconsistent on any rock/mountain mesh, but I'm curious if the ERM UVs serendipitously are more consistent in this respect.

Yes, this would replace MM. This mod is highly compatible as a vanilla replacer, but MM makes changes to landscape and other vanilla stuff. Evidently, MM uses double pass on the snow shader to support parallax, but ERM uses single pass, which I'm told is more compatible, performance friendly, and generally looks as good or better in most situations. This is part of why MM requires patching where ERM doesn't. ERM also has it's own LOD, whereas MM relies on vanilla for most LOD (which then use the MM textures). In fact, ERM LOD can be used for just about any mountain mod as a LOD upgrade as long as the mountain mod's texture paths are vanilla. ERM LOD can technically be used without ERM to upgrade vanilla LOD. MM also has lots of conflicting striation patterns in the texture UVs (i.e., one boulder will have horizontal striations and another one nearby may have vertical). This happens more/less with vanilla and other mods, but it's worse with MM. Compatibility is one of the things that makes ERM attrractive. EDIT: ERM will also complement (or be complemented by) RWT.