Leaderboard

Hi folks! I've had a total modernization rework of KOTOR head models floating on my mind for years and thanks to the fantastic tools released on this site, I've been able to get a fully functioning prototype going with a few test cases. I'm starting this thread to document my progress with it and share with the community. First up, huge thanks to developers of KOTOR Tool, Kotormax and MDLops for making this possible. My goal is to build a universal head base that can be extrapolated to replace all the player and party head models with a much more modern standard - one that looks good, and is also very easy to adapt and modify. Hair will be handled as a separate mesh instead of something modeled as a fixed part of the head model, as is the solution in vanilla meshes, removing the need to do skinning cleanup for new heads. Texture layouts for heads are standardized as a result. Where I'm at right now: -New head geometry completed. -New teeth, tongue and eyes. -Eyelids are no longer separate geometry, instead the eyelid models have been converted to dummies and the eyelids on the head mesh are skinned to them, allowing for far more natural looking blinking. -Much more believable eyelashes have been integrated as a result. -Head is fully skinned for facial animation, though this is still a work in progress and needs a lot of testing and iteration. -Early tests for texturing and stylization are underway. First pass with vanilla eyelashes before I took the plunge to try the dummy skinning route, which ended up being a huge gamechanger. Skinned eyelids and eyelashes. Much more detailed teeth! Testing out eyelid skinning. To see how much I can get out of the new geometry I chose to start with a pretty major quick redesign of Juhani based on Cathar from SWTOR. If I have the stamina to see this project to full completion I'll probably also make a 'classic' version. This is probably going to be a pretty long project, but I'll try to keep updating once in a while. I plan to release a full resource pack of this even in the absence of a fully completed replacer mod. Thanks for stopping by! I'll be happy to answer any questions in the meantime.

😀 Let's make KOTOR 3 as a collab! In this way, we'll have more chances to cover its complexity with our numbers. There's also a twist: we have a concept we can use as a basis. This means that if any of us stops working on this mod, someone else can still take their place, because they just need to read the concept to know what to do next. I wrote this concept over the last week, using everything Avallone said in interviews. It's still rough, but contains the whole main quest and details about the main characters. To make it easier to develop, I tried not to add too many planets and quests for now, we may still add them later. This is a holy quest for all modders and fans, let's work together! Check the concept and let me know what you think. concept.doc

Does remaking the existing modules may didn't work for you? Just my 2c -- I think everyone be better off remaking the existing modules rather creating new ones, at least with resources/SDK that we had for now. I mean, modules not only about models and textures -- there are also lightmaps, paths [in PTH format if I recall correctly] and many other details that's close to impossible not seeing the day-light to create from scratch -- that if the goals actually to make them functioning in real-time, rather than only for display/proof of concept. Take this one for example. That's a reskin of RedHawke's ORD Mandell Mod. From what I see, it looks decent enough for a new planet, without having the feeling like it's a straight copy-paste to Dreshdae. Another outstanding example is this one by @Sithspecter [excuse me for using your post as a reference, SS] -- -- if I haven't told that it was a reskin of Manaan's Sea Floor - I wouldn't have guessed, really. Edit: another great example of reusing modules is @jc2's Lehon Mandalorian Expansion. He's remaking the Rakatan settlement as the Mandalorian stronghold in his mod. Though aesthetically look the same, other than that everything looks different with smart replacement of NPCs and placeables. Though locally I did modded the looks of the module, so it looked like this -- -- and that's only changing the skyboxes and the flag's texture. Not yet involved with lightmaps, AuroraLight and fog. TL;DR -- there are much more important things rather than fiddling and getting burned out with newly created areas/modules; such as gameplay, storyline, characters/NPCs, voice-overs and audio [BGM, SFX] are elements that can make a reused modules feels unique and fun to be play with. I mean, big name developers are also known for reusing their assets far as I'm concerned, hahah. Edit2: what I'm trying to say above was -- it's not entirely impossible, only it's a pain to do so. At this point we may have to reflect at Canderis' post above. Also I seemed to forgot that you were talking about doing a "KotOR III" -- I thought it was about new modules, even more a new planet that already send chills down my spine, hahah. I hope that can be useful -- since you asked for feedbacks. P.S. hope that I can contribute more on this one, but since I haven't finished TSL yet think I'm stuck at technical areas for now, lol.

