Gildergreen LOD revisited

[VaultDuke]

With the USKP .esm transition now in place, what are the chance that we could try to get the Gildergreen LOD working again durin ghte next beta?

 

issue is, somehow the gildergreen doesn't show up in LOD, and simply ticking some flag iirc didn't do the trick. instead, the gildergreen in one version of the USKP was tranported to the Tamriel worlspace and set to full LOD over there.

(in another version, the Gildergreen was disabled and injected references were set to the opposite enable state, again they were located in the tamriel worldspace and set to full LOD. this just for reference, i think it was the most buggy version)

 

anyway, the gildergreen would not propperly show up inside Whiterun anymore. or at least not reliable, only being visible when loading directly inside whiterun. if a safe game was loaded from inside a building, the gildergreen would not be visible when entering whiterun. only to return, when leaving and then again reentering whiterun, or when fast travelling to the city.

 

this sound awfully close to the issues that were supposedly fixed by the .esm conversion.

so, for the next beta, i propose, we give it a try again, with the gildergreen transported to the Tamriel worldspace and given the full LOD flag.

(to be honst, i don't quite understand, why the gildergreen could not actually be set to ful LOD inside the whiterun worldspace, but whatever)

 

edit: first version:

http://www.afkmods.com/index.php?/tracdown/issue/912-gildergreen-tree-lod-missing/

(gildergreen doubled)

 

resulted in:

http://www.afkmods.com/index.php?/tracdown/issue/11911-gildergreen-in-tamriel-worldspace-double-feature/

two gildergreen visible if you looked very very closelly (i.e. i was the only one to complain,and others had trouble veryfying :-D)

 

was fixed by disabling the Gildergreen in Whiterun worldspace. resulted in more issues (see comments)

and also see separate tracker entry:

http://www.afkmods.com/index.php?/tracdown/issue/12163-gildergreen-vanishes-from-whiterun-and-ends-up-in-tamriel-worldspace/

 

i think we should give this last version of the fix (from USKP 1.3.0) a try again, since it might just work now with USKP.esm

 

but again: what was the original decision to not simply set the gildergreen to full LOD inside the whiterun worldspace?

[Nico coiN]

There are 2 Gildergreen versions. The 'old' (big) one and the sapling. They're both embeded one in the other and they have dedicated enable parents. Maybe there are even more versions in the 'Gildergreen regrown' mod from Arthmoor (unless it uses a scripted scale modification, I don't know). And the Gildergreen LOD is not supposed to be seen only in Whiterun worldspace. You normally can see it from a few various spots in the Tamriel worldspace (try this savegame and just look...) Gildergreen is not as the other common trees of the game with a unique LOD. We have two of them, but we cannot have 2 LOD versions (I mean 2 low-poly meshes, just as every other objects LOD in the game) due to an engine limitation : objects LOD are not affected by the flag 'visible when distant'...

 

A given object with LOD enabled in worldspace A 'propagates' in worldspace B if A is the B parent (with A = Tamriel worldspace    and    B = Whiterun worldspace). So, if something has to be done using the 'visible when distant' flag, then it should first be done in Tamriel worldspace. This should work in theory, but the game engine seems to decide otherwise...

[VaultDuke]

hm, as i said, i don't understand enough of it.

 

here are the links to the two bug reports, that describe the odd Worldspace-overlapping bugs and the main reason for the esm conversion

 

http://www.afkmods.com/index.php?/tracdown/issue/13424-issue-with-overlapping-cells/

http://www.afkmods.com/index.php?/tracdown/issue/68-incorrect-tree-and-rock-lod-from-within-solitude/

 

so, the only thing i get from this is:

overlapping cells behaved odd before the conversion.

the gildergreen fix didn't work because of odd overlapping cell behavior.

now the overlapps in USKP behave better

maybe this will also extend to the gildergreen and one of its old solutions.

[Arthmoor]

The Gildergreen is 3 distinct objects though.

 

One is the dead version you start the game with. One is the full grown version you get by bringing sap back. One is the sapling version you get by bringing the sapling back. The game cannot dynamically switch between these 3 different versions of the tree so it would only ever be right for part of the game, then wrong for the rest of it.

 

Tricking it using the "is full lod" flag won't work and the esm conversion didn't change this. There's something more fundamentally wrong with their LOD system than that.

[VaultDuke]

i think i'm missing some steps of that logis.

are you saying objects with the full LOD flag set can not be dynamically disabled and enabled. it this what is making this so complicated?

[lmstearn]

Arthmoor has recently made the observation that "LOD is pregenerated data" The binding of an object and its LOD is such that disabling the LOD of an object is to disable the object itself.