xLODGen - Terrain LOD beta 129 for FNV, FO3, FO4, FO4VR, TES5, SSE, TES5VR, ENDERAL, ENDERALSE

[sheson]

8 hours ago, Mousetick said:

xLODGen b101 Combine Worldspaces

I'd like to try the provided Tamriel_Combine.ini to put Solstheim LOD in Tamriel. Before I do, I have a one question.

[DLC2SolstheimWorld]

(... stuff omitted for brevity ...)

; Always replace existing cell/land data for terrain LOD inside these cell coordinates of the destination worldspace
ForceSouth=37
ForceWest=50
ForceNorth=63
ForceEast=76

I understand the above settings are going to place Solstheim in the upper right corner of Tamriel in a rectangle bounded by cell 50,37 to cell 76,63. That's not very far from the Tamriel coast, but there is a lot of water around Solstheim so the island would appear farther.

https://dyndolod.info/Help/Combine-Worldspaces-for-LOD

I don't use a satellite view map, I use a paper map of Tamiel instead. I don't generate object LOD Level 32. So this feature would not be useful to me.

I'm wondering if the Solstheim LOD would still be a visually useful addition when viewed from the Tamriel "overworld". Could you give a rough idea of what kinds of detail are visible from the College of Winterhold, for example? 

I could try it and see for myself of course, but I thought I could ask first.

PS: More than one question, actually. Are there any plans to do the counterpart, that is combine a part of Tamriel LOD into Solstheim? I guess this would require extending the Solstheim worldspace similar to Tamriel-Extend as vanilla Solstheim is too small?

Thanks.

The example for the feature is based on https://www.nexusmods.com/skyrimspecialedition/mods/48889 "Details for mod authors".

Check/use the mod if you want Solstheim in Tamriel worldspace and vice versa.

[Mousetick]

xLODGen b101 Combine Worldspaces

Does the <worldspace>_Combine.ini file support specifying the same source worldspace multiple times, to combine several rectangles into the destination, or should separate INI files be used?

Example of combining 2 separate rectangles from Tamriel into Solstheim:

Spoiler

[Solstheim]
(... details omitted for brevity ...)

[Tamriel]
(... details omitted for brevity ...)

; Source rectangle 1 coordinates
(... details omitted for brevity ...)

; Destination rectangle 1 coordinates
(... details omitted for brevity ...)

[Tamriel]
(... details omitted for brevity ...)

; Source rectangle 2 coordinates
(... details omitted for brevity ...)

; Destination rectangle 2 coordinates
(... details omitted for brevity ...)

The Readme says:

Quote

Add as many different source worldspace sections as needed.

Thanks.

[sheson]

1 hour ago, Mousetick said:

xLODGen b101 Combine Worldspaces

Does the <worldspace>_Combine.ini file support specifying the same source worldspace multiple times, to combine several rectangles into the destination, or should separate INI files be used?

Example of combining 2 separate rectangles from Tamriel into Solstheim:

  Hide contents

[Solstheim]
(... details omitted for brevity ...)

[Tamriel]
(... details omitted for brevity ...)

; Source rectangle 1 coordinates
(... details omitted for brevity ...)

; Destination rectangle 1 coordinates
(... details omitted for brevity ...)

[Tamriel]
(... details omitted for brevity ...)

; Source rectangle 2 coordinates
(... details omitted for brevity ...)

; Destination rectangle 2 coordinates
(... details omitted for brevity ...)

The Readme says:

Thanks.

Use
[Tamriel]
[Tamriel1]
[Tamriel2]

Can not guarantee it works.

[Mousetick]

12 hours ago, sheson said:

Use
[Tamriel]
[Tamriel1]
[Tamriel2]

Can not guarantee it works.

Thanks. I tried it, it seems to work fine with xLODGen but then DynDOLOD fails when generating the Tamriel object LOD because the same atlas textures are listed twice (once for each Tamriel rectangle, I guess). I'm going to make a separate report in the DynDOLOD topic.

I like the Combined Worldspaces approach better than https://www.nexusmods.com/skyrimspecialedition/mods/48889 because it 100% reflects the load order and the process is completely automated.

Edited October 1, 2023 by Mousetick

[Mousetick]

xLODGen b101 Combine Worldspaces

From Combine-Worldspaces-Readme.txt:

Quote

The process will automaticaly use data for a cell from additional worldspaces in case the destination worldspace does not have data for that cell.

This is a bit vague. What "data" is this referring to exactly? The cell record itself? The LAND record? Anything else?

; Always replace existing cell/land data for terrain LOD inside these cell coordinates of the destination worldspace
; If commented out no destination cell/land record is replaced
;ForceSouth=0
;ForceWest=0
;ForceNorth=0
;ForceEast=0

If I'm reading correctly, a destination cell that already exists (has a CELL record in the destination worldspace, potentially containing a LAND record) is skipped. Unless it is located within the Forced bounds - in which case, the CELL+LAND records of the source worldspace are used for terrain LOD. Is this correct?

