vrnord

Can I post an xLodgen suggestion for consideration? Dyndolod already has grass LODs but they are quite a performance hit and need to be fairly dense to look convincing. Obviously NGIO's option to extend actual grass models is an even bigger performance hit. And since xLodgen uses only landscape textures to bake terrain textures, without grass LOD the transition from grass to no grass is visually jarring. But, it occurs to me that between NGIO's grass cache and Texgen's grass billboard output there is (potentially) enough information for xLodgen to take a different approach. What if Texgen had an option to generate super-low-res grass billboards (like 16x16 or 64x64 pixels maybe?), and then xLodgen used the location coordinates and size (bounds) data of each grass model instance from NGIO's grass cache files to place the matching billboard at those coordinates and relative sizes on the terrain texture output, basically like a decal on top of the landscape texture? The grass decals could randomly overlap each other in the case of denser grass. From a distance, and under a decent noise texture, I think it could be a convincing visual extension of the physical grass models. The location of colours (like a patch of red flowers) would also match for a nice transition when the physical models load in. Even better if low-res grass billboard normal maps could also be placed/blended with the terrain's baked normal maps to randomize how it reacts to light. Obviously you would need to select a somewhat higher resolution in Xlodgen (maybe 1024 or 2048?) for this to look like anything, but I think it would still save a lot of drawcalls at the cost of slightly more VRAM. Thanks for all the brainpower and effort you put into the Dyndolod tool!

