z929669
-
Posts
10,775 -
Joined
-
Last visited
Everything posted by z929669
-
OK, so is this what you mean by "alternate textures"? So if the LOD model matching the mesh rule (path string for example) references textures\landscape\snow01.dds, even though the NIF defined by the plugin references textures\landscape\dirt02.dds, then DynDOLOD understands it's an alternate texture? I assume the alternate must adhere to dimension protocol to be used as expected and indicated in this report. If this is the case, then there is nothing to do for the author but make the textures and point to them from the LOD mesh.
-
Yeah, I never mess with those sliders, so I'm one of those that never noticed it's ineffectiveness in borderless fullscreen. As far as torch realism, I do agree, but if you are ever in a room where there is NO light (like a cave) you will find that those torches or candles extend quite a distance as long as there's not a ton of dust in the air. You don't notice this when there is even a tiny bit of ambient light. That said, I do agree that torch light could be brighter, so I have increased it again from ENB Light's value of 0.7 and Step's current value in the PP Patch of 0.85 to 1.0 when we update the Nexus. The default vanilla value (for non-ENB) is 1.75.
-
OK, thanks ... where can I find the alternate textures list, or is this created dynamically based on the LO? Or do you meant the alt textures defined by plugin texture set?
-
LOD\Mountains\MountainCliffSlopeSnow_LOD_1.nif ... as referenced for this EID in the plugin
-
Looking a bit further into more examples ... what about 0004157F .... this uses MountainCliffSlope_LightSN [STAT:0006E03F], which is assigns for Level0 as "meshes\lod\mountains\mountaincliffslope_lod_0.nif" by DynDOLOD but has no such MNAM NIF defined: so ... lod\mountains\mountaincliffslope_lod_0.nif (DynDOLOD Level0) LOD\Mountains\MountainCliffSlopeSnow_LOD_1.nif (Skyrim.esm Level0) According to the doc you linked, this would automatically be part of objSnow due to the EditorID string itself, but DynDOLOD is not seemingly assigning the expected LOD NIF. I'm not questioning if this is correct or not, just trying to understand what appear to me to be exception(s).
-
This is not a DynDOLOD problem. Trying to understand vanilla mountain LOD. It seems quite nonsensical on its face. What am I missing? Example: EditorIDs MountainCliffCrevasse and MountainCliffCrevasse_HeavySN both use the same NIF, and the following doesn't make much sense to me, so I'm asking your opinion: Is it a mistake or just laziness? The base model is the same in both cases, but the DNAM is different: No material, but using a light Level0 (but not at the other levels) Material and using a heavy at Level0 (but not at the other levels) Obviously, these look like two similar but inconsistent treatments. DynDOLOD lets us extend Level0 treatment to other levels but at the expense of performance.
-
incorporated No Spinning Death Animation (by dDefinder)
z929669 replied to TechAngel85's topic in Skyrim SE Mods
Our search lookback is three years, I think. I'm going to try setting it to all history again to see if it will work now. -
Fixed
-
This mod touches and changes a lot of objects and would probably be a deviation from vanilla in many ways. It's not just landscape. We'd need comprehensive compares with current Step to consider.
-
So you added the 'by' values to the existing, or are those the final values after you changed them? I will have a look at the diffs between the three ENB versions. They should look very ismilar in all aspects, but I'll verify. New torch brightness values for ENB will be coming soon in the PP Patch update once I cross check the ENBs.
-
Follow the links in the guide for DynDOLOD Resources mod and DynDOLOD 3 Alpha. You need to update to Alpha-32 Resources and also use the latest DynDOLOD Alpha 119
-
I'd like to know this as well. I don't understand why NifSkope doesn't have axis values in the UV editor. Putting it in vertex mode and selecting a number of vertices shows that everything I select is in 0-1 range, so I think the light gray box is 0-1 (or -1 to +1 in Cartesian space) ... so if that's true, then the dark gray must be 0-3 (or -3 to +3)??
-
You can test in game using Shift+Enter to adjust settings on right side (current weather) to see the impact and limits of each setting. I use AMD, so no idea about NVIDIA driversoft settings. You should be able to set by game though.
-
I used NVIDIA Texture Tools Exporter and just opened and saved with alpha mipmap coverage threshold box checked at default threshold of 127. All other settings default (but saved using 'normal' method instead of 'fastest'). I'm guessing you could alternatively use Texconv -keepcoverage number as sheson said, but I don't know what 'number' represents. Maybe increasing NiAlphaProperty to 128 on the branch node would resolve completely, but not sure without testing.
-
You could also try this version of one of the diffuse used. I just saved at alpha mipmap coverage threshold of default 127. This is probably close to what DynDOLOD uses, I assume.atlas_pine.7z PS: I should have mentioned that you could use the texture on the original version of pine01 I think without "UseMipMaps" removed.
-
While sheson is away ... This is what I would do. Try regenerating DynDOLOD using this version of the LODs you sent. This removes the "UseMipMaps" string from the branch BsTriShape name, which --as I learned just a few posts back-- is what prevents DynDOLOD from generating the branch texture mipmaps for the LOD version as usual. It will instead use the mips in the texture. It could be that the texture mipmaps are not done properly (I looked at them, and they get very thin) ... if that's the case, you should notice that the loaded full trees in the farthest distance before LOD begins look thinner than the close ones. It's worth a try. If it looks better, the mod author should be told to fix the mips or remove the string. These LODs are also not hybrids for some reason, so unnecessarily complex for LOD. Branch UVs look fine to me, and trunk UV doesn't matter (no alpha transparency to worry about). The NiAlphaProperty is quite low (40), but I don't think it matters much. But it would matter if the MA used a texture alpha threshold to match it (not sure how to check that or if that info is in the texture).
-
Testing with these changes for Alpha 119. Default is using ComplexGrassBillboard=4, ComplexGrassBacklightMask=0 L to R: Default >> ComplexGrassBillboard=5, ComplexGrassBacklightMask=50 This doesn't seem right. First images show as expected, but I did not expect that these changes would affect loaded grass, so I'm verifying ... wait one. I confirmed that EVLaS has no impact. No shadow is cast my the distant mountain. It should creep along towards the PC as the sun is occluded. Any ideas? Terrain underside not working maybe? Logs Disregard previous compare. I was lazy and loaded up the game on my save without clean saving first. Using a clean save or new game resolved EVLaS interaction: L to R: Default >> ComplexGrassBillboard=5, ComplexGrassBacklightMask=50 >> ComplexGrassBillboard=5, ComplexGrassBacklightMask=25 Better, but I think ComplexGrassBacklightMask=25 may be the best trade-off
-
Tested latest features in Alpha 119 using defaults for grass (backlighting flag unset using external billboard). Following are screen compares with my previous under 118: Left to right: Alpha 118 >> Alpha 119 So this looks great when the sun is down. While the sun still shows over the mountain though, matching is a bit worse. Should I play with ComplexGrassBacklightMask then? Keep using ComplexGrassBillboard=4 or switch to 5?
-
That's the first thing I tried ... not seeing those settings in the 119 DynDOLOD_SSE.ini My fault. I made a mistake in updating my upgrade INI
-
@sheson Question about new features in latest update: Is the documentation on these features pending?
-
So if your BethINI settings are all per recommendations (including iMaxParticles, Ambient Occlusion, etc.), then you can try updating to the latest ENB binary. I do think that ENB torch light should be brighter, so I will note that in the next PP Patch update. These things can also be influenced by your driversoft graphics settings, so you might want to look at those just in case. Otherwise, things like monitor and graphics hardware can vary a bit. To increase this lighting with ENB, there's many options, but I would play with increasing: [ENVIRONMENT] - AmbientLightingIntensity* and [SKYLIGHTING] values for exterior (I would not increase these much, as they are powerful and can affect many things) Settings exist for interiors day/night and exteriors at several times. These also must be edited under ..\enbseries\Weather\ for EACH weather. Don't change anything in enbseries.ini.
-
Are you using all mods and patches in 2.2.0 as instructed without any additional mods? These screenshots are fairly typical of expectations. The vanilla lighting without ENB is far too bright in those shots, and with ENB is a tad bit too dark. Have you tried adjusting in-game brightness from options menu?
-
Unable to fully precache grass (crash at specific coordinate)
z929669 replied to MinhazMurks's question in General Skyrim SE Support
Why use BDS and SoS? You need to pick one or the other, and disable Wintersun - Faiths of Skyrim. Do that and see if the issue is resolved. -
What is this command? How can we invoke/test? I'm asking in relation to different trees/textures.
-
Strange. I just checked, and they are at the end of the file and have been for days: Maybe because I quit DynDOLOD ... in which case, I'm not sure why the bugreport.txt was generated (there was no error in the logs)
