PaulGreen

So, I realized a big mistake in what I originally thought about TRI and about UV in them. I used a concerning amount of time to look into this.. Here are collected information I could find. I still don't see much reference to them other than by what other 'fan'-projects have done: Racemenu, Facegen, NiOverride Info: Bodyslide program Info: . So, other observations: So Results: So.. * importer should be able to hand variable-size UV lists. * Exporter can look to see if UVs are ~ identical, and pack them onto one entry for the face-list-index array.. I realize now that this is what the original script was doing. I misunderstood previously. * Making a PIRT import/export script has some use, I guess.. If anyone wants this, post here, otherwise it may be not worth it.

Ok, so I also added the abilities mentioned above... Took longer than I thought . Added ability to import and export multiple files at once. Export requires a checkbox, since it is potentially dangerous (can easily overwrite files accidentally). Also, just cleaned up the files alot, removed old things that didn't need to be there.

EDIT LATER: I attached a fixed version. No UV, since that data is missing. I looked at the whole package. The file named "FemaleHead.tri" in that package seems to be corrupt. It it is possible that it has a data form I'm unfamiliar with, as I've never found a Bethesda-sourced document that clearly defines all possible uses of a .tri file, but this seems unlikely. The file claims to have 2387 UV coordiantes, and in fact does, but then there should be an array of (face_count * 3) integers that tell which vertex each UV coordinate attaches to. In this file, the correct length of array exists, but the data is all "0xFFFFFFFF" which is clearly wrong in the intent of that array to be indexing the UV to verticies. The file may work in the game, because I think the UV are just ignored (at least in skyrim.. Again, not 100% sure), but technically, the file is corrupt as far as I know. This is seen here (if you understand the implication of the image, heh). That is supposed to be the end of the (float, float) UV array and the start of the (int, int, int) Face-Vertex-to-UV-Index array, but that whole array is just FF. The other vertex data can be extracted out of the file, since the other arrays are fine, just no UV information will be saved. FemaleHead-FIXED.tri

This seems good. I will see if I can later, if I do not dissappear again. If you can, post or send me the exact .tri file, I will see. I am fiarly sure that all UV should be 1:1 on vertex, but as error states, not 100%. I need an example of otherwise. I need to remind myself of tri format before I understand how to work with this, if the file is fine. There are two possibilities, and I need to see which: 1) Some vertex do not have any UV. Then, either just don't assign them in Blender, and exporter/importer have to be adjusted to deal with not all vertex having UV, OR just assign all vertex UV in blender, some with 0,0.. 2) the uv is 'packed', and the .tri format has an ability to assign one uv entry to multiple vertex, that I've never encountered. Yes, thank you :3 . Oddly, this is multiple times where I come back after a long time and someone fixes something just before. I updated the files and our changes are almost identical, heh. Importer worked fine, exporter had a bug which is fixed in main post file. I see you have one post, so maybe this isn't a name you use often. Would you like me to credit you in the files I have in the main post, with this username? Importer for this file worked for me, exporter had a bug where shapes would not be exported. Try files in main post, see if it is working.

