Jump to content

Recommended Posts

Posted
16 minutes ago, ikonomov said:

I decided to try xLODGen yesterday and see if I can get some better terrain lod textures than the terrain mod I had previously to use together with DynDOLOD 3.0 and grass billboards.  The results are fantastic, and despite my initial expectations it was very easy to generate, really no different to using DynDOLOD.  I also made a 1024x1024 noise texture that I want to share that gives slightly more detail https://www.nexusmods.com/skyrimspecialedition/mods/47057/.  I also tried 2048x2048 noise texture, but it looked too nice lol.  Once the cell rendered there was a decrease in quality and detail rather than the other way around.  I think 1024x1024 is a happy medium that gives slightly more detail to the 512 one included on the first page.  The overall brightness has also been ever so slightly increased.

I have a suggestion that I want to give purely from a new user perspective.

From what I could find, there are two really well done videos for using DynDOLOD by the awesome guy from GamerPoets, but none for using xLODGen.  Since most people using xLODGen will likely be familiar with DynDOLOD, is it possible to have the default output folder for xLODGen to be something like say "xLODGen_Output" the same way it is for TexGen or DynDOLOD?  This way it will be consistent with the other two programs and also allow people to manually install the files and be able to easily uninstall them later.  I run mine with -sse -o:"C:\Games\Tools\xLODGen\xLODGen_Output\" command line, which does the same thing, but why not have it the same as DynDOLOD and TexGen.

Thank you sheson for your amazing work.

I added a link to the noise texture mod to the first post.

xLODGen is a renamed xEdit. xEdit is an advanced multi purpose modding tool replacement for CK. It allows every freedom and responsibility to use it as anyone wants.

DynDOLOD is the advanced and easier version of xLODGen for object, tree LOD (and Occlusion) generation for Skyrim. It enforces the output path to protect users from themselves and their laziness to read or follow instructions. e.g. it makes the use of advanced modding tools easier.

The different versions of the same tool have different philosophies and goals. At some point in the future an easier terrain LOD generation might be part of the DynDOLOD version.

  • Like 1
Posted (edited)
28 minutes ago, sheson said:

I added a link to the noise texture mod to the first post.

xLODGen is a renamed xEdit. xEdit is an advanced multi purpose modding tool replacement for CK. It allows every freedom and responsibility to use it as anyone wants.

DynDOLOD is the advanced and easier version of xLODGen for object, tree LOD (and Occlusion) generation for Skyrim. It enforces the output path to protect users from themselves and their laziness to read or follow instructions. e.g. it makes the use of advanced modding tools easier.

The different versions of the same tool have different philosophies and goals. At some point in the future an easier terrain LOD generation might be part of the DynDOLOD version.

Thank you for adding the link.  I am ashamed to admit how many hours I worked on that one texture file, trying probably more than 40 versions in-game.  It would be awesome if people find it useful.

Also thank you for the explanation about DynDOLOD and xLODGen.  I have been using SSEEdit for a long time now, which must originate from xEdit the same way as your programs do.  I think it would be a fantastic idea to combine terrain LOD generation into TexGen, the same way you added the tree billboard generation.  I must admit that I have been shying away from xLODGen to generate the terrain because of the introduction on the first page even thought I've done quite a bit of modding myself with SSEEdit.  While most people must be trying first, and then reading, I read the post quite a few number of times before deciding to try it lol.

Edited by ikonomov
Posted (edited)

If an object disappears as you get close to it, is that because of the occlusion data? I reran occlusion with the latest beta 75 and the palace of the kings in SE is disappearing as you approach it:

https://i.imgur.com/27hoxae.jpg

Nope =/ disabled occlusion and it's still happening. Maybe someone knows what could be going on still?

 

EDIT: found the culprit, it's the better dynamic snow patcher that's touching the static object of the Palace.

Edited by Illana
Posted

My LOD, and map, are gorgeous now. Wow... Thank you. I wish I had looked into xLODGen earlier.

The coastlines are accurate. I can see islands I couldn't see before. There's no water z-fighting (Probably thanks to the optimize unseen setting being at the newbie-recommended 550 instead of on?). And of course the LOD is better everywhere else too, but the coastlines make the biggest difference to me.

Just... thank you. I'm in awe. The thread is probably mostly filled with support questions... I'm leaving an appreciation comment for a change.

  • Like 2
Posted
20 minutes ago, TechAngel85 said:

@sheson, quick question...

