ndix UR

I do have an AMD card, but I'm not sure how much that is really a factor because I am playing via Wine on a non-windows platform, so I don't have the usual ATI driver packages or OpenGL extensions. I tried something that, while I'm not sure it is a viable 'fix', might be an interesting experiment. Try adding both these lines to your TXI file: mipmap 0 downsamplemax 0 Also make sure you're using a TGA in Override or the TXI file will probably not do anything. For me this actually seemed to clear up the issue with Mission's face. It's not generally applicable everywhere this problem arises because it looks terrible for bodies and other things that are heavy on detail (winds up looking severely aliased from a distance). If it helps you though, we might at least be able to say that it is the fault of some sloppy math somewhere in the mipmaps/downsampling algorithms (to me, it seems like both, because either one of those lines alone doesn't fix the problem, but both together did).

I ran the experiment also, and had some similar and different results. Same: different resolution didn't seem to make any difference. Different: with DP's textures, I don't get a black line, I get a red line, which suggests that ... w/ my setup ... the texture image is tiling and there is some bleed from the right side of the image. It seemed more noticeable the further away you are. Here are my test images: mission-face-line.7z Also, I've had a CM_SpecMap envmap TXI in place from the beginning, using all TGA texture images. mission-face-line.7z

I also regularly experience this issue. It seems to be an issue with the algorithm in the game for getting data to make mipmaps from. Mipmaps are smaller versions of your texture which the game uses for rendering at different distances. This is why close up you (almost) never see this issue, and it is generally very affected by camera angle/distance. You can reduce the issue by making sure that all your UV islands have nice big like-colored dead zones/borders around them. I didn't know this early on and have paid the price. The game's mipmaps are 1/2 size at each 'level'. So, at the first level, your UV island border pixels are blended with 1 pixel (from the original sized image) from across the border. At the 2nd level, 2 pixels, 3rd level 4 pixels, 4th level 8 pixels, 5th level 16 pixels. It's a bit more complicated than that, but that is kind of the general idea. You have to balance the size of your border areas with the level at which the mipmap has so little detail it doesn't really matter. Like, a 2K texture will have 11 mipmap levels, which would need UV island borders of 1024px to be "perfect" at the last level ... but that last level is only 1 pixel, so what detail would you really be trying to preserve with that? For me, personally, I find 16px for 2K textures to be a good balance. A reason why you see this less in default textures is that they use the TPC format, which includes precomputed mipmap images (for which, presumably, they took care to make sure the mipmaps came out with good visual characteristics). TGA images don't have mipmaps, so they are generated by your video card (there is an OpenGL function that does this), which is also why there is some variance w/ different cards/drivers/etc. Seems like driver-level AA settings would help too, but in-game AA settings don't seem to affect the issue. In an ideal world, the mipmap generation would use UV mapping to refrain from using pixels from outside the UV islands, but that is not 2003 tech My understanding for why this issue never really goes away is that the game seems to maybe use black pixels when a mipmap is blending with pixels outside the border of the image. That is just a theory though.

I was trying it briefly the other day and I concur with JCarter426 that reverb went a long way. I was testing compression and curves when I had to walk away from it. Hopefully someone will have time to figure this out.

File Name: Ebon Hawk K1 Fixes File Submitter: ndix UR File Submitted: 01 Aug 2017 File Category: Mods K1R Compatible: Yes This mod provides geometry corrected versions of the following EbonHawk model files: m12aa_01e m12aa_01f m12aa_01h m12aa_01j m12aa_01k m12aa_01p Screenshots show some of the problems that are fixed. ****************************************************************** ** Ebon Hawk Geometry Fixes ** ** A Modification for Star Wars: Knights of the Old Republic ** ****************************************************************** Author: ndix UR Filename: EbonHawk-K1-Fixes-V2.7z This mod fixes a number of geometry issues with the Ebon Hawk models used in KotOR. It attempts to plug all the holes in the ship and make it space-worthy. Compatibility: Likely incompatible with other mods that replace Ebon Hawk model files, but is compatible with other mods that modify the cockpit external views for Ebon Hawk, as this mod does not touch m12aa_01q, the model for those. Known Bugs: None. It will not work for K2:TSL, which uses different models. Installation: Place the files in the 'For Override' folder into the Override folder in your game program folder. Uninstallation: Remove the files from your Override folder. Legal Disclaimer: All materials and copyrights belong to LucasArts, Obsidian Entertainment, and Bioware Corp. The author places no warranty or restrictions on use of this mod. Click here to download this file

FWIW, the issue I had with BoS:SR was that TSLPatcher was trying to write to nested directories without creating them (for backup purposes). I don't remember what I had to do exactly, but it was something like ... in the bos_sr_1.0 installation folder, create 'backup' folder manually, create a 'modules' folder inside of that. But then also create a 'modules' folder in the main installation directory. My assumption is that TSLPatcher copies files temporarily to the main installation directory (maybe to patch them?), then moves them into backup/ on success. In this case it is trying to copy a file like "modules/ship2.mod" without recognizing that the path actually includes a sub-folder. At least that was my theory. K1R I've never had issues with.

An update coming this Saturday eh? I really hope this isn't going to be Duplisaber Cathalan Edition, with all orange crystals and hilts. I would be a little disappointed because Duplisaber is actually a great project

So, your second issue, regarding connected geometry and different UVW vertices along island breaks. That is a limitation of the MDL/MDX format and cannot be worked around (well, unless MDLOps were to automatically split edges that need to be split, which is technically possible). You have to double your vertices along every edge of UVW islands. It is because vertices and UV vertices are stored together in single MDX rows, so you can't have a UV without a geometry vertex, and you can't have multiple UVs for a single geometry vertex. You can tell whether you are going to have this problem by opening your ASCII model in a text editor, going to the node you modified (torso), and seeing if the number of verts matches the number of tverts. If it does not, your model will have some kind of problem, maybe subtle, maybe not. And on the first point, you are quite right. Current versions of MDLOps don't smooth across disconnected geometry, which is required at UV island edges, so it can never smooth across different UV islands. The fundamental issue for current versions of MDLOps is that they only accumulate vertex (& face, if I recall) normals from connected geometry. Also the current versions of MDLOps don't do anything with smooth group numbers. I apologize for any inaccuracies, it's all top of the head. The way I have been working lately is to weld all the vertices, and then towards the end, I go around each UV island edge using 'edge split' to double the vertices as required. That is a blender command though, so you'd need to find/do the 3ds equivalent.

Yeah that info was directed more at the other windows PC builders that might want to help you but didn't read the specific manual for your motherboard Everything else in the part list looked good to me. I think you'll probably be bringing the machine up to a pretty happy "minimum".

On the SSD front, the motherboard you currently have selected sports an Ultra M2 slot, which will supposedly take a SATAIII or PCIe 3.0 x4 type M2 SSD. I guess SATA M2 exists for extreme form-factor stuff. In a tower I would think you would just use a 2.5" SATAIII SSD if you're going the SATA route. The PCIe M2 SSDs are spendy but generally much faster (very unlikely that these are limited by the connection speed in any way as PCIe 3 x4 is giving it almost 4GB/s of bandwidth, compared to a .75GB/s SATAIII connection or 1.25GB/s SATA Express) I think, though, if it's your first SSD, trying to get a slightly larger capacity (512G minimum) SATAIII in the 2.5" form factor is probably a good bang for the buck. Maybe somewhere down the line a PCIe M2 SSD would make sense, but I just think it's probably too expensive right now to get one that you can fit a Windows system and games onto. Personally I like Crucial as an SSD brand, but I have no idea what is good for Windows, so grain of salt please.

B4-D4 vs Verbal

Thanks! The cockpit seems to be the hardest part by far... For K1, I finished my detailed walkthrough and found the following geometry issues in the rest of the ship. In the cargo hold (with the supplies dispenser): In "Kreia's room" there is an open seam on the floor to the right of the doorway (when exiting the room) There is a small open seam to the left of the doorway that leads from the swoop/workbench room in the direction of the engine room & cargo hold. The 'main section' w/ the holo-emitter has a few open holes in the floor, most of which don't get noticed because they have black behind them. Here is one of them: There's also z-fighting at the threshold of the engine room, but I didn't get a picture of it. Partly because it doesn't come through at all in a still pic. TSL Ebon Hawk 003EBO I did a walkthrough and first bit of investigation into the TSL 003EBO module's models. Obsidian made it harder to detect most of the seam issues by surrounding the back 7/8 of the ship in a star box (almost all black). However, they also made the lightmapping a bit brighter in a lot of places, making some of the other seams easier to see (esp. in the cockpit). Stuff that was the same as K1: - instrument panel seams in the cockpit (not the big gap from Example 1 though) - z-fighting on engine room threshold - small open seam on doorway from workbench room What's new? - way more lightmapping issues, the most common 'issue' is that things have just been blacked out in the lightmap texture image. - the black floor panels on the way to kreia's room are the only ones i found where the lightmap error is "these are completely unmapped". - more loose polys, similar to the black plane popping through the cockpit instrument panel, but less bad in other places. Medbay lightmapping: Front hallway just outside cockpit: This is a seam issue that you could not actually see in-game in K1, but which I fixed up all the same in the K1 model I posted before... These are new, loose planar polys in the doorways, haven't backtracked them to see what they are connected to. I took a hidden one of these out of the front window of the K1 cockpit... I think that is pretty much it as far as I've been able to tell so far ... I don't have fixed models ready for upload, though I do have a bit done (K1 hawk might be completely done unless other people find more that I have missed) This was the hardest part, so I started with it. It came out ok but maybe not perfect I think: I'm at the limit for pics in a post, if you want to see the last one or two, here's a link: https://imgur.com/a/dSkf1

Wow, when you crack open the Ebon Hawk cockpit model in a 3d editor it is a wonder the ship doesn't fly apart! I found several more issues (these are all for K1, model m12aa_01p): There's a hole in the wall... No shortage of open seams around the instrument panels... And, not sure how I never noticed this, but now I can't unsee it... Everything I saw in this model for errors was geometry based. The holes in the Example 4 panel were maybe supposed to be part of one of the animated meshes, but yeah, no geometry is present in those spaces. Same for the hole in the wall. To get the ball rolling, here is a fixed version of the K1 m12aa_01p model: EH-cockpit-fixed-K1.7z I filled the Example 4 holes using a new mesh w/ different keyframes from any of the other blinking lights ... so that part is neat. It seemed to come out pretty well... No lightmapping changes ... the only thing that seems maybe questionable to me w/ the lightmapping in that model is below the Example 4 instrument panel there is a very black area w/ just a few blinking lights. It looks a bit odd, but maybe intentional. I had to cheat a bit, copying and translating the AABB tree from the original model. I have a thing that generates AABB trees, but apparently not well enough yet... The model worked fine for me, but it is pretty experimental so hopefully it will work for you also!

I like the idea of covering basics, but I feel like it could have issues. I very much agree with the statement that 'going anywhere from here requires an understanding...'. For me, where I've been trying to get to since the first stream is having my own 'testbed' module. Basically, a clean module that I can add whatever I need into without worrying about weird script conflicts, pre-existing items/scripts/waypoints/etc. I'm mostly there now (it took awhile because I modeled it from scratch). The issue I see with covering basics is that there are a lot of basics to cover. Like, so many that it becomes really hard for people to take in all at once. I started to have that issue w/ the scripting streams, but I took good notes and have continued processing it over the weeks. A couple weeks ago I watched HarIII's new module tutorial videos on youtube, which is a 15+ part series that covers a huge number of 'basics'. The thing I really like about it is that if you follow along with it you go from zero to a place where you can actively work on new things, and the info is easier to retain because you're always trying to do something specific and concrete vs. abstract. So my personal request might be something like 'comprehensive basics' OR 'more scripting', but either way towards some concrete goals that leave people w/ a place to jump off from. Schedule-wise, Thursday nights work for me, but I'm likely to make whatever time work. Thanks for doing these!

@setite, I have a similar background in terms of programming and photoshoppery. I started taking a hard look at the dialog problem around 3 months ago. I tried a few different 'generative' audio methods (based on Google DeepMind's Wavenet algorithm), but found them a bit lacking. The idea of using an actor and then using software to modulate the voice into the selected character is an interesting one I haven't looked into too much. I've been pursuing the steps for programmatically producing new dialog in a concatenative way. I am currently still at the point of generating the full speech-to-text map per-character. The maps I'm producing are JSON and contain each word w/ time interval and the filename. They are being derived from an IBM watson speech recognition pass w/ a customized language model. I have a custom nw.js app I'm running after that process to produce human-reviewed/confirmed results. Once those maps are all built out, I plan to put them into a form keyed by word, so that new dialog can be pretty easily created ... from within the corpus of words a particular character has pre-recorded. I am assuming that some amount of post-processing will be required to make them actually sound natural, but that's at least two problems down the road... Could be interesting to combine the splice-n-dice technique w/ the modulation approach to mix in needed new words for a character... So, my point is, while I have no concrete time estimate on how long this might take, there is a possibility of being able to produce new dialog in a less hurty way on the horizon ... especially if you know how to run python code (because it's really trivial to go from the JSON dictionary to an audio file in python, at least 50% harder in javascript for a cross-platform GUI app).

@FarmBoy0 thank you very much for posting your K1/2 binary templates for 010. I purchased 010 because of this and have been quite happy with it. Before that I was using vim + xxd! I did heavily modify your originally posted templates for my own use. The recently updated versions are clearly much further along, there are only a couple major issues I find in them. 1 - a few emitter controller numbers are off or missing, here is a diff between your version and my newly edited (not finished) version: 2 - the alpha controller is 132. 128 is just p2p_bezier2. 3 - the first byte of uint32 field_50 in the model header is the 'classification' of the model, pretty important, so I break it out like this: 4 - in the mesh header, int32 garbage[6] is where the animation of UVs goes, this is used for flowing rivers, rotating planets, cloudy skies, and is completely separate from TXI animations: 5 - the unknownFlag following rotatetexture is 'background_geometry'. I do not know how it is interpreted by the game. 6 - the emitter header has a few things that are different from what I've been using. I have little idea which of us is closer to correct here. I think I would like to PM you about this stuff and/or do more research on my end before just posting info or a diff. @Otaka, I am not diving into mdlops 0.6 to see why it produces that output, but it is probably stemming from the fact that the animation there uses 'positionbezierkey' animations, which mdlops tries to dumb down into linear 'positionkey' keyframes. Bezier animations have 3 floats for every piece of value data, rather than just 1. I cannot really explain what all the numbers do for these, but the extra numbers must be related to the interpolation around each value. I assume that you were looking at the opening1 animation in dor_lda01, at the position animation for Box04? If so, the raw controller data looks like this: positionbezierkey 0 0 0 -0.04 0 0 0.1 0 0 0 0.0333333 -0.0167227 0 -0.04 0 0 0.1 -0.0143337 0 0 0.1 -0.0645015 0 -0.04 0 0 0.1 0 0 0 0.2 -0.0474168 0 -0.04 -0.00970267 0 0.1 0.0229322 0 0 0.533333 -0.0474168 0 -0.04 0 0 0.1 0 0 0 2 -1.90687 0 -0.04 1.23963 0 0.1 0 0 0 Or, made into linear: positionkey 0 -0.04 0.1 0 0.0333333 -0.04 0.1 0 0.1 -0.04 0.1 0 0.2 -0.04 0.1 0 0.533333 -0.04 0.1 0 2 -0.04 0.1 0 Current and older mdlops has more than one issue that creates problems with controller and animation decoding, so I'm not sure which ones you are hitting. Hopefully this will help you at least understand where some of the weird numbers are coming from. On a side note, that is a really weird controller/animation node, because it doesn't seem to be changing the position at all (-0.04, 0.1, 0) ... just changing the interpolation (which would define the motion between changing values). So I kind of have no idea what to make of that animation. Sorry.

I have 2 minor pet peeves: 1. Panel walkmesh in IS56's area: one of the panels you can just walk right through, while all the others are fine. 2. Panel orientation in 3rd recharge station of Environmental Zone: one of the two computer panels is not parallel to the wall, making it partially clip into the wall.

This would be great to attend. I would love to see how you do debugging stuff (like testing what values are in what variables, etc). I am PST (UTC-8) but I live weird hours and might make it at any time.

Thanks for doing that extra testing. It is good to know that issues can arise for some configs on bumpmap-capable models that are missing their bumpmaps. Otherwise, I had basically been inclined to recompile everything (characters at least) as bumpmappable, maybe now I will only use it for things that it will really help (and/or for which a decent bumpmap can be produced with relative ease).

They're not so much 'custom' as the new standard, Darth Sapiens cubemaps. You can get them here: http://deadlystream.com/forum/files/file/498-modders-resource-cubemap-pack/ You would also be able to just edit the TXI and set it back to CM_Baremetal also. I am currently lacking any access to nvidia gear, so that is an interesting tidbit. Here is a pack of the 2 more test models I outlined above. The one in bump/ can take a bumpmap. The one in shadowfix has the extra head. C_ForDrd-testing2.7z

Oh fun ... so, it could actually be 2 different things, the bumpmapping stuff, or the extra geometry node. I'll create a couple different versions for you to test (one that can take a bumpmap and has no extra head node, and another that can't take a bumpmap and has the extra head node). That will have to wait for tomorrow though. For data's sake, what manner of video card/GPU is this on? maybe also OS/game type (like, CD/GoG/Steam) would be good to know. For the meantime, here's the very simple testing bumpmap I've used w/ the model (including the TXI files I've used). I can usually tell if it applied/is working by looking at the edges of the bands on the canister on the droid's back. When I was testing bumpmapping very specifically I was using images more like the ones from redrob's LF thread, black backgrounds w/ white text, and pairing them with diffuse textures that were just a solid color. OH, that reminds me, bumpmaps also work like envmaps, in terms of the alpha channel, so if you want to see the bumpmap effect more clearly turn the alpha way down on your diffuse texture also. C_ForDrd-bm.7z

Hmm, well, the UTC approach is probably the quickest way to go about it. I can't speak directly to the quality of it as a technique as I've never created a UTC file myself. I usually go with the "simple" approach of just finding the model pre-existing in-game. For DP that was in the Dxun underground Mandalorian cache. For me, it's been the industrial zone in M4-78. Thanks DP ... I hadn't been able to quickly think of another location to check, and it's nice to have one that's in the default game content. I tested the Dxun cache here and it worked fine for me. Personally I would try to determine if the problem is related to the UTC, the model, or 'other.' So, remove the UTC file from your Override temporarily, use DP's save to test the Mandalorian cache scene. If that works, put the UTC file back into Override and remove the C_ForDrd.mdl/mdx (I would actually use KTool to extract the vanilla C_ForDrd.mdl/mdx and put them into the same place in Override you had the custom model files in order to reduce the number of things being changed in your test). If neither test fixes the problem, the issue is probably 'other.' If the problem comes back to the model, here is a simplified version of the model to try. It won't take a bump-map and (on my system) it has weird head shadow issues, but if it fixes your problem that would definitely be good to know. C_ForDrd-testing.7z