When deciding on the planets you plan to use... you should decide in part with the idea of which k2/k1 modules would you use. If you don't do that then you will have some cool concepts for planets but no existing modules that would fit the planets you wish to have in your game. Also understand a mod like this will take a long time, the more complex you make it,.. the longer it will be.

I want to add something to this in that alpha blending seems to be related to the "background geometry" setting in models. I think this setting is responsible for why the skybox is still visible in Figure 1 of the original post but I'm not quite sure, so I'll describe my situation: I had basically several flat meshes behind each other with textures A, B and C. They were ordered A B A B C with C being the skybox with no alpha channel and A and B both having semi-transparent parts in their alpha channel. In my original setup, neither of these meshes had the "background geometry" flag enabled (not even the skybox C). In that case the skybox would always render in the background behind the semi-transparent parts of A and B. If A and B occluded each other however, only the one with the higher alpha blending would render through the semi-transparent parts of the other. So if let's say A has an alpha blending of 1.0 and B one of 0.9, then I can see A through B but not vice-versa. If they both have the same alpha blending, it would still favor one of them. This seems to be related to the model hierarchy as described by JC here. Basically, they have to be linked to the base from back to front for the semi-transparency to work properly. Things changed however, when I changed the "background geometry" setting. I originally activated that only for A and B as I assumed that C already had it enabled which turned out not to be the case. Once I did that, the alpha blending for A and B no longer mattered. Both A and B would now be rendered through the semi-transparent parts of each other. But now C would no longer render behind them. Once I enabled "background geometry" on C as well everything worked as intended. Now all meshes are rendered behind semi-transparent parts of all other meshes with their alpha blending all set to 1.0. So maybe "background geometry" is some kind of override for alpha blending in that meshes with that setting enabled are always rendered behind semi-transparent textures but if they themselves are semi-transparent, no non-background-geometry-mesh is rendered behind them. Maybe this can help in some instances where only changing the alpha blending value doesn't work.

The TPC texture format contains a floating point number in its header that we refer to as 'alpha blending'. It appears to be critical when used with DXT5 compression. This tutorial will try to help you use this feature properly. What is alpha blending? Alpha blending is not a direct 'opacity' or 'transparency' factor. It is only relevant for non-environment mapped textures that contain alpha-channel image-based transparency. For example, semi-transparent signage, mostly transparent windows, ghosts, etc. The best description I can give you for what alpha blending is: TLDR: alpha blending is not object opacity. It hides any mesh behind the textured object that has opacity less than tpc alpha blending number. Set it to 0.0 when using texture alpha channel as transparency. The meshes that will be hidden include any mesh that may be using alpha channel solely for environment mapping. Let's see how this plays out in practice with some visual aids. Each figure uses a TPC encoded version of the K1 Manaan Overhaul semi-transparent texture for the Sith Embassy signage. Transparency of the sign is right around 50%. Figure 1. TPC with alphaBlending set to 1.0 With alphaBlending set to 1.0 the only thing that shows through the sign is the skybox itself. This may be some kind of depth buffer test to make sure that something always blends through, which, in the 1.0 case, leaves just the most distant mesh, the skybox. Figure 2. TPC with alphaBlending set to 0.9 This seems to be the critical shot. With alphaBlending set to 0.9, lma_wall11 is showing, while lma_wall09 is hidden. lma_wall11 is 100% opaque, 0% transparent. lma_wall09 is 85% opaque, 15% transparent. So because lma_wall11 opacity > alphaBlending, it is shown, while, for lma_wall09, opacity < alphaBlending, so it is hidden. Figure 3. TPC with alphaBlending set to 0.5 In figure 3 we can see that both lma_wall09 and lma_wall11 are showing because their opacities are both greater than 50%. Figure 4. TPC with alphaBlending set to 0.0 This looks exactly the same as figure 3. Wait, isn't that weird though? Why can't we see the other sign through the first sign? It's opacity is 50%, which is greater than 0.0... Figure 5. TPC with alphaBlending set to 0.5, reverse viewing angle Just by looking through the sign in the opposite direction, the signs in the background now are blended through. This is showing a couple things. First, it seems that alphaBlending doesn't actually control instances where the same texture is behind itself. Instead, it appears that there is some kind of directionality at play. I haven't figured out what determines the direction of blending. I investigated whether it was the faces that appear earlier or later, but that didn't necessarily seem true. Using alpha blending The game's vanilla textures use all kinds of different values from 0.0 - 1.0 here. I do not fully understand why or how they have come up with a lot of their alpha blending values. In my testing, it seems like if you have a semi-transparent object, you set this to a low value, 0.0 or 0.1, and if you have a non-transparent object, you set this to 1.0. The important thing is that you do not think of alpha blending as the transparency or opacity of the object itself. If anyone comes up with better guidelines for setting this value through scientific testing, I will be happy to update this post to reflect the improved guidance.

