Jump to content

[Skyrim SE] Porting a mod from LE to SSE


Arthmoor

Recommended Posts

The links Brumbek made are worth having a good look following them

 

Bethesda somehow have also made some of the landscape textures in the game more obviously repetitive.

 

The original Skyrim textures, being infinite edge to edge, were also repetitive, but they did a good job of offsetting a random pattern so that from a distance it was not so obvious ..

 

.. Now they have sharpened things up a bit for a few of them, and especially in the bump mapping, the distant repetitiveness is so much more obvious - Have a look at some of the ground textures between rocks from a distance in the Karthspire area and only using vanilla textures, some of them stand out like a bad wallpaper from the 60s.

Link to comment
Share on other sites

 

A friend posted this link to a ported version for me. Idk where he got it, but it works:

 

[Link Removed]

 

It uses an older version of SkyUI, though (probably the last one before the MCM Menu was added), so it lacks the latest UI's like alchemy, blacksmithing, enchanting, trade, etc.

 

However you can just do what I did for years before SkyUI finally covered those and use QD Inventory for those components. I've been using QD Inventory for eons (like, since it first came out, and it was one of the first Skyrim mods too) and it still works fine in SSE. Just let the SkyUI port overwrite some of QD Inventory's assets.

 

I go ti contact with the creator of skyui twoo weeks ago or so to ask that.  he said no.  He is done with skyrim.  H ehas neither the time nor heart for it.  he said it would no longer be fun for him.  I told him that if it is not fun any longer that I agree with him.  Our time on this earth is limited. 

Link to comment
Share on other sites

If you can document permission from him, yes, that would be fine.

 

I'm pretty sure he's also stated that they'll be ok with someone doing the work of getting the current version ported once SKSE is out too. The UI .swf files themselves seem to work just fine even without SKSE, but the rest crashed the game if you try and access the system menu. So I don't know the level of effort needed to make that work.

Link to comment
Share on other sites

Okay, it seem textures can now crash the game.

 

Please test, and if you got the know-how (Brumbek, if you're still reading this thread, you're probably one of the most knowledgeable one, and also potentially concerned), consider investigating this seriously, could benefit a lot of persons :

 

From Vivid Landscape - All In One download Vivid Landscapes - All in One - Loose Files 2048

 

Only extract & install install those two files from the archive (yes, big download just for two textures... sorry) :

textures\architecture\farmhouse\wovenfence01.dds

textures\architecture\farmhouse\wovenfence01_n.dds

Start SSE and go to riverwood (coc riverwood). Game should instantly crash. Remove the normal map -> Everything is fine. What gives ? oO

 

Well, apparently SSE doesn't like his normal map that is saved as 16bit-X1R5G5B5. Edit: he removed the alpha layer, but that's because he edited the mesh to remove the Specular property...uh...why?

 

Frankly, I also don't like that he uses the bizarre 16bit-X1R5G5B5 DDS format either. I don't know why modders feel they should use wacko formats instead of, ya know, the ones the original game uses: DXT1, DXT3, DXT5. I really hope he just picked this as a mistake...because why would he save it with this compression?

 

Anyway, another good reminder for SSE. Some DXT formats will crash the game. So I suppose we need yet another utility to scan textures and ensure they are DX1, DX3, or DX5...other formats might work, I'm pretty sure uncompressed will work (although that's almost always a waste of VRAM).

 

 

The normal and specular maps need to be saved in correct (dx10+) format, just like for FO4. You can use Intel Texture Works v1.0.4+ plugin for Photoshop. 

P.S. Many mods for FO4 (still) uses wrong texture format and this will cause CTD's sooner or later. There are tutorials how to properly convert textures for FO4+, just search for ''Intel Texture Works for Fallout 4''.

 

 

Yes I'm sure, but only when it comes to FO4, I'm not sure if anything changed in SSE. 

And yes, textures can still be used in older format, but the problem is with normal maps and specular maps.

 

...but for ''_n'' and ''_s'' it should be converted to dx10+ for FO4 and most likely for SSE too. But it's Bethesda and theirs ancient engine, you never know..

Um, NO. Please don't post stuff if you don't actually have proof or knowledge. Bethesda still saved each normal map with or without specular as DXT1 or DXT5. SSE does NOT include the more advanced rendering/shaders from FO4. So I'm going to say your information is entirely incorrect. Why post here when you don't actually know about SSE? Sorry...I just don't like misinformation. Proof and facts or NOPE.

 

 

The links Brumbek made are worth having a good look following them

 