Idea/request for a possible future update: Billboard 2 looks more convincingly like full models from a distance to me, but when it is backlit by the sun (morning or evening, using the billboard model's soft-lighting shader) the illusion is broken because the bits that are supposed to be dark or opaque (shadows and the trunk) light up as much as the leaves/needles that should actually have some subsurface scattering. This is especially noticeable with snowy pines, because all the white snow on the branches starts to basically glow and look translucent. This is because the billboard model reuses the diffuse texture in slot3, and the diffuse image seems to be captured by Texgen using frontal lighting (looks like bright daytime). My suggestion is to use a new 3rd texture in the 3rd slot of the billboard models, which would also generated by Texgen (so texture.dds in slot 1, texture_n.dds in slot 2 and texture_sk.dds in slot 3). That new *_sk.dds texture would be captured using lighting that more closely simulates backlighting - so trunks and shadows are darker and thus less illuminated by the soft lighting shader when backlit. See below screenshots for the Nifskope lighting settings I found most closely resembled backlighting (backlit subsurface scattering version on left, daytime normal lighting for diffuse on right): Thanks for considering and for all your work on Dyndolod!

Can I make a suggestion for a possible future feature tweak? Grass LODs are really awesome: having grass beyond the active cells is a whole other level of immersion because I don't have to tell my brain to ignore bald terrain that is often very visible. I will downgrade other things so I can keep my grass LODs. A challenge is that, to balance performance with visuals, I need to set a fairly low grass LOD density so Pine Forest and Fall Forest areas run smoothly. I can get away with that visually, because there is enough tree density and shadows in those regions to distract from or obscure the patchy LODs - you get a nice impression of distant grass detail but don't really focus on it. However that leaves the Tundra and Reach with patchy grass LODs too, where it is much more noticeable and distracting because of the lack of trees. The irony is that the lack of trees and other forest clutter means I could have afforded denser LODs there. I wonder if there could be an option to add a rule to Dyndolod to override the overall grass density for certain regions, maybe by landscape texture? So if the rule is Reach = 50 density (but overall density is 35), then Dyndolod knows Reach = Reachgrass01, Reachmoss01, Reachdirt01 and Reachmossyrocks01, and finds the corresponding grasses to override from the overall density setting: all other grass types would be 35. Alternately, is there a way to run Dyndolod by region "chunk"? That way I could output Dyndolod with 35 density, then change to a higher density to output just the Tundra and Reach mesh chunks and have that override the overall output in MO2. Thanks for all your work on this awesome tool!

hey thanks, that actually helped me figure out the problem! I'm not using HLT aspens, but a long time ago I tried them and had installed the 3d lods, and when I uninstalled the aspens I neglected to uninstall the 3d LOD files. That never mattered until I reran Dyndolod yesterday and it started looking for the HLT CRC32 texture files for the vanilla/RAT 3d lod trunks. Weird. Anyway, I manually changed the CRC32 names of the trunk textures to match what Dyndolod was looking for and it looks great again.

Hello! I am having a weird problem that hopefully has a simple solution! I downloaded the most recent version today and re-ran Texgen and Dyndolod. But in-game I now have this problem: ultra 3d LODs' trunks are missing textures (purple rectangles). I narrowed the problem down to Dyndolod looking for a different CRC than Texgen assigned to the trunks in the textures\dyndolod\lod\trees folder. Note that billboards are fine, and I compared a new Texgen output against the previous one (that worked fine) and it has the same CRC filenames. I don't have an old Dyndolod output or previous tree report to compare to the new one to see if the CRC changed there. I can see that Texgen is using the CRC from the LOD trunk mesh model; but how can I get Dyndolod to use it as the texture name in the final ultra lod mesh? I have tried deleting cache, rerunning both texgen and Dyndolod again and also downgrading back to the previous version that worked correctly last time, but all are giving the same result: in the example of TreeAspen02, Dyndolod is looking for 353a9a39 but Texgen output (and the original trunk mesh) have CRC 055a9061. From Dyndolod Tree Report: Level0: meshes\dyndolod\lod\trees\treeaspen02_353a9a39passthru_lod.nif [CRC32:92F49419] using textures\landscape\trees\treeaspenbranchcomp02.dds, textures\landscape\trees\treeaspenbranchcomp_n.dds, textures\dyndolod\lod\trees\treeaspen02_353a9a39_trunk_1.dds, textures\dyndolod\lod\trees\treeaspen02_353a9a39_trunk_1_n.dds, textures\dyndolod\lod\trees\treeaspen02_353a9a39_trunk_2.dds, textures\dyndolod\lod\trees\treeaspen02_353a9a39_trunk_2_n.dds

Does that mean Billboard 3 isn't actually usable, or that it reuses one of the textures twice?

Question - how to I get Texgen to generate billboard_1, billboard_2 and billboard_3 tree lods? I want to use Billboard 3 option with 3 planes but I notice it wants all 3 textures but my Texgen output only has *_1.dds and *_2.dds for each tree; there is no *_3.dds. I don't see options for that in the Texgen_SSE.ini file. Thanks!

OK, thanks for the reply! EDIT: Alternate thought: what if there was a variable in the Dyndolod config .ini file to set maximum grass lod slope/angle in degrees? Any grass plants in the cache with a slope greater than that are automatically ignored by Dyndolod. Obviously then transition would still be a little odd when the bald side of a hill suddenly has grass, but for me at least that is preferable to the hillside having "X's" from a distance.

Thanks for all the effort you put into Dyndolod! Observation: grass lods on the sides of grassy hills (hillside is greater than maybe 35 degree angle) are seen more from the top of the model than the side, especially when you are on a different hill and thus viewing from above. The effect is obviously "X" - shaped things littered on hillsides that I know are grass lods but don't resemble grass at all from that viewing angle. This is most egregious in the Reach where there are lots of grassy hills and not so many trees to block the view. My suggestion is to have an option to rotate all grass lod models on their axis when rendering Dyndolod so they are always fully upright instead of whatever angle/slant the actual grass plant will be when you enter the active cell: that way the side of the model should always be more visible than the top. Thanks again!

Edit never mind I figured it out; had a conflicting mesh version for some trees. Thanks for your help!

Sorry I thought I had fixed it by installing the EVT trunk meshes, but no. The attached pics show the issue: the meshes of both the EVT trunk and the full model, opened via MO2 virtual folder, show the correct texture. The same trunk and model simultaneously viewed via Texgen preview show the old texture. The weird thing is I don't even have that texture installed anymore! What is happening??

Where would I find the trunk NIF to check the texture path? Is it different from the full model NIF? I didn't actually change the texture path on the full model NIF; I just renamed new textures to match the original ones (I thought that would be more compatible). I am using Enhanced Vanilla Trees which uses a lot of alternate trunk textures.

I think I am missing something: I changed the tree trunk textures of my snow pine trees to be more browns rather than all boring greys. Looks great in full model and Texgen-generated billboard, but Texgen doesn't seem to be updating the colour of the ultra lod trunk - they still look grey from a distance in-game and then turn brown when the full model loads, and viewing the 3d ultra lod tree model in the MO2 data folder also shows a grey trunk. Did I miss a step? When running Texgen I selected Tree, HD Tree and Rendered checkboxes in the Tree/Grass section. Thanks!

oh I see. I will see if I can still make a decent billboard manually then! Thanks

Hello! I created green variants of the 6 aspen trees and used them to replace some of the placed trees in the "Great Forest of Whiterun Hold" mod. Works and looks great! The only issue is the green version of TreeAspen04 isn't recognized by either Dyndolod or Texgen and is skipped. I suspect I could add a new rule to Dyndolod for that specific mesh if I had to, but how do I get Texgen to make the billboard? Since it is a small tree (or large bush?) I am ok with LOD4 being a billboard rather than a 3D ultra lod. I verified it has all the same field values as the other aspen variants, which are all automatically recognized and included by Texgen/Dyndolod. I added the "has distant lod" flag to see if it would make a difference but it has not.

got it. Thanks!

I ran it again (a 3rd time) and it worked! Thanks! Question: is there a setting in Dyndolod to allow these birds to be seen from inside a city (not using open cities)? For example, there are quite a few circling in the sky over the Windhelm docks but no sign of them from inside the city's child space. Or would the author have to also place some birds inside the child space to fake that effect?

I installed Crows SSE and Seagulls of Skyrim and hope to be able to see them from a distance, but both just become visible when their cells become active. I removed any LOD file they came with and added separate mesh rules for each of their models: levels 4,8,16 are blank, VWD checked, Far LOD and Reference unchanged (Seagulls has a Dyndolod .ini file with this rule but it didn't automatically load in my Dyndolod rules list). Clearly I am misunderstanding something though because they still abruptly appear when I am quite near and disappear when their cell is unloaded. LODGen165=Beyond Skyrim\Mr_Siika\Seagulls\SKY_SeagullCircleCW.nif,,,,Far LOD,Unchanged,1 LODGen166=Beyond Skyrim\Mr_Siika\Seagulls\SKY_SeagullCircleACW.nif,,,,Far LOD,Unchanged,1 LODGen167=Beyond Skyrim\Mr_Siika\Seagulls\SKY_SeagullAnimRight.nif,,,,Far LOD,Unchanged,1 LODGen168=Beyond Skyrim\Mr_Siika\Seagulls\SKY_SeagullAnimLeft.nif,,,,Far LOD,Unchanged,1 LODGen169=Beyond Skyrim\Mr_Siika\Seagulls\SKY_SeagullFlapX.nif,,,,Far LOD,Unchanged,1 Am I using inappropriate rules, or is there another step I have missed to get these to register with Dyndolod? Thanks!

Please disregard: I ran once more over night and the latest output works properly! Don't know what changed but is good now. Thanks!

I know I am doing something wrong but don't know what it is, and can't find any relevant documentation on it. Basically I added The Great Forest of Whiterun Hold (TGFWH) to my load order, and have now run Dyndolod 4 times and it seems to ignore the trees etc added by TGFWH every time. Those added trees don't appear in game until up close, and I can see that TGFWH isn't even added as a master to the Dyndolod plugin. TGFWH works in-game so I know it is activated and working properly, and Dyndolod works in-game too because trees added by other mods are still visible in the distance. I can see in the log that Dyndolod sees the TGFWH plugin, and don't see any errors. I deleted the cache. I am no newbie at running Dyndolod, but I did just switch to MO2 so maybe that is something? I am running Dyndolod via MO2, and the previous Dyndolod I ran via MO2 prior to installing TGFWH worked flawlessly. Also I know TGFWH works with Dyndolod because I had it installed about 8 months ago and it was wonderful, but my system at the time couldn't handle the extra load. I think I am losing my mind! Any suggestions? EDIT: I may have found the problem but don't know how to fix it. I added a "patch" .esp after TGFWH to change about 50% of its added tree references from pine trees to aspens - I just used a script to change the "Name - Base" field from one tree base record to another. That works fine in-game, but I noticed a line in the log that says "[00:00:21.589] <Warning: 430 duplicate FormID numbers of trees references were detected, excluded from LOD>". That isn't attached to any plugin in particular but it is a huge number compared to previous logs from before TGFWH; I wonder if it is ignoring both plugins (TGFWH and the patch) because the patch overrides all the trees and so Dyndolod thinks it is all duplicate? Clearly I still want it to generate LOD for the winning record. I will try to Z-merge the 2 together so they aren't duplicating each other and see what happens.

Thanks for the response! I have now turned off the Large Ref fix. Time to try out v3.0!

I am having a couple issues (latest Dyndolod/texgen release, but happened in older version I was using before too). Dyndolod doesn't seem to be using the texgen output. I run texgen, verify its output reflects the current textures, install it (and see it in the appropriate data\textures\lod folder afterwards) but when I then run Dyndolod it seems to ignore those textures. For example, large lod like Whiterun city walls and the Mage's College clearly change from a different color to the correct color when I approach it. Ultra tree lod trunks also seem to be a different color. Am I missing a step? I added a rule to have mountains and cliffs use full model in lod 4, and lod 4 in lod 8, which looks great! I also upgraded near grids, used original lod assignments, and enabled the largerefs fix in the MRM. Running ulargereflodgridsize=5. But some "transition rock" meshes on the sides of mountains now flash from a distance like they are trying to show 2 slightly different meshes/textures simultaneously. Also, snow on mountain rock changes dramatically from LOD4 level to the loaded cell, as does shadow on mountain rock. Usually LOD4 has more snow and less shadow than the loaded cell. Is there a way to completely disable the fade from LOD4 to active cell (like just do an instant change instead)? Or make it actually fade? Right now mountain ledges seem to "strobe" for a second or two, which wouldn't matter since I am running full mesh in LOD4, except for the huge discrepancy in shadow and snow mentioned above - so it looks like shadow and/or snow are strobing as I approach mountain rock and it is very distracting. I turned the "time to fade in from black" in the MRM to 0.00 but that made no difference. Thanks!

ok thanks for the reply! I will wait and hope Meh321 eventually makes a VR-compatible version.

Would this be possible in VR? I recognize you have no control over the fact that No Grass in Objects and its requirements are SSE - only, but what if I ran the pre-cache on SSE using the same grass mod, and then used the resulting .CGID grass cache file to generate VR Dyndolod?

You are amazing! Appreciate all your hard work!