Yiffy Age of Skyrim

[Bad Dog]

Ya, I worried about that. For the scars I'm regenerating the nif. For the heads--if I do them, and I really don't want to be sucked into that--I can regenerate heads and tris. That part isn't  a huge amount of work. In fact, right now I have separate head meshes because I'm not sure I didn't fiddle the UV in each one. If I clean it up, I'll likely go with one head mesh and a races morph, so it would be just one head nif to generate.

 

I'm not sure why triangulating should break vert order--but of course that doesn't mean it doesn't.

[Silversammy]

Thanks can't wait for the update

[NightroModzz]

1 hour ago, Bad Dog said:

I'm not sure why triangulating should break vert order--but of course that doesn't mean it doesn't.

I'm just going by what I read on the Polycount forums, and a little from experience. Triangulating can be unpredictable. Such as if the shape changes from the original, a square can be split to a left parallel when it was originally a right parallel. Vert order may also have been changed just by quadrifying it, as it can sometimes create a quad from the wrong combination of triangles. So of course this leads to changes in the mesh.

 

I know you can compare and reassign vert order numbers Maya, Maybe there is something similar for Blender just so you can see if everything matches. Of course it's best to just copy and past the UVs (if it transfers), and not use the edited mesh.

 

I'm pretty sure I read past complaints of mophs morphing in a similar way in the video, so I guess just view for reference to avoid or fix similar mistakes via vert reorder in case you split and mirrored in the past, or anything that changed the mesh.

[Voldearag]

That's a beautiful news update, awesome work BD. ? Just realized by accident your initials make a sideways coolface.
Including animated ears on NPCs is as massive sounding an addition as ENB suddenly making Real Shelter irrelevant by adding even better rain occlusion. 

A surprise totally-great-on-it's-own thing.

[Blaze69]

6 hours ago, Voldearag said:

Including animated ears on NPCs is as massive sounding an addition as ENB suddenly making Real Shelter irrelevant by adding even better rain occlusion. 

A surprise totally-great-on-it's-own thing.

I mean, they are animated already. You just need to speak with some random NPC and you'll see it's easier to tell their intended expression than in the vanilla game thanks to their ear animation.

 

The only thing BD would be adding here would be ear movement to the LookRight/LookLeft morphs so that the ears also twitch towards the sides a bit when NPCs look at something that isn't right in front of them, but all of the other ear movement is there already. So I wouldn't call it that much of an addition, even if it is a neat little detail.

[Bad Dog]

Actually, not even that. The ear movement is there in the vanilla khajiit morphs already. All I was doing was putting them back into the edit earrings so they'd move with the ears.

 

There's a blender script that re-orders verts in a mesh to match another mesh based on the UV. So I could quaddify, fix the mesh, then use the script to correct the vert order. Then fix the UV. But I wasn't ever able to make it work right.

[Bad Dog]

This is me testing out a new scar mesh:

 

Spoiler

 

LOL my Skyrim's on drugs.

 

[NightroModzz]

Lol, purrty. Did you try removing some of them moon sugar mods?

[Kardien Lupus]

1 hour ago, Bad Dog said:

This is me testing out a new scar mesh:

 

  Hide contents

 

LOL my Skyrim's on drugs.

 

Guard! Guard! This Nordic Wolf using Skooma! Arrest this one quick!

[PaulGreen]