I had a bit of a motive in asking.. I don't have LE version unfortunately, so cannot test myseslf :3 I suspect it will not. I don't know if you welcome or need information, but if it is helpful. I tried to create a few things similar some time ago, devised some ideas, but failed to follow through. Creature animation slots (defined in sslBaseAnimation) in Sexlab save two variables related to creatues "RaceType" and "RaceTypes" RaceType is set to exactly one value, and this variable designates the "Creature Race" racekey of that animation. This is always set to the most recent creature added to the animation as an actor.. If the slot is created by adding FEMALE, DOG, HORSE the the racetype is Horse If added as FEMALE, HORSE DOG then the racetype is Dog. RaceTypes is an ordered array of all of the racekeys in the correct positions in the animation. So, if an animation is created by adding DOG, FEMALE, HORSE then "racetypes" will be [ canine, null, horses ] In Previous sexlab frameworks (like for LE) there is no method for getting the information out of RaceTypes. It is only available internally. Therefore, there is no method of discovering which particular racekey holds a particular actor position in an animation. However, in one of the later versions of the SE Sexlab (sometime after BETA 4), Ashal added a new function to sslBaseAnimation GetRaceTypes() which does allow getting the racekey for each particular position Since there is now a method of determining the racekey for each position, an animation can be "correctly" loaded for each SexLab thread without having to guess and 'hope' that the actor order is correct, but a method has to be derived for doing this... if one is looking for an animation with a particular sequence of actor races, one would have to go through the entire list of animations every time and test the ordering One idea I was working on was to write a plugin that forces extra tags on all the creature animations after registration is complete, with a particular formatting. Then, one can simply use tag searches with a formatted string to search out a particular animation. A bit more... In Sexlab, there is a convention for the animations that the "receiver" (victim or not) is always the first animation actor slot. This allows one to correctly queue animations as expected.. if you want a "Male on Female" animation, one searches for an animation with the Female in the first slot and a male in the second slot. If one wants "Female+Male on Male", then one seraches for a 3-actor animation with a Male in the first slot. If one wants a "Horse on Dog" then the Dog should be the first actor and the Horse should be the second, "werewolf on dog" should be dog first, then werewolf, "Dog on werewolf" should be werewolf first, then Dog. Some of the animations involving creatures have this convention reversed. I think it was because Sexlab was not designed with detailed creature setups, so reversing this allowed the animations to pick up the "receiver" 's racekey as the animations racetype (since it was specified last), and would play. This technically causes problems when trying to precisely set up animations.. once a system is devised to correctly select animations and actor positions, then the problem is, since the convention is reversed, if you specifically want a "werewolf on dog", you don't know if an animation with A1=wereolf A2=dog is "werewolf on dog" or is "dog on werewolf". If a system is, indeed, devised, my opinion is that the animation authors should go back to the normal convention to make the selection precise Here is a rough draft of a tag-adding plugin I used before.. I remember I was having trouble getting the actual Sexlab forms, so just included a direct form link, which is probably not ideal, but it works. The form ID is copied from SexLabFramework.psc 's own code that sets the CreatureSlots property. The idea is that every animation is tagged with something like C2dragon. "Dog on human" would get C2canines, "werewolf on Dog" would get C1canines,C2werewolf or something

Quick question.. For the "Aroused Creatures" edit.. if you try "Werewolf on Wolf" animation from the HCoS wildlife pack, does it work?

I don't see this answered specifically: Was a method to get mods like this able to select creature X creature animations worked out? In other words, does this (or other) mods allow automatic use of animations like the HCoS wildlife animations?