Does this have any meaning to DynDOLOD for object LOD? As an experiment, I tried combining JaphetsFollyWorld into Tamriel. Japhet's Folly is located on a small island north-east of Winterhold, which already exists in Tamriel. From the results I got, it looked like the source cells were ignored by DynDOLOD. I assumed it was because the destination cells already contained object references.

Thanks.

[sheson]

2 hours ago, Mousetick said:

xLODGen b101 Combine Worldspaces

From Combine-Worldspaces-Readme.txt:

This is a bit vague. What "data" is this referring to exactly? The cell record itself? The LAND record? Anything else?

; Always replace existing cell/land data for terrain LOD inside these cell coordinates of the destination worldspace
; If commented out no destination cell/land record is replaced
;ForceSouth=0
;ForceWest=0
;ForceNorth=0
;ForceEast=0

If I'm reading correctly, a destination cell that already exists (has a CELL record in the destination worldspace, potentially containing a LAND record) is skipped. Unless it is located within the Forced bounds - in which case, the CELL+LAND records of the source worldspace are used for terrain LOD. Is this correct?

Does this have any meaning to DynDOLOD for object LOD? As an experiment, I tried combining JaphetsFollyWorld into Tamriel. Japhet's Folly is located on a small island north-east of Winterhold, which already exists in Tamriel. From the results I got, it looked like the source cells were ignored by DynDOLOD. I assumed it was because the destination cells already contained object references.

Thanks.

In case of terrain LOD if the destination worldspace does not have a LAND record, the data from the LAND record of the source worldspace is used but it should use the data (waterheight) from the CELL record of the destination worldspace.
In case of object LOD, it means a cell that has no object LOD in the destination worldspace.
In case of tree LOD, it means a cell that has no tree LOD in the destination worldspace.

[Mousetick]

2 hours ago, sheson said:

In case of terrain LOD if the destination worldspace does not have a LAND record, the data from the LAND record of the source worldspace is used but it should use the data (waterheight) from the CELL record of the destination worldspace.
In case of object LOD, it means a cell that has no object LOD in the destination worldspace.

Thanks for the clarification. I feel there is still room for interpretation, so I made the following table. Could you please review it, let me know if it is accurate, and possibly fill in the blanks?

Spoiler

+----------------- +                          +-----------------------+
| Destination cell |                          | Combined Terrain LOD  |
+------------------+--------------------------+-----------------------+
| No CELL record                              | Source CELL+LAND      |
+---------------------------------------------+-----------------------+
| CELL record without LAND                    | Source CELL+LAND      |
| Outside Force SW-NE bounds                  | Dest water height     |
+---------------------------------------------+-----------------------+
| CELL record with LAND                       | Destination CELL+LAND |
| Outside Force SW-NE bounds                  | (Source ignored)      |
+---------------------------------------------+-----------------------+
| CELL record                                 | Source CELL+LAND      |
| Inside Force SW-NE bounds                   | Dest water height     |
+---------------------------------------------+-----------------------+

+------------------+                          +-----------------------+
| Destination cell |                          | Combined Object LOD   |
+------------------+--------------------------+-----------------------+
| No object LOD                               | Source                |
+---------------------------------------------+-----------------------+
| Has object LOD                              | ?                     |
| Outside Force SW-NE bounds                  |                       |
+---------------------------------------------+-----------------------+
| Has object LOD                              | ?                     |
| Inside Force SW-NE bounds                   |                       |
+---------------------------------------------+-----------------------+

 

I didn't understand why we needed to specify the coordinates of the destination rectangle in ForceSouth/West/North/East since they can be easily calculated by xLODGen or DynDOLOD from the coordinates of the source rectangle + CellX/Y offsets. In most cases, we can simply specify the destination worldspace's cell limits, meaning 'combine and replace LOD with source everywhere applicable':

; If the destination is in Tamriel
ForceWest=-96
ForceSouth=-96
ForceEast=127
ForceNorth=127

This also makes testing/adjusting the source coordinates a lot easier, no need to update the destination coordinates.

Thanks for reading.

Edited October 8, 2023 by Mousetick

[sheson]

39 minutes ago, Mousetick said:

Thanks for the clarification. I feel there is still room for interpretation, so I made the following table. Could you please review it, let me know if it is accurate, and possibly fill in the blanks?

Ask a specific question/case.

The explanations are the intended/expected behavior. Force always means, the destination is replaced by source.

39 minutes ago, Mousetick said:

I didn't understand why we needed to specify the coordinates of the destination rectangle in ForceSouth/West/North/East

The "Limit" uses the source worldspace coordinates, because that is where the data comes from.
The "Force" uses the destination worldspace coordinates because that is where LOD is combined and checked.
There might be cases where source Limit and destination Force coordinates might need to cover different areas.

