Add to my previous post: Warning was "Mesh is too dense"

Where was the stop exactly? Could you specify it (the first part is done by Tesannwyn)


This is a security feature preventing endless loops, if the program tries to put too much vertices in a region (e.g. if you have steps because of inconsistent mods). Just a break condition.


Maybe something remaining from older configurations which were deleted later (landscape extender like Onras heighmaps, or Valenwood Improved)? Or other worldspaces?


When using shapes (default for ultimate) the result should be the same. For strips the tes4ll meshes consume less memory.


If so, it was not planned.What I know is that when entering a new cell, the current LOD is adapted, in order to hide the LOD in the near region. But I have no idea how the game engine structures its data internally


Just as a remark, Auryga managed http://tesalliance.org/forums/index.php?/topic/4341-info-tes4ll-a-new-tool-for-landscape-lod-generation/page__view__findpost__p__71545.

Did you tried already the LLOD system of OBGE?

Valenwood. But Valenwood meets Anequina . I will check out what are the lods looking at this border now.

I no longer have that load order, started a new install and am loading my visual mods bit by bit and regenerating. But if I remember correctly the last three lines mentioned EVE Shivering Isles Easter Eggs.esp then a line with a few characters, then the last Line had a couple characters (possibly only 1) which was a 'C" I believe.

At that point it hung for 15 minutes, no HD activity. So I just closed it and went to the shell.

In the shell, with all the mods chosen in load order, it would not generate, stopped in the beginning sating too many mods. That is when I began to choose a few and the process worked.

On this note, there is an option in the shell when about using shapes (faster but requires more video). When choosing Unlimate, that box remains unchecked.

Based on your response to wkomarecki, I assume this is only a tradeoff between more vram in game vs faster generation in the tool. Visual quality with shapes or stripes should be the same in game?

On a final note, this tool is plain genius. Thanks for making the effort to improve the game.

Question on quad file size:

I've been using increasingly-more-hand-tweaked v210 hi-res mesh sets for some time and am happy 'em it. Decided to take the plunge and give v220 a go. Was surprised at the difference is size of each quad. My v210 hi-res quads are much bigger, even compared to v220 at 'ultimate' meshes. Is this normal? I worry that maybe I'm not using v220 right. (Tried it with the 'shell', while I run v210 manually.)

Also, on those few land-walls that still crop up...what is the trick to knowing where, in relation to a 'wall', to place corrective coordinates? Some of my attempted 'wall' corrections do nothing or make things worse. On the other hand, some corrections are super easy.... bridge ends ... most floaters ... buried land depressions... I nail those almost every time.

-Decrepit-

The limit are 256 mods, by checking all, did you maybe went over this limit?


Yes the number of triangles and vertices are the same. The only difference is that in the later case the already-existing triangles are build to strips. i.e. when you have 2 triangles with the vertex numbers 1-2-3 and 3-2-4, it builds a strip with 1-2-3-4 (just "gluing" the neighbors saves the 2 points). Jumping over the gaps (1-2-3 jumps to 5-6-7) is done by adding fake triangles (1-2-3-3-5-5-6-7). The 2 triangles in the middle (3-3-5 and 3-5-5) are degenerated and removed by your rendering engine in the GPU. The standard meshes of Oblivion contain a lot of degenerated triangles, why I tried to strongly minimize the number. But maybe for a modern graphics card with ~1GB vram the impact between strips and shapes is maybe negligible.


My IC quad (60.00.00.32) has in high res about 450kb and in ultimate about 700kb.


Hmm, hard to tell.... I identify and fix the location from far view, and after I reached the location I set a small network of vertices, trying to take them at prominent places: the lowest points, the edge of the roads (left and right, so after 300-400 units, in bendings also more), at the of stones....

Remember, the triangulation will connect the closest points. If you have a road with U-shape, one should put 2 points at the bottom. This should be a really hard constrain.

EDIT: No idea if this is helpfull, but I used a lot of times the "texture" option in the batch file ("WriteQuad -x=0 -y=0 -tex=60.00.00.32.dds". N.B. the numbering is not consistent, the next quad would be "WriteQuad -x=1 -y=0 -tex=60.32.00.32.dds"):