On 11/27/2018 at 6:11 PM, NightroModzz said:

 

 

   Modifying the polygon structure is generally unrelated to the vertex order. You can even delete the entire face structure, leaving just the vertices as points in space and one still hasn't altered the vertex order, though depending on program, deleting the faces deletes the UV and other associate data too. Blender is one,  since all data is tied through "loops" data structure now and not in the V data structure as it was in older blender.

 

   Doing  Tri -> quad  followed immediately by  Quad -> Tri  is highly likely to NOT reproduce the same face structure, that is true. Whether this is consequential or not depends on context. Many programs that import OBJ files as morphs will only care about V structure and the F structure is completely ignored, so alteration to the face structure does not matter. Some programs make an attempt to match V to V in a morph import by using UV position. This still won't matter even if the face structure is highly altered as long as the V index order is intact, since the V index list will still be the same and thus the UV coordinate it points to will also still exist and be the same coordinate point (though the UV list itself may be altered in arbitrary ways). Altering how the vertices are connected into faces doesn't alter the V or UV list itself, instead just alters how those points are connected to each other.

   If a program involves the facelist in the discovery of V position in import, then it indeed will matter.

 

   In another context, Outfit Studio and the new nifskope actually alter the V and UV index order on import to match a certain structure of the face list. So, altering the face list in any way will cause Outfit studio and nifskope to mess with the vertex index order when that mesh is later imported.

 

   Another possible context..  some programs may alter the V index order in memory when the mesh topology is altered. In those programs, altering the mesh topology will then, of course, break the V index ordering. I don't know which programs may do this, though blender is not one. One can alter the topology and the V index order remains intact in blender.

 

    Yet another context,  some programs will export an OBJ with the V order intact,  but not the UV order or structure.. blender and UVMapper are examples. Both of these programs may "compress texture coordinates" on export. If UV positions are determined to be identical, then a separate UV line is NOT exported for that point, and instead the V that shares that UV point just all point to the same index in the UV list. This can mess with programs that attempt to import morphs using the UV structure.

   This is of course a problem regardless... if UV structure is used to determine some structure of V's,  then having a UV map that overlaps islands or has the same position for a bunch of vertices (like, say, the whiskers on khajiit all share exactly the same uv square), then the UV is not possible to use to uniquely find a V.

 

   ANOTHER context..  the .nif plugin for blender will sometimes alter the index order under conditions I've not yet determined. Even if you just import a .nif then immediately export a .nif from that,  the V order will sometimes be different, but not always.

 

 

   Finally, another point about blender related to this.. The algorithms that are used to do the  Tri -> Quad, Quad - Tri,  subdivide process do not appear to be always easily predictable. I've found that if one saves the state in a .blend file,  then does a Tri -> quad, or subdivide or such then exports this file,  immediately loads the .blend file back and does the same operation and exports another copy,  the facelist ordering in the two exports has a chance of being very different. For subdivide,  since this adds vertices (and obviously then changes the V index),  this also means that the V index list will not be created the same way. So, one cannot have a chain of work where you do these operations separately on even the same mesh just reloaded and expect the resulting files to be identical.

   One has to be careful with this..  if you save a file before one of this style of operate,  do a bunch of work then decide that you want to make a slight alteration,  but didn't save a copy of the .blend AFTER this operation and have to reload before,   even if you do the EXACT series of actions,  the resulting toplogy can be completely different and so will not work with a bunch of stuff already created after this step.

   typing this up, I' realizing that it might not be the operation that's unpredictable, but that those operations rely somehow on the order of the data structures in memory, not just the contents of the structures..  so reloading the file may alter the order that the structures exist in memory and so the algorithm then does something different..

 

[Doodlecute]

Does this mod have the potential to alter only some races? I only want to replace the Nords, Bretons, and High elves.

[Blaze69]

3 hours ago, Doodlecute said:

Does this mod have the potential to alter only some races? I only want to replace the Nords, Bretons, and High elves.

It's been discussed several times already: yes, in theory it would be possible to only replace specific races, but we won't do it because it would take way too much time and effort, as the entire mod would basically need to be rebuilt from scratch.

[Doodlecute]

Hmm, that's too bad. I guess I worded things badly though; I meant to ask if such a thing already existed not if it could be made. Obviously from your comment it does not. Sorry if I poked a sore subject.

[Blaze69]

3 hours ago, Doodlecute said:

Hmm, that's too bad. I guess I worded things badly though; I meant to ask if such a thing already existed not if it could be made. Obviously from your comment it does not. Sorry if I poked a sore subject.

Not so much "poked a sore subject" as "just thinking about the amount of work needed to make such a thing makes my head hurt", lol. Plus, as I've said, it's been asked and answered several times already (though I'll admit it's been a while since the last time it was asked so the answer is buried deep in the thread by now).

 

Bottom line: certainly possible, but it would take too much work for it to be worth doing (for us, anyway). Plus, managing the different options on which races to replace and which to keep vanilla/human would be a nightmare. So I'm afraid it simply won't happen from our end.

[Bad Dog]

Part of the problem is that so many assets are shared between races. If some stayed human and others not all that would have to be untangled.

 

I'm actually dealing with a mini version of that now. We have Lykaios heads, citrus heads, short-ear citrus heads (some of the morphs had to change), and original khajiit heads (which I'm converting but earring morphs are made to work with them). So I have to either make all shared head parts work with all of them, or separate out rationally which parts will work with which variants. There's khajiit ear jewelry that consists of 3 rings and a pendant, for example. There's just not enough room to reasonably put all that in a small cheetah ear. Or KK's manes. They need morphs to fit closely around the face if they're going to be put on other races--but also too I don't want to put them on every race cuz that would just look silly.

 