This is an issue that has come to the forefront of my mind recently, as new techniques have surfaced for increasing the overall experience of the game. Taking a card from the programmer's practices, I'd like to hopefully lay down some standards for modding to increase consistency across mods. This will hopefully help with easing compatibility between mods as new releases show up in the downloads section. I'm posting in here to gather input from the community as to what the best practices might be, though again, these ARE suggestions and we certainly can't force anyone to follow these practices. This would also be a good place to rehash our stance on porting, using others' assets and copyright issues. These are my initial thoughts on standards. 1. Override Subfolders I feel like there should be some subdivision of mod assets in the override. Either by asset or by mod, though I would be inclined to discourage by mod, because that introduces potential for increased incompatibility. By adding subfolders, we help organize installation files and add some ease of access to specific files that may need editing. The downside is of course that K1 doesn't support override subfolders. An alternative to this then is applying naming standards to new mod files, but when most of the files being edited are vanilla and can't be edited, this is sort of a moot point. Ultimately, I'm fine with using subfolders for K2, but not K1, since they are not supported, but it might be better to have the standards the same for both games. 2. Texture Formats If you aren't aware, the Bioware DDS conversion tool has been released in the downloads section. It works great and really helps increase performance for massive reskins. However, converting existing mods is a bit of a mixed bag. Textures must have dimensions of a power of 2, must NOT have any compression applied and must have normal orientation. It's not much of a pain to ensure these while exporting textures, and not too much trouble to convert, but every once in awhile you'll get that random texture that's not within those standards and it won't convert correctly. I would even go as far to recommend including the textures in dds format in the mod. I can't imagine too many people will want to edit textures that go in the override, but if they do, I'm pretty sure there's a tool that will convert to tga for those people. 3. When to use scripts I know sometimes it's easier to add a script to spawn a random container somewhere in a module, but in terms of compatibility, scripts are the biggest problem area. If possible, avoid using scripts, add it to the git instead. It probably doesn't make sense to enforce this standard until we have a good way to merge git files (though, I think TSLPatcher is able to do this, but we'd probably need to cover TSLPatcher a little better in tutorials). We also shouldn't be using scripts too heavily to alter global game behavior, but I don't know if I would contest this much because the use case for this is pretty limited. 4. TSLRCM Compatibility I think this seems pretty obvious, but at this point, mods should made with TSLRCM compatibility in mind. There are few who still make mods without consideration for TSLRCM, which is completely fine but certainly cuts down on their downloads. It shouldn’t have to be up to the user to ensure compatibility, nor to some other modder. That’s all I’ve got for now. Don’t mean to step on people’s toes, and a lot of this is up for debate, so please, any input is welcome and encouraged.