[Mousetick]

19 hours ago, sheson said:

Ask a specific question/case.

The specific questions/cases where denoted by a question mark '?' in the previous table.

• What is the object LOD result produced by DynDOLOD when the destination cell already has object LOD and is located outside the ForceSW-NE bounds? Source cell object LOD, or destination cell object LOD, or something else?
• What is the object LOD result produced by DynDOLOD when the destination cell already has object LOD and is located inside the ForceSW-NE bounds? Source cell object LOD, or destination cell object LOD, or something else?

19 hours ago, sheson said:

The "Force" uses the destination worldspace coordinates because that is where LOD is combined and checked.
There might be cases where source Limit and destination Force coordinates might need to cover different areas.

The destination coordinates are solely defined by the LimitWest/South/East/North coordinates + CellX/Y and HeightZ offsets. It doesn't matter what the Force coordinates specify - they don't define the destination. They only specify the area where existing destination LOD is allowed to be replaced by source LOD, if the destination already has terrain/LAND.

The destination area can be resized and moved simply by modifying the Limit coordinates and/or the offsets. Not by modifying the Force coordinates.

As the goal in most cases is to replace the destination LOD with the source LOD, without restriction, it is not necessary to specify Force coordinates that exactly match the coordinates of the Limit rectangle transposed into the destination worldspace. The destination worldspace's cell bounds can simply be used, implying "replace the LOD in whichever destination cell has a corresponding source cell, as defined by the Limit coordinates and offsets."

In fact, I wonder why the Force settings exist. They seem redundant.

Edited October 9, 2023 by Mousetick

[sheson]

The Force settings  applies to cell/land data, terrain LOD. Object and tree LOD is not affected by it in xLODGen/DynDOLOD

On 10/9/2023 at 12:28 PM, Mousetick said:

• What is the object LOD result produced by DynDOLOD when the destination cell already has object LOD and is located outside the ForceSW-NE bounds? Source cell object LOD, or destination cell object LOD, or something else?
• What is the object LOD result produced by DynDOLOD when the destination cell already has object LOD and is located inside the ForceSW-NE bounds? Source cell object LOD, or destination cell object LOD, or something else?

The object LOD of the destination is being used.

[tamrieltwo]

For example, it will successfully generate Tamriel.4.-36.52.btr, but it will fail to generate Tamriel.4.-36.24.btr

There isn't an error message when xLODGen finishes, and I have enough disk space.

The log files say it successfully generated "Finished LOD level Tamriel.4.-36.24.btr [6767/2]" -- but it's missing from the output directory.

LODGen_log.txt: https://pastebin.com/p8xZnyZc

 

 

[sheson]

10 minutes ago, tamrieltwo said:

For example, it will successfully generate Tamriel.4.-36.52.btr, but it will fail to generate Tamriel.4.-36.24.btr

There isn't an error message when xLODGen finishes, and I have enough disk space.

The log files say it successfully generated "Finished LOD level Tamriel.4.-36.24.btr [6767/2]" -- but it's missing from the output directory.

LODGen_log.txt: https://pastebin.com/p8xZnyZc

Moved to the xLODGen Terrain LOD beta thread.

Read the first post and/or the Readme.txt included in the download archive and/or https://dyndolod.info/Help/xLODGen#Installation how to always set a dedicated output folder  outside any game or mod manager folders with the -o command line argument and then install the output as a mod.

The files are saved to the path shown in the log message.
Output: C:\Games\Skyrim Anniversary Edition\Data\meshes\terrain\Tamriel\

If the file does not exist in that folder, it was deleted afterwards or it was placed somewhere else by the mod manager.

[tamrieltwo]

15 hours ago, sheson said:

Moved to the xLODGen Terrain LOD beta thread.

Read the first post and/or the Readme.txt included in the download archive and/or https://dyndolod.info/Help/xLODGen#Installation how to always set a dedicated output folder  outside any game or mod manager folders with the -o command line argument and then install the output as a mod.

The files are saved to the path shown in the log message.
Output: C:\Games\Skyrim Anniversary Edition\Data\meshes\terrain\Tamriel\

If the file does not exist in that folder, it was deleted afterwards or it was placed somewhere else by the mod manager.

Setting the -o flag fixed the issue. I was previously using MO2's "Create files in mod instead of overwrite" but 30% of the output files failed to write to disk when I did that.

[sheson]

6 hours ago, tamrieltwo said:

Setting the -o flag fixed the issue. I was previously using MO2's "Create files in mod instead of overwrite" but 30% of the output files failed to write to disk when I did that.

The files save OK, otherwise the OS would report an error.

Mod managers replace existing files in their respective mod folders.

[Kopachris]

I don't see a link to the source code of your modifications to xEdit in the main post, only a link to the main xEdit GitHub repository. As xEdit is licensed under the Mozilla Public License, which is copyleft, can you please share that code?