Darth_Sapiens

actually your post over at LF sent me in the right direction, with the greyscale etc. so really you've been the biggest help yet you got me going on this, indirectly, but still.

k well do, i'll get started this weekend

ooh, i wanna do that, it'd be good practice for me

i forgot to take out changedit, lol. the voice and dlg edit's are for splicing/editing a line where he refers to himself as floating. theoretically the dlg is the only incompatibility, and really its cause the patcher can't modify strings and an only appends them to the tlk.

so i have sent MagnusII a pm on LF, here is what he had to say: public class TriMeshHeader { public static int KotorI_Size = 332; public static int KotorII_Size = 340; #region Private Members private int _KotorVersion; /*0*/ private UInt32 _FunctionPointer0; /* 4216656 K1, 4216592 K1 SkinMesh, 4216640 K1 DanglyMesh * 4216880 K2, 4216816 K2 SkinMesh, 4216864 K2 DanglyMesh * */ private UInt32 _FunctionPointer1; /* 4216672 K1, 4216608 K1 SkinMesh, 4216624 K1 DanglyMesh * 4216896 K2, 4216832 K2 SkinMesh, 4216848 K2 DanglyMesh * */ private UInt32 _OffsetToFaces; private UInt32 _FacesCount; private UInt32 _DuplicateFacesCount; private KotorVertex _BoxMin; private KotorVertex _BoxMax; private float _Radius; private KotorVertex _AveragePoint; /*60*/ private float[] _DiffuseColor = new float[3]; private float[] _AmbientColor = new float[3]; private UInt32 _Shininess_Tentative; /* 0 (mostly), 1, 2, 3, 4, 5, 7, 8, 13 * Blend Factor, SamplerStageStates, TextureOperation? */ private byte[] _Texture1Name = new byte[32]; /*120*/ private byte[] _Texture2Name = new byte[32]; private byte[] _Texture3Name = new byte[12]; private byte[] _Texture4Name = new byte[12]; private UInt32 _OffsetToVerticesIndexesCounts; /*180*/ private UInt32 _VerticesIndexesCountsCount; // = 1 private UInt32 _DuplicateVerticesIndexesCountsCount; private UInt32 _OffsetToVerticesOffsets; private UInt32 _VerticesOffsetsCount; // = 1 private UInt32 _DuplicateVerticesOffsetsCount; /*200*/ private UInt32 _OffsetToTrimeshInvertedCountersArray; private UInt32 _TrimeshInvertedCountersArrayItemsCount; /* * = 1, always one UInt32 * sequence goes like this: first * trimesh node is 98, then: * 98..00, 100 * 199..101, 200 * 399..? */ private UInt32 _DuplicateTrimeshInvertedCountersArrayItemsCount; private Int32[] _Unknown1 = new Int32[3]; // -1, -1, 0 /*224*/ private byte _SaberUnknown1; // 3 for non-saber private byte _SaberUnknown2; // 0 for non-saber private byte _SaberUnknown3; // 0 for non-saber private byte _SaberUnknown4; // 0 for non-saber private byte _SaberUnknown5; // 0 for non-saber private byte _SaberUnknown6; // 0 for non-saber private byte _SaberUnknown7; // 0 for non-saber private byte _SaberUnknown8; // 0 for non-saber, 17 for sabers private Int32 _SparkleTentative; /* 0 for most, 1 for water and clouds and * one piece of the GUI * Maybe some sparkle or reflex effects, * or a specular lighting modifier? */ private Rotation _UnknownRotation = null; private Int32 _MDXDataSize; /* mostly 24, 32, 40, 76 with a smattering of other values * if textures = 0 almost always 24, except 15 models with -1 and 23 with 60 * if textures = 1, almost always 32, with several 64 and 68, and a bunch of 100 and 0 * if textures = 2, it's either 40 (mostly) or 76 */ private UInt32 _MDXDataBitmap; /* which data is present in MDX * according to MDXDatabits */ /*260*/ private Int32 _OffsetToVerticesInMDX; // = 0 for most, -1 for lightsabers or when verticescount = 0 private Int32 _OffsetToNormalsInMDX; // = 12 private Int32 _OffsetToUnknownInMDX; // = -1, never present private Int32 _OffsetToUVsInMDX; // = 24 if present private Int32 _OffsetToUV2sInMDX; /* -1, 24, 32 * if mdxdatasize = 24 then it's always -1 * if mdxdatasize = 32 it's almost always -1 except for 14 models where it's 24 * if mdxdatasize = 40 or 76 then it's always 32 */ private Int32 _OffsetToUV3sInMDX; // = -1, never present private Int32 _OffsetToUV4sInMDX; // = -1, never present private Int32 _OffsetToUnknownStructInMDX; /* -1, 24, 32, 40 * if mdxdatasize = 24 or 32 or 40 then it's always -1 * if mdxdatasize = 76 then it's always 40 * this is basically whatever info is in the MDX * after the last texture UV coordinates and * before the bones. It is 36 bytes long. * the last three of these values seem to be some sort of * "weighted normals"... they definitely have something * to do with normals as at least one of these triplets * was equal to the normal in c_hutt --> eye01, and the others * have similar values */ private Int32 _OffsetToUnusedMDXStructure1; // -1 private Int32 _OffsetToUnusedMDXStructure2; // -1 /*300*/ private Int32 _OffsetToUnusedMDXStructure3; // -1 private UInt16 _VerticesCount; private UInt16 _TexturesCount; private UInt16 _HasLightmap; //0, 1 private UInt16 _Shadow; // 0, 256 private UInt16 _Render; // 0, 256 private UInt16 _Unknown2; // ?? private float _TotalArea; // sum of faces' areas /*320*/ private UInt32 _Unknown4; // = 0 private UInt32 _Kotor2Unknown1; private UInt32 _Kotor2Unknown2; private UInt32 _OffsetToMDXData; private UInt32 _OffsetToVertices i'd wager the four textures are, the base, the lightmap, the bumpmap and the environment map.

Wrapping up how I feel about this. I really like the movie, the trailer looks cool, but while I watch it, I think of the universe they're rewriting, which makes the experience bitter sweet. Do I agree with Disney/LF on this decision, no. However I see the reasons why they did what they did. But we're past the point of debating the merit of cette decision. It's done. I'm not happy, but I'm past the point of anger. From now on the story will be more controlled, is this good or bad? No one can say for sure yet how this will play out. I feel numb towards star wars, whereas I once loved it. But I don't think it's fair to compare decades of the star wars universe with it's vast amount of content to a trailer less than 5 minutes long of the new story. So while I no longer love star wars, and I feel numb towards it all, I'll give it the chance to grow on me again. It's not like the old universe has ceased to exist, they're just done telling its story. No doubt many EU settings and themes will appear again. How this new story will grow and expand is as of yet unknown, but I'll give it a chance to grow on me, the minds behind our star wars didn't die with it, I'm interested to see how they'll shape the new one.

after doing some thinking i feel almost as if it's in the mdl of the file, specifically it has to do with materials, i think the game loads the model , the model gives it a list of textures, with various parameters, one of them having to do with bump mapping, for example the quarren, is all one model right? but we can only apply a functional bump map to his head. a visible example (not my screen btw, bottom right on the wall) notice how only the one texture/material has a bump map?, also when i tried earlier to bump map the dantooine cliff, nothing happened, but the water definitely has a bump map going on. iirc they are on the same model.

well i can crossout txi & appearance 2da, so they're either hard coded, or they're in the model, i really doubt them being hard coded, in all the string-dumping i have done on swkotor2.exe i have only seen bumpmaps mentioned in the txi code.

The bad/good news, The good news: the games both use bump maps the exact same way, The bad news: Not all models accept the bump maps, For example, I couldn't get any sort of custom bump map to work on any models that don't support it (space suit, robes, Nihilus, Mandalor,e etc.) Some that do for sure are the Twi'lek male head, the Quarren, the Rakghouls, etc., in TSL. In KotOR1, Hutts do too (for some reason Obsidian cut this for Vogga) , I think this is something we need to edit models for, but that is far from my area of expertise. Help me [unknown super modder], you're my only hope!

I'm feeling the same as you, except I'm still bitter over the EU being abolished.

check out this screen

so we can change cubemaps by using a certain visualeffects.2da code. the effect is pretty cool. now how can we use this???

already on it

kotor and tsl have cubemaps for every area-ish, they are just too low res to notice the difference lol. check out anything with a CM_ prefix in the texture packs, we can remake them, however ktool garbles them when extracted.

Oh wow guys. Yeah, I'll check everything out and see if I can/need to make a patch It might be a little while though. Thanks for the support, guys!

well, not always, but mainly vanilla textures are, however in reality, all sorts of resolutions work for textures, but for bump maps, it doesn't seem so.

Sorry, to resurrect this thread, but I felt this is a better place to put what I found than into a new thread. Where to begin? Well, I have found out something for sure, we can make bump maps, they have to be in grayscale, that means not rgb mode but grayscale mode in photoshop, with no alpha channel And as for dimensions, they must be a power of 2 squared, (2x2, 4x4, 8x8, ... , 256x256, 512x512, 1024x1024, 2048x2048... etc.) So now we have a texture that is considered a valid bumpmap, it won't crash your game, and will work when called/defined as a bumpmap. In its txi there are some fields we can now fill namely: isbumpmap 1 // Mandatory, without this it won't be treated as a bumpmap bumpmapscaling 1 // this is for how high or low the bumps should be (0.5, 0.75, 1, 2.25 etc.) The following are some commands, from Never Winter Nights, that are in the kotor/tsl .exe but I haven't tested out in game yet // Specify what kind of bumpmapping this bump map will do: specular, diffuse, or both. These values are ignored if this texture is not a bump map. isdiffusebumpmap 1 isspecularbumpmap 1 // Specify a color for specular bumpmap highlights (RGB). This value is modulated with the bumpmapping light's color to produce the final highlight color. 1=255, 0=0 specularcolor 0.5 0.5 0.8 So, here comes the theortical part. How does kotor do bump maps? in two ways, A from a grayscale texture then renders a tangent normal map, B from a pre rendered tangent-space normal map. Almost all the bumpmaps in kotor are prerendered, they come out in rgb when we extract the with ktool, but they also always crash the tpc viewer. It seems this is the more efficient way to do it, but it is not something currently we can do, (we can keep experimenting) but what was needed for efficiency in 2003, is a luxury, I'd say we can afford to take in 2014. in the end the gpu get's the same thing from either method, (according to glintercept). Lastly here is the experiment I ran, let's see what we can do now with bump maps! my experiment:

@xedii, The bump maps I actually have working at 1024 right now. I think it just needs to be a multiple of 2 for them to work.