
audawarduz
Citizen-
Posts
12 -
Joined
-
Last visited
Everything posted by audawarduz
-
How do I get the coordinates of the cell to generate? I tried opening the DynDOLOD MCM in-game, but which coordinates do I need in order to select the appropriate BTO? The MCM does not use the words "west" or "south" anywhere, so I'm not sure how to relate it to the settings in DynDOLOD. Also, after I click Execute LODGen and it indicates it is finished, do I then click OK, or Cancel?
-
What do I need to do to only run DynDOLOD on the cells I'm interested in seeing? And is there a nice way to find out those cell coordinates, names, or whatever, in game?
-
For attempting to match the colors, I would suggest turning off the extended grass draw distance in GrassControl.config.txt, and choosing the setting in DynDOLOD_SSE.ini to draw grass LOD closer. Then it will be easier for you to see your transition line between normal grass and grass LOD. I suspect the direct/ambient settings in TexGen will produce "better" results for color matching, which is why I'm expending some effort on it. I think the RGB multipliers in DynDOLOD_SSE.ini are intended for final adjustments after you've gotten the colors fairly close. Once you do have the colors fairly close, you can then obtain good DynDOLOD_SSE.ini settings for the RGB multipliers by running DynDOLOD twice. First you need to run it with whatever settings are in your file (if you've tweaked them a lot, then maybe pick something close to 0.400 to get a good starting point). Then, go somewhere where you can see the grass/LOD transition, pick a time of day and a weather condition, and take a screenshot. Open the screenshot in GIMP, and use the color picker to measure the color of both the normal grass and the LOD grass (use the color picker settings to take an average over some area of your screenshot large enough to contain several grass instances). For each of the RGB values, take the ratio (real/LOD). Then go into DynDOLOD_SSE.ini and change the RGB multipliers like this: new_RGB_value = old_RGB_value * (measured_real_RGB / measured_LOD_RGB) where the measured values come from your screenshot. Provided your starting guesses (the old_RGB_value's) were close enough, this procedure will get you a pretty good match in color, after you run DynDOLOD again. But, only at the time of day and weather that you chose for the screenshot.
-
I was wondering if you have any suggestion for how to determine good settings for the TexGen grass billboard lighting parameters, especially Direct and Ambient? At the moment I am changing the numbers a bit, re-running TexGen + DynDOLOD, and then loading the game to eyeball the effect under controlled weather conditions. But as you imagine, this adjustment loop takes some time. Is there anything I could measure from a screenshot (say, using the eyedropper tool in GIMP) that would give a better idea of how much I should change these values? And since they both affect brightness under different lighting conditions, are there particular weather settings I should use? For example, maybe one needs two screenshots under two different weathers, in order to (hopefully) isolate the two variables. But I don't know how the variables relate to the eventual colors I see on screen.
-
I was wondering if you could help me understand how to use this setting in DynDOLOD_SSE.ini. Couldn't find anything in the manual, and the comments are not entirely clear: ; set to a value > 0 and <= number of CPU cores ; lower values = more main threads = more memory usage - not nessarily faster/slower ; higher values = less main threads = less memory usage - not nessarily slower/faster LODGenThreadSplit=4 I would expect a setting that, say, limits the maximum number of simultaneous threads to a given number. That idea aligns well with the comment on the first line, but seems to be contradicted by the following comments. How does this number actually relate to the number of threads? And does it have anything to do with the subprocesses that are spawned in CMD windows? Or am I misunderstanding that? I have played around a bit with this number and not really noticed any effect. (But to be clear, I have loads of RAM and would like DynDOLOD to do as much in parallel as possible.)
-
Ah, ok, got it, thanks
-
Ah, I think I'm having the opposite problem, actually. When I am inside Whiterun looking out (I guess this means I'm in WhiterunWorld), there is no regular grass drawn outside of the Whiterun walls. So the grass LOD appears, but there is nothing before it, so it looks like a barren landscape until you get to the LOD distance. It's not the biggest issue as I can just not look over the walls. But if there's some easy way to fix it, that would be nice. Although it's not really a DynDOLOD issue.
-
Awesome! To be clear, should I recreate the grass cache, or just run DynDOLOD?
-
Could you explain where to edit such a thing? I would also like to solve this problem. No worries, this is also what mine does when it's finished. If I open Task Manager and kill Skyrim.exe, I then get the message saying grass cache is finished. If this doesn't exactly give you feelings of confidence about the process, then try running the grass precache process with Skyrim set to windowed mode. I did this once, and discovered that the "black screen, hang" behavior I was seeing was actually Skyrim attempting to pop up a message about the grass cache being finished (but being unable to do so because it was fullscreened).
-
Thanks, that did the trick. I can now successfully generate grass LOD. Now to work out the balance between looks and performance.
-
Could you explain how to recalculate object bounds? Or point to where it is explained?
-
I am trying to use 3.0 alpha 20 to generate grass LODs, and I am having a problem with Myrkvior trees (specifically, the aspen trees in TFoS Aspens RAT Large addon). I have run the following, all through MO2: 1. NGIO precache grass: Done, no problems 2. xLODGenx64 Terrain LOD: Done, no problems 3. TexGenx64 3.0 alpha 20: Finishes with no errors 4. DynDOLOD 3.0 alpha 20: Fails to generate any LODs. Reports `Error: LODGenx64.exe failed to generate object LOD for` all worldspaces. Digging through the detailed logs: `LODGen_SSE_[worldspace]_log.txt` reports textures\terrain\lodgen\skyrim.esm\rat_aspen04_0005fada.txt not found Log ended at [time] (0:1) Code: 404for all worldspaces. That is, it appears one aspen tree from TFoS Aspens RAT Large is causing the problem. Indeed, I go and look for the named file and it is missing. MO2's virtual Data folder shows that `textures\terrain\lodgen\skyrim.esm\rat_aspen04_0005fada.dds` and `textures\terrain\lodgen\skyrim.esm\rat_aspen04_0005fada_n.dds` exist, and have been placed there by TFoS Aspens RAT Large. In the folder there are textures for six aspen trees, numbered 01 through 06. Only 04 has this problem. For 01, 02, 03, 05, 06, MO2 reports that the files come from TexGen Output, and TexGen has added the relevant `.txt` file. If I look in `TexGen_SSE_Debug_log.txt`, I find the following: [00:17] <Debug: Processing TFoS Aspens RAT large SSE.esp TreeAspen04 [TREE:0005FADA]> [00:17] <Debug: Ignoring Meshes\landscape\trees\rat_aspen04.nif bounds volume 487.956970214844 TFoS Aspens RAT large SSE.esp TreeAspen04 [TREE:0005FADA]>by contrast, the other aspen trees appear as [00:17] <Debug: Processing TFoS Aspens RAT large SSE.esp TreeAspen05 [TREE:0007614B]> [00:17] <Debug: Processing TFoS Aspens RAT large SSE.esp TreeAspen06 [TREE:0007614A]> [00:17] <Debug: Processing TFoS Aspens RAT large SSE.esp TreeAspen02 [TREE:0006C9D5]> [00:17] <Debug: Processing TFoS Aspens RAT large SSE.esp TreeAspen03 [TREE:0006C9D4]> [00:17] <Debug: Processing TFoS Aspens RAT large SSE.esp TreeAspen01 [TREE:0006A9E6]>without the "ignore" line. So, TexGen is ignoring aspen 04. This causes DynDOLOD to fail to produce any LODs, because it cannot find the file. What needs to be fixed in order for TexGen to correctly generate `textures\terrain\lodgen\skyrim.esm\rat_aspen04_0005fada.txt`? Full logs exceed the maximum allowed size on Pastebin.