Ok.. 3rd reply to myself, sorry.. Looking at the OS code again just now , someone else complained about this last year, but specifically related to the importing of slider data onto an already-imported mesh in OS: [ https://github.com/ousnius/BodySlide-and-Outfit-Studio/issues/156 ] A fix was created that specifically ignores the facelist order and keeps the actual V order when importing, by using an import option called "no faces": [ https://github.com/ousnius/BodySlide-and-Outfit-Studio/commit/d05ab360dae7e1cb6bf968dfb2d5303b574144ad#diff-a9deb0b7b91eab12633e63b7e815958a ] I'm not 100% sure what you're doing in Outfit Studio, but looking at the code now, if you select the option "no faces" on importing an OBJ, it will indeed keep the V order on import, but do literally what it says here, not import faces.. If you're just importing slider data, that doesn't matter since all that is cared about is the offset of V position from alread0imported mesh's V position. However, if one is importing a mesh newly, and does want the faces, you cannot use that option, and the import will still reorder V on the order encountered in the face list. Just looking at the OBJ import code, this looks easy to change. I do not know if changing this then breaks assertions the program has in other areas about the order it would then have the data structures in. Only way to know is to try it, hehe.

I think outfit studio is open source.. if this is just a continual problem, I guess one option is to just take the current version and just make this one change regarding importing model types to have a version that doesn't re-order verts.

OS doesn't re-order the verts when importing a NIF's data I'm pretty sure, but does when importing an OBJ's data. So, the NIF has a face list that isn't in the ascending order I've mentioned a bunch, then when you export/import the OBJs, Outfit studio re-orders the verts on import so they don't match. How one gets around that problem depends on the intent of the work being done.

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

Uncompressed textures still work, the SE construction kit will just throw a bunch of "textures should be converted outside the game" errors or some such every time a part is loaded with such a texture on it. Compression into BCx (DXTx) is supposed to have a performance benefit as well, not just from smaller file size, but from loading structure. The form of the data in memory apparently allows it to be processed quicker that an uncompressed texture. I've not looked into the claim at all, no idea the merit. It is not outright foolish claim, since a texture isn't just "processed" once when loading, it is technically "processed" in nearly every frame constructed for lighting and pixel shading and such. No, this is wrong. Apparently textures are converted and stored in memory in certain ways regardless of initial form. The point is that the DXT forms are already in that structure, so there is no processing required when loading the texture into memory, whereas something not in that form requires processing before being stored in memory for per-frame processing. In days where memory bus for GPU is so fast, there is so much memory on GPUs, maybe it doesn't really matter so much. Edit again: This is 'stream of consciousness' posting, heh.. I guess the above still depends on the engine. If Skyrim's engine is such that it will store the texture as provided and re-do the processing into data structures every time texture data is needed, many uncompressed textures may have an effect. That would seem to be really bad method, but who knows. I guess if one really wanted to test, you could back up texture folder, then run that tool above and convert all textures to uncompressed, load a game, and see if FPS is affected. Probably as the textures are loading, so for first10 seconds or so, might be slower, but if FPS still remains the same as when using compressed textures, then there is no problem once they are read and processed.

Every tool I've ever used that exports a .nif file occasionally or frequently outputs a few wrong settings. Basically, 90% of the time, I have to manually fix some settings in the nif. From blender, it's almost always the shader type (gets set to "default" instead of "facehen map" or "skin map" or whatever) and sometimes other things. If it is still failing, can send me output file and see if I can see problems.

The SSE game will not use some older DDS compression types, and CK complains about uncompressed textures, though they will still work in the game. I'm not very familiar with the state of DDS compression, however it seems like the idea is that the new BC7 compression algorithm can compress textures very well, while maintaining nearly the quality of uncompressed textures, while also having the advantage of laying out the data structure of the file to optomize for graphic hardware (which uncompressed cannot do). So, there can supposedly be a significant increase in texture rendering speed over uncompressed to use any of the DDS compressions, then if BC7 is nearly as good, probably should use that. However, gimp plugin and any older plugins have no support for BC7. I understand that, to make the game work or the CK not complain, one should just use BC3 compression for color textures with alpha and BC1 for color textures without an alpha (BC1 vs BC3 in RGB part is exactly the same, only slpha is different), and then BC5 for normal maps, which can be done from gimp. However, the but best option is to use BC7 which gimp and other older plugins cannot do. Note, do NOT use BC5 for color maps, ONLY for normal maps.. it throws away one of the color channels as part of its technique. Info on compression formats: [ http://www.reedbeta.com/blog/understanding-bcn-texture-compression-formats/ ] INtel photoshop DDS plugin which can do BC6/7: [ https://software.intel.com/en-us/articles/intel-texture-works-plugin ] However, microsoft has also released a command-line tool that can do this conversion to BC7: Github project: [ https://github.com/Microsoft/DirectXTex ] Latest pre-compiler release: [ https://github.com/Microsoft/DirectXTex/releases/tag/aug2018b ] You can use this something like [ texconv.exe -o outputdirectory -ft dds -f BC7_UNORM * ] to convert all the files in a directory of known types (BMP JPG JPEG PNG DDS TGA HDR TIF TIFF WDP HDP JXR) into dds with BC7 and output to directory outputdirectory. There are also options to just recusively go through every subdirectory and replace existing files with newly compressed versions. If files are already in a format SSE knows and CK doesn't complain about, there is no point in re-compressing. It'll just lose even more color data in the compression. Some more possibly useful discussion I randomly found, no idea about validity usefulness of the tool linked. [ https://www.reddit.com/r/skyrimmods/comments/8p4g98/bc7_dds_batch_compression_tool_texconvgui/ ]

Are the lykaios eyes in the intended future release of 'yiffy age' using the same textures for them that were in the current available 'yiffy age' or are they different ?