I've gone through Docs and this forum. I've only seen Optimize Unseen being mention set to numbers on LOD32. Do the number settings work on LOD8 & LOD16 too, or just the map?

Each setting that can be set differently for each of the LOD levels is applied to that LOD level accordingly.

  • 2 weeks later...
Posted (edited)

This is probably expected behavior, but in the shallow waters north of Morthal I noticed some z-fighting with fairly large areas flickering.  It is only happening at a distance, so it must be either in LOD8 or LOD16.  Having the Optimize Unseen to On and Off results in the same behavior from what I could see, but with 550 it disappeared.  I have uLargeRefLODGridSize=11 (Ultra) and with 550 if there is some shifting going on when I get closer into LOD4 (Optimize Unseen Off) it is too far for me to see it.  So for some people 550 might be the preferred setting to use for LOD8 and LOD16 as well as the LOD32 map meshes.

Edited by ikonomov
Posted (edited)

Actually I'm still seeing flickering around the edges between water and land at a distance with 550 for Optimize Unseen for LOD8 and LOD16.  When I tried On and Off it was more pronounced covering larger areas.  I'm observing this by looking at the shallow water area north of Morthal.  I'm standing near the Lord Stone in the mountain.  Any suggestions to minimize this?

Thank you

Edit: I noticed some z-fighting in other places like around rocks.  Prior to using xLODGen for terrain textures I was using only Terrain LOD Redone and I don't remember seeing much of z-fighting then.  Do you have any insight about why there seems to be more with xLODGen?

Edited by ikonomov
Posted
4 hours ago, ikonomov said:

This is probably expected behavior, but in the shallow waters north of Morthal I noticed some z-fighting with fairly large areas flickering.  It is only happening at a distance, so it must be either in LOD8 or LOD16.  Having the Optimize Unseen to On and Off results in the same behavior from what I could see, but with 550 it disappeared.  I have uLargeRefLODGridSize=11 (Ultra) and with 550 if there is some shifting going on when I get closer into LOD4 (Optimize Unseen Off) it is too far for me to see it.  So for some people 550 might be the preferred setting to use for LOD8 and LOD16 as well as the LOD32 map meshes.

Obviously the large reference system has no effect on terrain or terrain LOD.

Test and a find a different values for LOD level 8 and 16 that work best for the load order and the setup, then let us know your results. However, you can not expect z-fighting between terrain and LOD water to magically disappear, only be less pronounced.

1 hour ago, ikonomov said:

Actually I'm still seeing flickering around the edges between water and land at a distance with 550 for Optimize Unseen for LOD8 and LOD16.  When I tried On and Off it was more pronounced covering larger areas.  I'm observing this by looking at the shallow water area north of Morthal.  I'm standing near the Lord Stone in the mountain.  Any suggestions to minimize this?

Thank you

Edit: I noticed some z-fighting in other places like around rocks.  Prior to using xLODGen for terrain textures I was using only Terrain LOD Redone and I don't remember seeing much of z-fighting then.  Do you have any insight about why there seems to be more with xLODGen?

Obviously, the used LOD generator does not change how the engine works or why things z-fighting. Lower quality terrain LOD meshes with larger triangles that might have less intersections with other objects.

Posted
9 hours ago, sheson said:

Obviously the large reference system has no effect on terrain or terrain LOD.

Test and a find a different values for LOD level 8 and 16 that work best for the load order and the setup, then let us know your results. However, you can not expect z-fighting between terrain and LOD water to magically disappear, only be less pronounced.

Obviously, the used LOD generator does not change how the engine works or why things z-fighting. Lower quality terrain LOD meshes with larger triangles that might have less intersections with other objects.

Thank you for the reply.  Lots of things must be obvious to you, but probably less obvious for the rest of us.  Sorry for the trivial questions.

If some z-fighting is to be expected then I think the 550 for all LOD8, LOD16 and LOD32 seems to work fairly well.  There is still a little bit of flickering, but the water line looks to be almost intact and I see little change to it going into LOD4.  It must be a good balance I think.

There is one big rock wall that I was looking at which was exhibiting a huge amount of z-fighting.  I looked at it closer and I don't think the problem is with the LODs.  When I'm right next to it I can clearly see a landscape mesh and a flat rock mesh overlapping and fighting with each other as they are mostly on the same plane.  The two meshes slowly shift from one to the other as I'm walking right next to it.  The only way this wouldn't have shown in the Terrain LOD redone is if he edited that mesh manually, which I don't think he did, so it must be that I simply didn't notice it before.