And the head morphs for all those head types have to be similar enough so the earrings move with all the different ear types, or the earrings have to be specific to the head type.

[Skyrimhero11]

Hey Bad Dog! So there is a mod called Skyfem and it turns everyone npc into a woman/futanari. Is there any chance you could look into it and see if you can make a patch for it with yiffy age? Just asking, its not like i can force you. BTW nice mod.

[Blaze69]

7 hours ago, Skyrimhero11 said:

Hey Bad Dog! So there is a mod called Skyfem and it turns everyone npc into a woman/futanari. Is there any chance you could look into it and see if you can make a patch for it with yiffy age? Just asking, its not like i can force you. BTW nice mod.

See the answer above about making a modular version of YA that only replaces specific races. Making a SkyFem version of YA would require pretty much the same amount of work, so I'm afraid it's going to be a negative there as well.

[poblivion]

I found this, it is quite interesting for beast races

 

 

http://regidentsofskyrim.x.fc2.com/article0073.html

 

[gaotseun]

hi

would it be possible to run this mod with SE version?

[Blaze69]

10 minutes ago, gaotseun said:

hi

would it be possible to run this mod with SE version?

If you had bothered to go back a single page in the thread, you would have seen it's been discussed several times already in the last few days, with the latest comment about it being made by me:

On 11/26/2018 at 7:52 PM, Blaze69 said:

[...] the consensus is Bad Dog intends to look into a SE port not long after YA 5.0 is out (which in turn should happen before the end of the year as per his ETA). [...]

For fuck's sake, people, read the damn thread (or at least the last few pages) before you ask something to see if it's been replied already. Is it really so hard?

[gaotseun]

thanks for the answer

[NightroModzz]

7 hours ago, Blaze69 said:

If you had bothered to go back a single page in the thread, you would have seen it's been discussed several times already in the last few days, with the latest comment about it being made by me:

For fuck's sake, people, read the damn thread (or at least the last few pages) before you ask something to see if it's been replied already. Is it really so hard? 

If I may add

 

Or or, on Nexus, read 2 or three posts bellow you, or the damn sticky post! If only people weren't so lazy, they'd save themselves time too. Or better yet, press [Ctrl]+[F] and be amazed.

[Bad Dog]

I am so freaking burnt out right now. That thing I wrote upthread about hoping I wasn't going to get sucked into redoing all the heads? So I got sucked into redoing all the heads. And they're whupping my ass.

 

I have a nif which I can load into OS, export as an OBJ, load the EXACT SAME OBJ back into OS, and the verts are spazzed out all over the place.

 

I cannot figure out how the khajiit head textures work. The ruff and neck overlap, the whole thing is weirdly partially transparent, but somehow you end up with a fringed edge on the ruff but not on the neck. I've tried everything I can think of and can't duplicate the behavior. I even moved the edge of the neck UV up so the ruff could use the fringed edge and the neck wouldn't have to. Didn't work. 

 

Weights are okay, but the edge of the ruff is still moving with the head even tho I set all those weights to 0.

 

I was going to go with one nif file and a races tri, and that was working, but with my new nif it doesn't. Head doesn't show up at all. Don't know why. So I'm generating individual heads. 

 

I'm remaking the normals now. I'll have to remake the tint masks, but that's fast. I wish I could say that the result is clearly better but at this point I'm just not sure.

 

I was able to go through all the ear expression morphs and clean them up (and they needed it). I matched KK's "puzzled" expression (you can see it on Vilkas upthread) so jewelry would work for Nords and the rest of the races. Now I can finish jewelry tris, which was the motivation for doing all that work in the first place. 

[Blaze69]

4 hours ago, Bad Dog said:

I cannot figure out how the khajiit head textures work. The ruff and neck overlap, the whole thing is weirdly partially transparent, but somehow you end up with a fringed edge on the ruff but not on the neck. I've tried everything I can think of and can't duplicate the behavior. I even moved the edge of the neck UV up so the ruff could use the fringed edge and the neck wouldn't have to. Didn't work. 

I think they use special alpha properties to achieve that effect. If you check out the alpha channel in those textures, the fringed edge shape is in there. Couple that with some specific values for the NiAlphaProperty and/or the Alpha value in the vertex color data, and that may explain how the effect works.

[27X]

On 11/27/2018 at 11:23 AM, Bad Dog said:

Now I just have to restrain myself from redoing the UVs and the textures on every damn race in Skyrim.

No reason not to, the more the game looks like it should, the more people whom are engaged to continue supporting it. TES VI is four years away AT BEST.