Bethesda somehow have also made some of the landscape textures in the game more obviously repetitive.

 

.. Now they have sharpened things up a bit for a few of them, and especially in the bump mapping, the distant repetitiveness is so much more obvious - Have a look at some of the ground textures between rocks from a distance in the Karthspire area and only using vanilla textures, some of them stand out like a bad wallpaper from the 60s.

Aggressively sharpening a normal map...that's almost always a bad plan. I'd be curious to see high-quality screenshots comparing this. I said it before, but I'm strongly considering just copying over all the original textures minus the landscape that now uses Specular in SSE.

Link to comment
Share on other sites

 

If we get permisison from

schlangster to modify 2.2 and upload then it is fine , correct?

 

See this post for details on schlangster's requirements to allow porting : https://www.reddit.com/r/skyrimmods/comments/5a0l55/sse_megathread_4_no_really_read_it/d9culxi/

 

[snip]

 

Thanks for looking into it. (and for the batch of infos :P )

Link to comment
Share on other sites

So, just to clarify. It *is* possible for mod users to port mods to SSE if the creator is unable/unwilling/retired/abducted by aliens as long as it's only for personal use? Example: Wyrmstooth. The author is gone, and no he is not coming back. But if i want to play it in SSE do I have all I need to convert it? (understanding that this may be quite a bit of work)

Link to comment
Share on other sites

Yes, as long as it's for personal use and you don't distribute it, that's entirely fine.

Link to comment
Share on other sites

Quick question: I uploaded my first converted mod to nexus for SSE.  Does anyone have any writeups on how to upload it to the xbox place?

 

So far I gathered that the bsa tool has a checkbox that says "for xbox", so I guess I have to redo the bsa?  And then I saw something about getting images ready?

 

Any help appreciated. 

 

Nexus is going nuts right now.  Got like 56 downoads in just a few minutes.  Dying to comapare to the xbox side to see which group is hungrier.

Link to comment
Share on other sites

Arthmoor and others, I've been trying to determine how to package SMIM since making two entirely separate packages is REALLY annoying. So I figured I'd test the new SMIM SE .esp in the original game to see what happens. It seems to work fine. Even the cells with the new Water Flow edits don't seem to be an issue. For instance, AbandonedShackExterior that SMIM edits with the new SE Water Flow, it still seems to have the proper Marsh water with fog just like it should.

 

Am I crazy to think I could just use the Skyrim SE SMIM .esp with file header version 44 for BOTH the original and SE versions of the game? That would make it so the installer package could basically be identical for both versions. Please someone tell me why this idea is terrible.

Link to comment
Share on other sites

Yes, you are crazy to think that because the updated water flow references a form that doesn't exist in Classic Skyrim.

Link to comment
Share on other sites

It handles old meshes, but seems to be a bit more picky about them being well-formed.  Also certain texture formats are no longer supported like uncompressed grayscale, which the game reads as if it were RGB with only the red filled out.

 

With that said every single NIF file has been run through their internal converter program to have a better vertex data layout, which enables the engine to more optimally read all the data into DX11. Not to mention it's significantly compressed, where a typical vertex (position, UVs, normals, tangents, bitangents, and vertex colors) goes from 60 bytes to 32 bytes.**

 

The vertex format is the exact same as FO4's except SSE meshes are never half-precision (using 16-bit half floats for all of the vertices). Most all blocks are completely identical,  but no existing tools will even be able to open the NIFs without an update even if they can read FO4 NIFs, since SSE NIFs are a bit of a mixture.  The NIF file versions go 83 -> 100 -> 130 for Skyrim -> SSE -> FO4, showing that SSE came between the two developmentally (which we already knew).

 

 

** Which, if they're doing it correctly, the engine is having to take a bit of extra time to load the old 60 byte vertex, but it's getting converted to the new format before being sent to DX11.  So if there is any kind of overhead with old meshes it should only affect loading time.

Jon, I have a question. Is the vertex count for NIF file changed after conversion by Nifscope. OBJs converted to NIF in 3dsmax plugin experience that kind of change. If so, it means that every .tri file I made needs to be redone completely.

Link to comment
Share on other sites

Just noticed something about the water flow - The distant LOD anim of water flow does not match the direction in the middle to near distance

 

tcl and fly up high above a river ( I did it above the river which Sky Haven Temple looks down upon )

 

Now slowly come down and forwards as if you are a plane coming in to land on the river

 

You will notice the far distance water flow is doing the Skyrim Original thing and flowing under the banks of the river sideways

 