http://imageshack.us/f/820/icquad.png/

One has to add the path in Nifscope to \texture\landscapelod\generated\

Oho! My My v220 hi-res mesh for that zone was a good bit smaller. Turns out I put too much faith in taking the 'shell' at face-value. I selected its various menu options (hi-res, wall-fix, etc.) but it only spit out 'standard' mid-res sets. Once I saw what was happening I edited tes4ll_all.batch to force it to select hi-res and the other options I wanted. At least I hope I caught everything.

The v220 hi-res set I made afterward was in line with yours.... 60.00.00.32 being 451kB. That's still smaller than that quad's v210 equivalent (which is something like 494 kB, but maybe v220 gets the same or better results at smaller file sizes.

Oh, I run v210 manually...no fancy shell.

Haven't got a real good chance to compare v210 with v220. What little I've seen shows v220 automatically fixing stuff that v210 ignores. There are a few cases where the revers is true, but those tend to be minor.

Sadly, my two attempts at creating a v220 'ultimate' mesh set ended in fatal errors.

-Decrepit-

Is it me, or are the cell transitions a lot smoother? Before, there was a noticeable pause every time as the game processed the new LODs, and stuff would pop in; now, it's nearly seamless, and things fade in properly. I love it.

Here's a http://img845.imageshack.us/img845/5266/elsweyr.jpg I took last night. I'm standing just outside the Corinthe city gates, looking north. I'll get a shot of Dune later and add it too.

Nice capture. Is yours a hi- or ultimate-res tes4ll mesh set? Yeah, it seems to me that eliminating most LOD / near-view landscape height mismatches makes transitioning from one to the other less jerky.

I notice my new self-generated v220 hi-res mesh set finally corrects the road-spanning land-walls along the upper Red Ring not far south of Weye. First time I've ever seen what that section of land properly looks like at distance.

-Decrepit-

Yes, this is a result of the placement of vertex points directly at the border of the cell. Because I have to split the triangles at the cell border later (remember... to avoid the voids) this seems to save somehow splitted triangles and therefore unneeded vertices. So more quality but less vertices.


What was the error message?

This might not be an exact quote, but I believe the message was "Too many vertices"

-Decrepit-

Try to enable

SetOption -useshapes

respectively add this line in the beginning of your batch script.

The ugly thing about the NIF format is that it can store more triangles as shapes as stripified triangles.

gruftikus: Here is another two thumbs up report. Love what your mod does for the distant LOD!

Using ultra settings and loving it :goodjob: My eyes have never been this happy :touched:

That's mid-res. I've got a 1 GB video card, but I didn't want to go overboard and bog my system, so I erred on the side of caution.

http://img406.imageshack.us/img406/8866/duneo.jpg. You can see the Two Moon Temple and Reaper's Anequina Manor in the foreground, and one of the tribal villages off to the right.

I have a GTX 260-216 with 896MB VRAM, and the Ultimate version runs without problems (but I have only 1024x1024 textures and the Vanilla normal maps with 512x512)

When you get a chance do try a hi-res set. My GPU has 1.2gb video ram, not much more than yours. My hi-res sets have never noticeably stressed it. It's been a long time ...some tes4ll versions...since I ran a mid-res set. Back then the difference between mid- and hi-res was readily apparent.

Here are comparative captures showing Kvatch at distance from the north. Both feature tes4ll v210 hi-res LandscapeLOD mesh packs. (I shot 'em on my secondary computer...which has not yet been upgraded to v220.) You'll note a few anomalies, but nothing overly serious. It's certainly a far cry better than what I saw prior to tes4ll. Back then Kvatch hill and surrounds were a real mess due to my particular load-order. Floaters and 'walls' everywhere.

The first capture shows the scene with http://i307.photobucket.com/albums/nn303/Decrepit_Waste/TES%20IV%20Oblivion%20Landscape%20LODs/Kvatch_tes4ll_1.jpg. I liked the coloring right well but didn't care for the tiling at distance. It dawned on me several days ago that I have a better texture-pack with which to create that quad's color-map. I spent most of this afternoon doing so. http://i307.photobucket.com/albums/nn303/Decrepit_Waste/TES%20IV%20Oblivion%20Landscape%20LODs/KvatchAmpolXLODcolor-map1.jpg To say I'm pleased is an understatement. Assuming I run in to no gotchas this one's a keeper. Next up....a color-map for the quad directly east. My fear is that it's the quad CSE always crashes on when attempting a color-map by my method. (I make 'em at 7712x7712 then reduce to 2048x2048 after edits.)

-Decrepit-

That second shot is indeed much better. I'll run it with High-res and see what happens.

Good stuff. I've been away from Oblivion for a while, losing contact a bit with what's cool and new. Ran into this almost by accident (saw it on Nexus), so immediately tried it out. I used the batch provided with the mod, with the Ultimate setting (my GPU is a Radeon HD 6950 2Gb) - and was amazed by the results. First thing I did was going to the roads behind Anvil walls, where there were some blatant errors in the vanilla LOD - now ALL were gone! Sure, there are a couple of floating rocks, but I don't think I'll bother fixing those: the improvement in going from normal distance to LOD is so huge, makes one wonder with Bethesda didn't bother offering a few options like this in the first place.

Thank you for this excellent addition!
PKR.

Are there any worldspace size limitations? The reason I ask is that I use Tes4Edit at the moment because nothing else will produce textures for a worldspace the size of my Mesogea mod, many times the size of Tamriel.

Also are you going to produce something similar for Skyrim?

The limit is at about the size of Onras heightmap. Without a 64bit version one cannot exceed this limit. The reason is that it is a 32-bit program an I have to keep the heightmap 5 times in the memory.


First one has to see if there is a problem with the Skyrim LODs (my Skyrim box did not yet arrived, so I can judge only on the basis of the screenshots), and we need to have the Creation Kit released. Hard to speculate about the need of an additional tool.

I've been wanting to try this out, but haven't finalized my load order yet (I've been waiting for a couple of releases to drop, but they haven't yet).

I do use Onra's heightmap, given the memory limitations, would generating ultimate LandscapeLOD be possible? Or should I count on using a lower res version?
Also, Is it possible to generate LandscapeLOD for custom worldspaces in a seperate run? I've been waiting for Silgrad Tower, but wonder at the ability to use this utility with Onra's heightmap + custom worldspaces. Thanks for your time.

Auryga managed to http://tesalliance.org/forums/index.php?/topic/4341-info-tes4ll-a-new-tool-for-landscape-lod-generation/page__view__findpost__p__71545 for Onra in the Ultimate version. But no promise, just try it.



Yes, you have to do 2 things:

1.) One has to tell Tesannwyn to process a different wordspace. This is done with the option

-w "WordspaceName"

both for tes4ll and Tesannwyn. If you want to can take a look at DibellasWatch_ultimate.bat as an example:

tes4ll -t -b ini\tes4ll\DibellasWatch.batch -f "wallremover,ultimate,nicer_mountains,overwritelods" -w "DibellasWatch" -l "DibellasWatch.esm"

If you use Tes4llshell instead, you can enter the wordspace name in the corresponding field.

And, 2.) you have to tell tes4ll to use different filename output, so not 60.xx.xx.32.nif, like for Tamriel. This is done by adding:

SetOption -worldspace=yy

to the tes4ll batch file, this creates the filenames to be yy.xx.xx.32.nif

E.g., for Dibellas Watch, I added:

SetOption -worldspace=4781446

This is what you have to add to tes4ll_all.batch, but of course with the number of your worldspace.

Did any of you try the pyffi process after generating the meshes with this software? If you have done it does that help with performance?

I pyffied mine after running this. It increased the size by 2 MB (from 8 MB to 10), but I'm unsure if performance improved. It certainly looks nicer, though. BTW - I did try out the high-res. Works great, no performance hit. Every time I get a good vista, I just stand there for a minute and admire the view and say "damn, that's amazing". :thumbsup: The mountains especially are a huge improvement.

See.. my problem is that whenever I stand on the Talos Bridge the fps is horrid. :swear: :blink: It drops to around 14-19 whenever I'm around that area. No matter what I do whether I use mid-range or high range or even pyffied, the fps is horrid. I'm trying to figure out what I'm doing wrong here. :facepalm: :banghead: :brokencomputer: