Bad Dog's Hoodie Schlongs: Khajiit, Argonians, Human/Elf

[PaulGreen]

   I haven't figured this out so well myself yet. I suspect from reading around that there are better tools to do this than Blender's built-in weight copy tool. This is also why you'll notice that models that attach to body parts attempt to share vertex points. Look at the original SoS models to see.. at the attachment point to body, the vertices share exact weighting data since the vertices are at precisely the same location. When the 'attachment points' are not shared vertex positions, you start having to interpolate or totally guess weight values.

   Press "n" while in edit mode to see a property slide-out of a vertex, which will give you exact weighting values. You can copy that between the meshes.

 

   If you import two .nif files to do weight copies, import your target .nif LAST. The way the blender nif tools work, they save some 'hidden' data about the way the bones are oriented. Importing another .nif after your intended exported one means that hidden data gets overwritten... I think. Just seems this way from trial and error, heh..

 

   Remember that blender will not give you an accurate picture of the weighting results unless you parent the bones together. Rotating Gen1 should also rotate Gen2-6 as well.

 

   You don't have to paint both the _1 and the _0. When you import an OBJ into a .nif file within nifskope, the tri-shape data is modified to the new mesh data, but since the skin and partition information is not touched, the weighting and other info is kept intact. In other words, As long as the meshes share vertex order exactly, the weight information still works. just paint one of the _0 or _1, export it as .nif,  open in nifskope,  import the .obj of the other shape over the trishapedata, then save that as the opposite _1 or _0.

 

   Also keep in mind, the way weighting works, the weights are always normalized. If you paint 0.5 weight on a vertex and no other weight value, the game and blender will treat that as "1.0"  That's why you can see effects like a 0.001 weight seeming to shoot a vertex a long distance and such.

[boo]

I've found that manually setting weights on each vertex is the most reliable option.

[Bad Dog]

On each vertex, huh? Ow. I did figure out that matching the edge of my mesh to the hole in the body exactly was the way to go.

 

What I'm most puzzled over now is exactly how Skyrim does the interpolation between the _0 and _1 meshes. My failed attempt looks fine at weight 0 and fine at weight 1 and blocky/crappy/spazzed at weights in between. Somehow Skyrim has to find an intermediate location for every vertex in the mesh, right? Which means there has to be a one-to-one correspondence between vertices. How does that happen? Is there some magic ordered list of vertices in a mesh? How might that list get scrambled? Like, for instance, if I nuke half the mesh, add the mirror modifier, push the _0 mesh around, and apply the mirror, have I just broken the correspondence between the _0 and _1 meshes? I'm sorta thinking I probably have. 

[zref]

Wow thanks for all the hard work.  I cracked up out loud when I came across "consultation with physiology experts" as a list to possible ways of trying to get realistic flesh movement when I was looking up just what vertex weight is.  I knew it was complicated but ouch!

[PaulGreen]

 

 

 

   Wow, coffee fueled wall of text, lol   >.>

   All stuff below is my current understanding. If it's wrong, oops..

 

  Yes, there are quite a number of contexts in which the vertex ordering is important. There are a few points I can think of:

 

Point about _0 and _1:

 

 

   As far as I can tell, the _0 and _1 .nifs, the _0 .nif file is the most used. For weights 0.0 <-> 0.99, the skin and weighting data, UV, face list, textures sets, shader, and other extra info is used from _0. When the weight hits 1.0, the game switches to the _1 completely. So, if you had different textures in the _1 and _0 file, The _0 texture would be used from 0.0 through 0.99, then suddenly switch to the _1 texture at 1.0.

   Incidentally, If you have incompatible settings between the _0 and _1 it can crash the game.

   For the 0.1 through 0.99 weights, the only data combined is the vertex positions listed inside the _0 and _1. The vertices are morphed from their position in the _0 to the position in the _1. The way this works is that vertex at index number #0 moves from the X,Y,Z at index #0 in the _0 file to the X,Y,Z at index #0 in the _1.

 

 

Point about nifskope and OBJ v,vt,vn ordering in face list. OBJ format info: [ https://en.wikipedia.org/wiki/Wavefront_.obj_file ]

 

 

Nifskope (1.1.3 at least) seems to have a technical limitation when importing/exporting OBJ files. If you open an OBJ in a text editor, the face list lines begin with ab "f". Those integers are the vertex indices into the vertex array. Each vertex (v) on a face is also given a texture coordinate (vt), and possibly a normal (vn). These are specified in the form  Vertex/Texture/Normal, so something like 67/89/23. That is the 67th vertex index is given the 89th texture in the texture list, and is given the 23rd normal in the normal list. If one of those doesn't exist it is skipped.. for an OBJ with no texture coordinates, you see 67//23.

   The Nifskope limitation is that it accepts these lists only when the three arrays are in the same ordering, and when each piece of data (vertex, normal, texture) is given to exactly "one" vertex. So, in other words, the 67th vertex in the vertex array will always be given the 67th normal and the 67th texture. So the face line will look like  67/67/67 . If they are not in this type of order, Nifskope seem to have trouble importing.. so watch out

   The problem is that blender and other programs don't export in these entirely ordered styles and it can lead to problems I've found.

 

 

Blender and OBJs:

 

 

 

   When you import or export OBJs in blender, there are options to "preserve vertex ordering". It seems like blender usually does this anyway, but these options ensure that it pays particular care to the ordering when reading/writing the format. It won't break the ordering in fulfilling other options.

   Doing things in blender that delete or create vertices will, of course, break the ordering. Even if you perform the exact action on two meshes, it isn't entirely guaranteed that the ordering will come out the same. This is certainly true if the mesh topography is not the same.. the different shape of a _0 and a _1 intended mesh will probably mean the mirroring, sub-dividing, and such will turn out different.

 

 

 

UV map region edges create duplicate vertices for game engines. Be careful of "unwrapping" UV again, it may change the vertices:

 

 

 

All faces of a mesh share vertices. Two adjacent faces share an edge, and that edge is made up of two vertices. So, when the faces of a mesh are being declared, most vertices are referred to at least twice, once when specifying the face vertices on one face, then again when specifying the vertices for the adjacent face.

   If you look at a UV Map, you see that there are regions of the UV. For instance, a cylindrical object is "unwrapped" to be something like a flat rectangle. At the top and bottom of the rectangle is the "seam". That's the point where the unwrapped, 2D UV map actually meets its other edge (top and bottom of the UV region) on the actual 3D model. At these seams, two triangle faces adjacent to each other on the model are *not* next to each other in the UV. Or said again, the top of the 2D UV map region meets the bottom of the UV region at the same location on the 3D on the model, but are different points in the UV map

   The 'problem' is that, this means that a single vertex along that seam has two different texture coordinates. When the vertex is being specified as part of the face at the top of that UV region, it has one UV (say [0.5, 0.7] ) and when that same vertex is being specified as part of the face at the bottom of the UV region, it has a different UV coordinate ( [0.0, 0.7] ). The single vertex in the 3D space belongs to both the top and bottom of the UV map region in the 2D UV Map space, once for the face at the top and bottom.

   As mentioned above, though, in the engines, every vertex can have exactly one set of data. A single vertex cannot be given two different UV coordinates. The way this is dealt with is that the vertices are just duplicated along that UV seam. One vertex belongs to the face on one side of the UV region, the other vertex belongs to the face on the other side of the UV region.

   As a consequence, re-unwrapping the UV on a model will probably require a vertex re-ordering since the previous duplicate vertices may (should be) welded, and the new UV seam should have new duplicate vertices created.

 

 

 

Bodyslide note, if you use bodyslide and import/export models for slider data:

 

 

 

I've found that, if you're using bodyslide to create morphs and things, Bodyslide itself has bugs relating to vertex ordering. I haven't really figured this out yet..

   Basically, importing or exporting models for slider data can fail, sometimes with errors sometimes with a result looking like there was a bad vertex ordering, even when the model is precisely correct. In a few cases, I got it working by just adding a bunch of newline characters at the start of an OBJ file..  dunno.

 

 

 

I paid for a program a long time ago that can save a few situations of similar-topology models that had their vertex ordering broken.. called "UVMapper". One of the tools menu has a "reorder vertices" tool. You import a model, select that option, then select the target model to match its ordering, and it attempts to re-order the vertices to match.. I dunno how it does it at all, but it works sometimes.

 

I actually wrote a python script awhile ago for another purpose that ended up being useful in fixing up vt and vn ordering om OBJ files.. it isn't magic, just that if the mesh is genreally correct  (num vertex = num texture coordinates  normals don't matter), but the list data was not ordered precisely, it would re-order the OBJ arrays to put them in the same orders (make face lines that look like  63/63/63). It's kinda badly designed, but it works, heh.. if you want, let me know.

 

I have a Blender file of some work I did on the khajiit schlong model. Trying to animate it, I think it's getting there, but having but stuck on a few points for a bit.

 

 

 

 

[Bad Dog]

Huh. I figured the _0 & _1 vertices had to work something like that. What a hack.

 

I'm avoiding importing/exporting objs. I'm going through blender 2.4 and using the export to fallout 3 hack. Tedious, but it works and I'm familiar with it.

 

I've now got _0 and _1 meshes that work, don't float away from the body wall, and morph into each other properly with the weight slider. Next step is to clean up the textures and normals, which probably means re-unwrapping, which per your above probably means re-creating the _1 mesh. But it's less tedious now--It doesn't have to be reweighted, it just has to be fit to the _1 body. Maybe I'll get the _0 to the point I'm happy and then create the _1 once. That would be sane.

 

That thing about Skyrim switching over to the _1 body at weight 1 had me in fits for a while early on. I couldn't figure out why my stuff was only working at full weight...

[PaulGreen]

 

 

Don't know if you care to switch process, though a person updated the blender plugin to work with the newer blender versions. [ http://niftools.sourceforge.net/forum/viewtopic.php?f=13&t=6323 ]

 

   As far as I can tell, this new version actually works much better for .nif import and export than the old one with 2.49b. The wiki and project pages for the Niftools website are all very outdated.. basically all the new information and project updates are only in the forums.

 

   The only caveats is that it defaults export for oblivion, and the shader type isn't exported. When exporting, change target from "Oblivion" to "Skyrim" and the "Max Partition Bones" from 18 to 24. After export, the Shader Type is always "Default". Have to switch it to "Skin Tint" or whichever in Nifskope.

 

 

 

[shadowking622]

 

 

 

Don't know if you care to switch process, though a person updated the blender plugin to work with the newer blender versions. [ http://niftools.sourceforge.net/forum/viewtopic.php?f=13&t=6323 ]

 

   As far as I can tell, this new version actually works much better for .nif import and export than the old one with 2.49b. The wiki and project pages for the Niftools website are all very outdated.. basically all the new information and project updates are only in the forums.

 

   The only caveats is that it defaults export for oblivion, and the shader type isn't exported. When exporting, change target from "Oblivion" to "Skyrim" and the "Max Partition Bones" from 18 to 24. After export, the Shader Type is always "Default". Have to switch it to "Skin Tint" or whichever in Nifskope.

 

 

So I can finally import nif files with out having  to go through that lengthy process?

 

[PaulGreen]

 

 

 

   It works for me. Using the latest 2.76b, I do nothing special at all for import, export requires those two points above.

 

   I should add another caveat is importing multiple .nifs into the same project workspace:

 

by PaulGreen:

 

   If you import two .nif files to do weight copies, import your target .nif LAST. The way the blender nif tools work, they save some 'hidden' data about the way the bones are oriented. Importing another .nif after your intended exported one means that hidden data gets overwritten... I think. Just seems this way from trial and error, heh..

 

 

   So basically, bone transformations will be correct on export for whichever nif was the most recent imported one. At least, this is what I have observed.

[Nepro]

Is Drachis Argonians hardcore requirement? Can I do it without it?

[Bad Dog]

Yeah, the argonian schlong texture runs up into the body. I'll fix soonish. Playing with khajiit now. Got the mesh sorted pretty well, got model space normals to work (yay!), figured out a bunch about baking normal maps in blender. I've been painting bump maps in photoshop and then getting blender to bake it into a model space normal. Figuring out how to get the normals from blender to skyrim was fun--I had the light falling on the wrong side of the schlong for a while.

 

Now I'm making the balls fuzzy. I'm still tweaking it, but it doesn't look bad so far. I could give him a little fuzz for pubes too and I might if I don't like the seam. More as it happens.

[PaulGreen]

Sort of.. The method might be a terrible abomination, though.. basically all done in papyrus. I think the model is a little too high-def, so this might all end up being a big hit to performance..

 

 

Does anyone know how to dynamically add/remove a bone node from the skeleton in game? Is it possible?

 

 

Just an .mp4 in a zip file, not any game files:

 

BDKGenTest.7z

[TangoFoxtrotTastyWhiskey]

It's kind of a shame Drachis is required...I imagine trying texture fuckery to make it FAR-compatible will result in failure on my part, however, so there's that.

 

(Yes, I know FAR is supposed to be horrible and awful and oh gosh the seams, but I prefer its style to Drachis', it tries to take Argonians back to what they used to be and I'm just a nostalgiafag like that.)

[boo]

That already looks pretty great.

[Bad Dog]

Patience, my children. I'll get back to the argonians after the khajiit are sorted. I wondered if I'd hear from any FAR users. 

[Bad Dog]

If anybody has any insight into model space normals, I'd love to hear it. I can generate them in blender but they're wrong. What I'm doing is -- generate in blender; load into photoshop and invert colors; switch green and blue channels; flip horizontal. 

 

I've heard blender runs normals in the opposite direction to everyone else so maybe that's why I have to invert. I've read that Skyrim wants blue and green flipped. But I have no idea why the result has to be flipped horizontally--just that if I do it, I get the right result.

 

Any ideas why? And is there a simpler way? (Yeah, xNormal. I've never gotten that program to make sense.)

[PaulGreen]

NOTE:

I think the below is incorrect. New info here:

 

http://www.loverslab.com/topic/56901-normalmap-online/?p=1461401

 

 

---

 

Your favorite annoying guy is here! The real answer would come from someone who knows something of the internals of the game engine..

 

I think inverting the colors is as you think.. the normals are facing the wrong direction. In my limited experience, Blender does have the normals facing "out" as they should be. In edit mode, hit "n" for property panel, go down to "mesh data" and turn on vertex or face normals. They should be pointing outward from the surface of the mesh. If they're pointing inward, just flip the normals. Inverting colors is the same as flipping the normal (RGB = XYZ, so -R-B-G = -X-Y-Z). As a note,  0 = 128 in the RGB, so -1.0X = 0Red  and +1.0X = 255Red

 

As far as I know, the game engine has Y "up" instead of Z. In blender, +Z goes "up" in the sense of ground to sky, but in the game Z is into and out of the screen, and Y is "up" in the sense of ground to sky.

   Incidental, this creates another weird thing.. If you think of the coordinate system in blender,  and think of the way the character stands in the program, a character is "standing on" the X-Y plane with their front facing +Y, their right side in the +X half and their body in the +Z half. When you swap Green and Blue, you're swapping the Y and Z coordinates. So, basically, think of the person then laying flat down on their face in blender's axis orientation.  +Y is now "up" for that character, in the sense that their feet to head would be pointing up to the sky.  However,  now -Z is their "front" and +Z is their "back" but that isn't the case in the game engine.

   If you split the color channels on a working model-space normal map, you'll notice that the Blue channel  (Z-axis)  has their front in the lighter color (channel is 129 - 255), which is +Z, and has their back in the darker color (channel is 0 - 127) which is -Z.

   This means that, in addition to swapping the Y and Z axis in the game engine, the X axis is also flipped..  +X in blender is -X in the game.

    To think of this, imagine that person laying face down on the X-Y plane in blender, so they are facing in the -Z direction. Then if they turn over to lay on their back, now they are facing +Z. That act of flipping over on their back while laying on the X-Y plane is the equivalent of a 180-degree rotation about the X axis, so an inverse of the X axis.

 

   I think this might be at the crux of the need to flip horizontally,  except  that flipping the map horizontally is not actually correct..  I assume that your texture map (UV map) is symmetrical, right to left. When you flip it horizontally,  the Red channel (X axis) flipping actually has the effect of inverting the channel value, and the Green and Blue channel (Y and Z) basically look exactly the same. This is the act of inverting the X-axis as described above.

   However, if the map was not %100 symmetrical right to left, any non-symetrical component of map would also be flipped (not color inverted, positionally flipped) which would then be incorrect. Like, if on the characters back, you had a gouged scar on the right side, after flipping horizontally, the scar would now be on the left side. If the diffuse map had a painted texture to match the normal map, they'd be on different sides of the body now..

   The actual correct thing, I think, is to just invert the Red color channel only.  Not flip the image, but just invert the Red color channel.

 

 

   I  had to think all this though when doing the animation thing  >.> I still don't understand all the little coordinate and rotation anomalies, though. Kinda annoying, lol.

 

 

   Where you also asking what model space normal maps were?  (vs tangent space, I guess)

 

[boo]

If anybody has any insight into model space normals, I'd love to hear it. I can generate them in blender but they're wrong. What I'm doing is -- generate in blender; load into photoshop and invert colors; switch green and blue channels; flip horizontal. 

 

I've heard blender runs normals in the opposite direction to everyone else so maybe that's why I have to invert. I've read that Skyrim wants blue and green flipped. But I have no idea why the result has to be flipped horizontally--just that if I do it, I get the right result.

 

Any ideas why? And is there a simpler way? (Yeah, xNormal. I've never gotten that program to make sense.)

 

IIRC, I was able to get correct normal in blender by mirroring the object along one or both axis.

[TangoFoxtrotTastyWhiskey]

Patience, my children. I'll get back to the argonians after the khajiit are sorted. I wondered if I'd hear from any FAR users. 

 

You can't believe what a relief this is. Veezara seems to be getting lonely.

[thyne]

File Name: Bad Dog's Hoodies: Khajiit, Argonians, Humanish

File Submitter: Bad Dog

File Submitted: 30 Sep 2015

File Category: Models & Textures

 

 

Merry Christmas, peeps and pervs!

 

Just in time to bring you Christmas joy, I offer Bad Dog's Hoodies. I've taken my khajiit peen and used the same mechanism to support argonians and people-type races as well.

 

The main file adds a "hoodie" schlong that works on any race and changes appearance as it gets more erect:

• On people, it's an uncut. As it gets more erect, the foreskin pulls back. Fully erect, it is the "Smurf Average" schlong that ships with SOS. It's fully SOS-animated throughout.
• On khajiit it's sheathed; it extends from the sheath as the character gets more aroused. The balls are fully animated throughout; the shaft is animated once it's erect.
• On argonians it retracts completely. As the character gets more aroused the shaft extends. The argonians carry their balls inside, being cold-blooded, so their balls don't show at all. The fully erect schlong is fully animated.

Probabilities are set so that nords, bosmer, orcs, and bretons are highly likely to be uncut. Redguards, imperials, and altmer are highly likely to be cut. Everyone else is in between.

 

Note that this is not a full animation. Doing real animation of sheathing peens is Very Hard--KrittaKitty and PorscheDog have been working on that for months for the Lykaios race. All I do is swap out meshes at strategic moments.

 

Orcs can use this schlong, but the secondary file is a schlong specific to orcs. It's an adaptation of the troll penis for those who want a more beastly look on their orcs. This is a plain vanilla SOS schlong, no scripts, so it's low impact.

 

Quirks and oddities

• I've set the probability of khajiit, orcs, and argonians using my schlongs to 100%--but unless you set the probability of all the other schlongs to 0% for those races, you'll still see them showing up sometimes. So if you care, do that.
• The human schlongs don't quite match up with the body. Dunno why, maybe bone weights? But I haven't been able to fix it yet. In my, um, testing, I never noticed it so I don't think it's too bad. I'll upload a fix if I figure it out.
• For reasons I don't understand, this mod messes with the page up/down keys in the console. I don't touch them directly so this shouldn't happen. But it does. Sux.
• I'll probably be fiddling with the textures and models on the uncut human. It's just too something, or not enough something. Needs more texture.
• Be warned--I'm doing squirrelly stuff with swapping models and catching animation events. I've, um, tested it fairly thoroughly and I think it's stable, but it's not really a low-impact mod.

There are also some male and female khajiit body textures here to lend piquancy to nude play.

 

 

Installation

 

You can load and go, but because of the way SOS picks schlongs, not all orc and beast races will get the new equipment. If you care about that, use the MCM menu to go through all the OTHER schlongs and set their probability to 0% for orcs, khajiit, and argonians.

 

Bad_Dog_Hoodie_Schlongs has the uncut/sheathing schlong for all races.

 

Bad_Dog_Orc_Schlong is just the orc schlong--no sheathing on this one.

 

Prerequisites

• SKSE Register Custom Animation Events
• Drachis Argonians for the cool look
• Sexlab, duh
• SOS, duh. The Smurf Average addon is REQUIRED--make sure you don't disable it. It's available by default.
• I have them loaded in that order.

 

 

Recommended

• Sexlab Aroused Redux V21 - Use this version and turn on SOS integration to have your handsome beasts show the ladies he cares.
• Revealing Armors for SoS - Not much fun if you can't see the action.
• Floppy SOS - Better animation. I use the balls only because I get funny twitching of the cock, but ymmv.

 

 

Credits:

• Whoever made the troll penis. I've been wanting to put that thing on an orc since I first saw it.
• Ditto Smurf Average. I didn't try to improve on it, just pulled a skin over the knob.

 

 

 

 

Click here to download this file

every time they get aroused my game crashes what would cause this

[Bad Dog]

Your favorite annoying guy is here! The real answer would come from someone who knows something of the internals of the game engine..

 

OK, mr. annoying guy, you get some kind of prize. Inverting just the red channel does do the left/right flip thing in a way that doesn't depend on symmetry. And your explanation of all of this is useful, including the explanation of why the models all appear in blender in a non-useful orientation.

 

The normals thing tho is a little different than what you explain--the normals as shown in blender are all correct, the thing I read is that a tangent space normal map has the direction of the normal inverted, so a skyrim normal map loaded into blender has to have the strength set to -1 to flip the value. But that's by the way.

 

I got xNormal to kinda sorta play nice--I'm creating tangent normals from bump maps, model space normals from that, swizzling in photoshop and getting something useful. Gack.

[Bad Dog]

Here's where I'm going with this: 

 

 

 

 

 

 

Comments are welcome but I don't think it's getting much better than this, not on this pass. Imma rig this up with _0 and _1 and do the rest of the arousal stages. 

[Bad Dog]

Crap. No matter what I do, I can't get the _0 and _1 to play together. Right now, the mesh changes smoothly to .99 and then wigs out at 1.0. I can't figure it--my last attempted, I re-imported the _0 nif, did NOTHING but move a few verts around, and exported the _1. Same problem. I did it once and thought I had the right to think that problem was solved, but I guess not. Gonna give this a rest and come back to it fresh.

[PaulGreen]

Crap. No matter what I do, I can't get the _0 and _1 to play together. Right now, the mesh changes smoothly to .99 and then wigs out at 1.0. I can't figure it--my last attempted, I re-imported the _0 nif, did NOTHING but move a few verts around, and exported the _1. Same problem. I did it once and thought I had the right to think that problem was solved, but I guess not. Gonna give this a rest and come back to it fresh.

 

I have never actually used blender to do normal mapping before, heh.. I tried it once a few minutes ago and I got a tangent-normal map that I had to invert the red channel on, and that worked. I've found the settings and procedure for doing the tangent maps is finicky.. anything not at default settings and such can throw it off. I dunno !

 

   If you'd like, attach the _0 and _1 or PM them to me or something and I'll see if I can observe anything.

[Bad Dog]

Here's the current not-working meshes. Looks fine till you get to 1.0 then the balls go weird, then the body disappears, then CDT.

khajiit_p0_0.nif

khajiit_p0_1.nif