doodlum

Recently I presented a method in which I have used the DynDOLOD Glow LOD to create lights which extend across the whole map. LLF Infinite Lights Distance I am currently working to smoothly blend these lights in and out, however I am unsure how DynDOLOD is enabling these in the distance and fading them out when close. I would appreciate clarification over what nif properties or whatever else, is controlling this. Further to this, DynDOLOD may need to be expanded in the future to better support these lights. These lights ideally need to be active for all static lights so an option to enable this may be worth being made clear in the inis or the advanced menu itself. Currently, I am using the bounds of the geometry for the radius and position, and using the emittance, with optional culling of the original mesh which can boost performance. On my side, there is no performance impact from having any number of lights so it is totally fine have as many lod lights as we want.

Thanks for the response. Yeah I was unsure if you'd be able to do it. Just making sure before I started work on the runtime version.

I'm looking at implementing a form of large-scale occlusion, similar to ENB skylighting. The original presentations which used this technique, render the depth maps offline. To render offline would make the effect have almost no cost to performance, otherwise I need the basically render the game twice. I don't know if it is possible for DynDOLOD to render out depth maps. But if it was possible to render out a depth texture of each cell, which I can then use at runtime. That would be amazing. Furthermore if the textures had mipmaps, it would be possible to approximate shadows on very distant terrain which would be impossible to do at runtime otherwise. This is the simplest form of large-scale occlusion for interactive framerates. This is used by Red Dead Redemption 2.

Awesome! One thing with that page is that it doesn't reference complex grass support from community shaders. It should make clear anything ENB does, community shaders does too. With grass I actually use vanilla lighting code where the soft lighting/backlighting color is the diffuse. So for grass LOD it might be able to match almost perfectly. If there's an easy way for me to detect grass LOD I could also just inject separate lighting code.

Thanks! I think I will try to release this today. I need to just add that additional check and some additional code to the project which hosts this.

Awesome! I'll be releasing this soon. It would be good to have a way to check the dyndolod output to see if it was made with complex tree LOD like a simple ini file, then I don't need users to manually toggle it within the mod.

I've tested the normals. https://imgur.com/a/aRY1pOj It does work correctly but it just can't match even the basic ultra object LOD in consistency. It may be worth using this feature, only for high performance setups. So I'm fine with this not being released, up to you.

Thanks! I will test this now. Sorry, how can I set the lod levels to match?

I did a test using the current DynDOLOD. Same settings apart from tree LOD(with new shaders in complex mode) vs object LOD. This was overlooking Riften with Engine Fixes installed, probably the worst-case. Tree LOD in complex mode: 87fps, 69fps 99% average "Ultra" object LOD using default resources, high preset, and "ultra" ticked: 73fps, 61fps 99% average Edit: Looks like this setting by default is 3D... I will need to test again.

Ah I didn't see this page, only looked at the other ones. I'll note what could be fixable: "No normal map textures resulting in limited lighting." - Fixed. "No x or y rotation angles, always pointing straight up." - This could be done slightly randomly, otherwise unlikely to be fixable. "Fixed billboard center, so there can be a lot of transparency overdraw because diffuse textures can not be trimmed." - As far as I know, the game still uses z-prepass culling on tree LOD, so I don't know how important this actually is. The CPU is more limiting than the GPU due to the single-threaded renderer so even if there's a tradeoff it may still be worth it. "One billboard side per tree." - Can be done randomly. Still needs to fit into the atlas, or needs multiple atlas textures. "One tree LOD atlas texture per worldspace. Maximum of 256 billboards per tree LOD atlas texture/worldspace." - Sounds unlikely to hit this? "Tree LOD only unloads correctly if the load order of plugins adding tree references does not change after tree LOD generation. Tree LOD in parent worldspace used for LOD does not unload in child worldspaces. Tree LOD does not unload for references added by ESL flagged plugins. FPS problems in Skyrim when 3rd person camera crosses cell borders." The first two might be fixable with changes to EngineFixesSkyrim64/treelodreferencecaching.cpp otherwise probably aren't fixable without addtional data. It's worth me noting that the instance buffer has 8 unused floating point values. It may be possible to upload additional tree data as long as it is cached. e.g. taking the tree ref's rotation.

Thanks for answering. Yeah, right now the bottom half is the normal + additional mask. One idea I had was an ambient mask, which could be used to simulate shadows relative to the horizon vector of the sun? So then the diffuse of the atlas is actually just purely the original colour. I'm not sure how correct that is. Regardless there can't be "ambient" or "diffuse" modifiers, a tree needs to match the lighting of the original model I think. Because the vertex normals are not present, the "sphere map" method is ideally baked in somewhere. Yeah there's no benefits apart from as I understand it, slightly better performance, primarily with draw calls. And the ability to simulate more advanced lighting. Object LOD is still needed for edge case so tree LOD would need to be almost visually indistinguishable, at least at a distance. i have not tested the "ultra" tree lod so there may be additional performance impacts from that. It only uses one billboard right now, but what I can actually do is use the normal vector to select a different atlas offset. So there could be as many tree billboard versions that fit within a 16k texture, or I can actually load additional separate textures if that's better.

I made a shader modification for tree LOD where I'm currently happy with the results. Because lighting is simulated through normal maps, it would need DynDOLOD to support it by adding a config to check for what worldspaces use the format, and drawing out normals to the bottom of the atlas. There's an additional mask in the alpha channel available which is unused. Additionally the atlas could be tiled further for additional masks. Only the texture coordinate is available for unique information about the current pixel. The vanilla shader is so stripped down there is only that. Additional information is provided through RE plus generated normals and tangents. https://www.nexusmods.com/skyrimspecialedition/images/182805 I don't really know how good of an option this is. If it's a bad idea or just won't be supported then I'll drop this. It should theoretically be beneficial in bottlenecked situations over object LOD, and can be tweaked specifically for flora