As you get closer it morphs into the correct flow direction for that area as the LOD hands over to near distance.

 

( This is vanilla Skyrim SE behaviour .. No mods installed )

Link to comment
Share on other sites

LOD for a water flow? You are asking for waaaaaaaay too much. We don't even have a simple static LOD for half of objects in the game that should have it :imp:

Link to comment
Share on other sites

Crazy idea: We put the water level down under any ground, then we add water plane everywhere, and mark those as full LOD / neverfade (or whatever the setting for cloud sheet in mountains is, I never remember). 

Link to comment
Share on other sites

LOD for a water flow? You are asking for waaaaaaaay too much. We don't even have a simple static LOD for half of objects in the game that should have it :imp:

 

Too true, this is probably DynDOLOD SE territory .. maybe one day

Link to comment
Share on other sites

Yes I'm sure, but only when it comes to FO4, I'm not sure if anything changed in SSE. 

And yes, textures can still be used in older format, but the problem is with normal maps and specular maps.

 

I even tested it in FO4, I loaded the game with most normal and specular maps in the old format (compatible with Skyrim 2011 and older) and the game was sometimes crashing on fast travel and sometimes even during gameplay, but after I converted them to dx10+ crashes stopped. So for ''_d'' format should not matter that much, but for ''_n'' and ''_s'' it should be converted to dx10+ for FO4 and most likely for SSE too. But it's Bethesda and theirs ancient engine, you never know..

As I wrote I think I noticed this happen only on terrain replacing mods . PErhaps it uses a different shader.

Link to comment
Share on other sites

So, possible odd question about the new nif format (jon! help!) and Bitangents.

 

Bitangents used to display in vector3 X,Y,Z coordinates like normals and tangents, now they're split apart into Bitangent X being a float and Y and Z being bytes. Can someone please explain the bytes (in this example pic, the value 127) and how (or if) it relates to the previous vector co-ordinates?

 

post-1482-0-90151100-1477851660_thumb.jpg

Link to comment
Share on other sites

As long as this isn't a skinned SSE mesh (I haven't updated it for that yet) the Update Tangent Spaces will fix any tangent/bitangent issues from the verts/normals/uvs.  I will eventually be porting over the face/smooth normals and such for the new format. 

 

The values there are turned into a float like so:

bitY = (double(bitYi) / 255.0) * 2.0 - 1.0;
bitZ = (double(bitZi) / 255.0) * 2.0 - 1.0;

This means that 127 is (127 / 255) * 2 - 1 = ~0.0

 

Basically:

 

0 = -1.0 in float

127 = 0.0 in float

255 = 1.0 in float

 

since normalized NBT vectors range from -1.0 to 1.0.

 

Since the data is split like that, I don't know how to really let anyone edit it like the other vectors. 

Link to comment
Share on other sites

LODGen.exe now fully supports generating static LOD SSE with correct support for the new large reference grid (more info). Updates to SSELODGen are committed, so you soon should be able to generate static and tree (no changes) LOD with SSEEdit. Typically it creates its own texture atlas, but if there is the need to support the existing atlas of SSE such a feature could be provided, let me know.

 

uLargeRefLODGridSize from the ini is confusingly named, because large full models are placed into this grid beyond the usual 5x5 uGrids. Static LOD for these references now needs to unload earlier than for small reference that show in the uGrids only.

 

The distinction of when a reference is large is based on the OBND data (obejct bounds). This means if a mod changes this data for any suitable base record (STAT, MSTT) LOD needs to be generated again. Otherwise it can happen that full model and its LOD are displayed at the same time causing texture flicker.

 

The whole system seems a bit brittle and coarse at the moment  - either because it lacks better control through flags or I just haven't figured it out yet (no CK) The general idea of it is nice. It just could use some tweaking I think.

Link to comment
Share on other sites

Probably also worth mentioning that there seems to be a bug with the LargeRefLODGrid, that as soon as there exists an (even identical) overwrite for a large reference, the reference will not load in the large grid anymore and the largeref LOD supermesh(es) for the quad/cell may not unload properly causing texture flicker for other nearby large reference.

Link to comment
Share on other sites

As long as this isn't a skinned SSE mesh (I haven't updated it for that yet) the Update Tangent Spaces will fix any tangent/bitangent issues from the verts/normals/uvs.  I will eventually be porting over the face/smooth normals and such for the new format. 

It actually was a skinned mesh (book), but that's fine. Thanks for the info! Wow.

Link to comment
Share on other sites

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...