stoppingby4now

I really like that third one as well, feels more solid.

I make use of layers quite extensively as well. Gives much more flexibility (as you know), and I commend you for the use of them.

I would agree with explaining both approaches. Makes for a well rounded document and empowers users with the knowledge to choose which is right for them regardless of recommendation.

For a lot of users, I think the standalone version is much more installer friendly, easier to maintain, and should be the recommended solution. However, we're currently in a situation with respect to lack of updates that having the SVN is more beneficial which requires the python version. Ideally, SVN use would be left to the adventurous and developers/testers.

@torminater That's interesting, because I'm experiencing something completely different (RCRN classic no FXAA). I'm not seeing z-fighting any more pronounced with it, but there is a point where it clears up much faster and practically goes away for me. I'm now only experiencing it on very very far distant objects (it's also more pronounced in 3rd person than it is in 1st person view). A case in point is if heading West from Whiterun and looking at the mountains in the distance. I would always get z-fighting, lessening as I got closer, well beyond the western watch tower. Now, it's virtually gone before I even reach the western watch tower. I haven't gone up to the throat of the world to test yet.

Did a comparison between Vanilla and the DDSopt versions running around and watch to see what happened. With the Vanilla textures, trees maintain their shape and details pop in as you get closer to them. With the DDSopt version, most of the trees in the near distance are missing information, and as you get closer, the extra information pops in. However, trees that are even further in the distance seem to still maintain their original shape.

So is that missing mip accounting for the distant, but near trees as well? What's strange is that I'm seeing a very few select trees that look normal, but far too many regardless of distance (except those you are up against) have missing information. I don't know how to do any real comparison, but I believe you that what DDSopt has processed has good detail. Just have to figure out how to get the missing information back.

In DDSopt, both versions are the same resolution and same format, just that my DDSopt version has one less mipmap. So either information loss can occur regardless of format and resolution staying the same, or that one missing mipmap is causing the problems. I just don't know which one is missing, and if that is the cause.

If that is the right texture, I'd be willing to filter it out and re-run DDSopt to see what the difference is.

textures\landscape\trees\treepineforestbranchcomp_n.dds

Fri mentioned updating the BB logo, but I believe he was referring to the logo created by Elven when referring to the layers.

I haven't looked at the horizontal one. Fri may be referring to the vertical one which has 22 layers (2 hidden).

Should be fixed now.

Thanks for the heads up, will look into it.

Believe I'm looking at the right ones. The DDSopt version has one less mip level (11) from the HRDLC (12). Resolutions are the same. Only other difference I see is that in the HRDLC version, the left most portion of the view has a gray tint over it, whereas the DDSopt version doesn't. I don't know what that means though.

Then what explains the loss of information on the trees?

There is information (definition) loss, but I would still argue that it equates to detail loss. You can't detail an object nearly as well with less of it there to work with. If information is being lost via DDSopt, logic dictates that some level of detail is going to go with it. I'm no expert on texture compression, and I doubt I ever will be, but basing on the constraint settings where they are all lossy, doesn't that mean that some detail is going to be sacrificed?

I think it safe to say that you have more experience than most of us though.

Woot. I really like it with the text centered. Good work!

I only use M4, and I only have the occasional issue in regards to using doors. Entering Dragonsreach seems to always trigger it for some reason.

That is something we'll just disagree on. I'm talking about distance trees. You may just like the look of the DDSopt version, but to be honest, it's not realistic. You don't lose that much definition and detail when looking at trees in that distance range in real life, and there is a lot of loss in both in the DDSopt version. I'm going to have to clear out my mods and put back the DDSopt I did to compare. Again, I can't help but wonder if the images were labeled wrong and we are comparing the opposite image.

I hate that too. Putting it in code tags would work, but then you wouldn't be able to format text. Hopefully a new editor solution can provide a means of keeping spacing.

@ElvenArcher Actually I meant having the text still below each letter, but centered... .......^ .......S ...Skyrim .......T ....Total .......E Enhancement .......P ....Project (dots used to help show positioning) I'm curious about that look, because if it looked good, it could provide a consistent vertical image that would fit whether left or right justified. Just need to see an example to know for sure.

The tree in the immediate foreground has the same general fullness between the two. I'm mainly referring to the trees in the background. If those images are correct, I just don't agree that the DDSopt versions look better. Particularly when looking at some of the trees on the right hand side, there is very noticeable loss of detail. Which is why I was wondering if the images might have been labeled wrong (have you verified that you didn't make any ini changes that might affect the scene?). If not, I can't agree with DDSOpt version in this instance.

Yes' date=' that would also possibly work well. That along with a darker skin would be very nice[/quote']Aye, we need a new darker default skin for the wiki. I've been playing too much, going to finish up the highslide extension then start by implementing the top bar on the Wiki.