Posted
1 hour ago, ikonomov said:

Thank you for the reply.  Lots of things must be obvious to you, but probably less obvious for the rest of us.  Sorry for the trivial questions.

If some z-fighting is to be expected then I think the 550 for all LOD8, LOD16 and LOD32 seems to work fairly well.  There is still a little bit of flickering, but the water line looks to be almost intact and I see little change to it going into LOD4.  It must be a good balance I think.

There is one big rock wall that I was looking at which was exhibiting a huge amount of z-fighting.  I looked at it closer and I don't think the problem is with the LODs.  When I'm right next to it I can clearly see a landscape mesh and a flat rock mesh overlapping and fighting with each other as they are mostly on the same plane.  The two meshes slowly shift from one to the other as I'm walking right next to it.  The only way this wouldn't have shown in the Terrain LOD redone is if he edited that mesh manually, which I don't think he did, so it must be that I simply didn't notice it before.

Terrain and terrain LOD is the ground you walk on. Reference records in plugins place objects defined by base records. Reference in loaded cells can typically be clicked on and have form ids.  Objects have their LOD done in object LOD.  Large references are  references that also show outside the loaded cells in the LOD area a bit further before they switch to LOD. If references have a tree base records or a  static base record flagged as having tree LOD,  they are part of billboard tree LOD. Most of these things are well documented in the CK wikis and other guides for the may games that xLODGen supports.

If you believe a problem has to do with LOD, turn off LOD with tll in console to see if the problem goes away. It always turns off all LOD.

However, typically a rock wall is an reference and if that flickers with LOD, the LOD is typically object LOD. If that happens just outside the loaded cells, it is large reference bugs.

If this happens inside the load cells, that it is stuck object LOD after fast travel, that can be fixed by not using ultra settings or by changing the fBlockLevel0Distance a bit. From 60000 to 57000 for example.

 

Posted (edited)
2 hours ago, sheson said:

Terrain and terrain LOD is the ground you walk on. Reference records in plugins place objects defined by base records. Reference in loaded cells can typically be clicked on and have form ids.  Objects have their LOD done in object LOD.  Large references are  references that also show outside the loaded cells in the LOD area a bit further before they switch to LOD. If references have a tree base records or a  static base record flagged as having tree LOD,  they are part of billboard tree LOD. Most of these things are well documented in the CK wikis and other guides for the may games that xLODGen supports.

If you believe a problem has to do with LOD, turn off LOD with tll in console to see if the problem goes away. It always turns off all LOD.

However, typically a rock wall is an reference and if that flickers with LOD, the LOD is typically object LOD. If that happens just outside the loaded cells, it is large reference bugs.

If this happens inside the load cells, that it is stuck object LOD after fast travel, that can be fixed by not using ultra settings or by changing the fBlockLevel0Distance a bit. From 60000 to 57000 for example.

 

It was a snow covered area with loose/smaller rocks surrounded by some large rocks.  Using the tll command revealed the area to be part of a large reference.  When the cell fully loads there appears to be another mesh of snow cover on top of the loose/smaller rock area that's partly covering it.  It doesn't seem to be related to fast traveling.  Once the LOD is turned off the flickering disappears.  So I guess the problem is from the LODs, but looking closely at those two meshes they are almost on the same plane, next to each other overlapping, it seems reasonable to see this especially if some z-fighting is to be expected as with the water line.

Edited by ikonomov
Posted
13 minutes ago, ikonomov said:

It was a snow covered area with loose/smaller rocks surrounded by some large rocks.  Using the tll command revealed the area to be part of a large reference.  When the cell fully loads there appears to be another mesh of snow cover on top of the loose/smaller rock area that's partly covering it.  It doesn't seem to be related to fast traveling.  Once the LOD is turned off the flickering disappears.  So I guess the problem is from the LODs, but looking closely at those two meshes they are almost on the same plane, next to each other overlapping, it seems reasonable to see this especially if some z-fighting is to be expected as with the water line.

Turn off large references to verify if it is a large reference bug.

If it is the case, check the DynDOLOD log for the lines that tell which references and plugins are causing them.

Posted
12 minutes ago, sheson said:

Turn off large references in the INI to verify if it is a large reference bug.

I changed uLargeRefLODGridSize to 0, and the flickering seems gone.  Did a number of tests moving closer and far away and I don't see it.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.