sELFiNDUCEDcOMA
-
Content Count
359 -
Joined
-
Days Won
18
Posts posted by sELFiNDUCEDcOMA
-
-
@ sELFiNDUCEDcOMA:
I'm not sure a tool exists to merge scripts automatically, so you still need to make enter scripts for all mods you want to be compatible with. And no, there's no way a file executing another file can "outcomment" something happening.That's not what I meant. You have an OnEnter script that is made up of include calls, you can comment them in and out and switch load orders prior to compiling it and placing it into you override. Pretty simple really, even if this is something a mod author may end up doing as the average user has no clue when it comes to scripts. Basically creating a range of script variants supporting different mods.
@ sELFiNDUCEDcOMA:
Also, why, if you can modify the onenter, would you want to execute another script rather than just doing it right there (unless of course engine crap demands it, as seen in the Telos Cantina for example IIRC). Adding more and more 'runs' just adds to being it more likely to have issues, not less.Ah, so as to have a LOAD ORDER that can be tweaked by other modders so as to make it more compatibility with other mods.
The OnEnter is nothing more than a container that calls other scripts, one that is exposed so as to make modding those modules easier without having to actually modify the modules themselves. If there is an issue, all you have to do is remove the OnEnter script in the Override and it reverts back to the original state TSLRCM safe version.
And more "runs" ain't your problem or even other modders' problem, it is the users who try and use this to have 100 mods running at once. Which may not be the case unless they are comfortable with modifying and compiling scripts.
@ sELFiNDUCEDcOMA:
Also the "I have to upload all my files with the next TSLRCM version" doesn't really hold much water after we're pretty much done, it's very unlikely that more is done and if so it's also unlikely to modify the onenter. They're really barely updated per version, big updates like 1.7,1.8 or 1.8.2 excluded.
1.8.3b it was just 207TEL (fixing issues with the Swoopstuff OE had set up) and 351NAR (fixing stuff we had set up inproperly).
Some of my own mods editing enter scripts (like My Dantooine Statue) has been as is since 29 janury 2012. Only the .dlg's got updated.Yes, well it does happen and when it does people expect the mods to be checked for compatibility issues. Not everyone bothers -- because it was once off work or they just don't have the time/interest to do so-- which can lead to some mods not being used anymore due to being perceived as potentially resulting in bugs.
From my point of view, this becomes less relevant if OnEnter injecting is used.
@ sELFiNDUCEDcOMA:
And it's very likely for alternative onenters to cause issues, just try making one doing a cutscene on the EH, and then running the original onenter. It's going to work poorly.That's why you have an OnEnter script that is doing nothing more than calling other scripts; some can be called prior to the original, some after.
Plus, I didn't say it was a cure all. Sure, OnEnter injecting isn't going to be a solution for every specific problem. But where it works...
But most files can be de-compiled with DeNCS, there are very few exclusions.
Does anyone have an active download link for DeNCS..?
-
Hey all, sorry for the (long) delay in reply; after a short break I started work again and it tends to be demanding for the first few weeks. Whenever I had the time I tended to be too tired to remember or motivated to write this.
Skybox tex comment: 2048 across the board would be heavenly. Some of that depends on what people can export at. Maybe set 1024 as acceptable, but 2048 preferred?
Sounds good to me.
Could you clarify this a bit? Are you suggesting making subfolders specifically for compatibility? That sounds like a good idea. I'd like to hear more on it.
Well, at the moment I have the following folder structure:
ARMOR
BUMP -- more so a temp folder for testing
COR
DROID
DXN
EBO
GEN_NEW
GUI
HAB
HEADGEAR
INVENTORY
K1_TEX
K2_TEX
K2TSLR
PER
PORTRAITS
ROBES
TEL
WEAPS
WScreen
As you can see it's already a long list along with not really having much of a naming convention or standards in way of what goes where. I can imagine that if I keep it as is and other modders use their own folder structure, that quite a bit of conflicts would arise.
This sounds like a generally good idea. I would just hope that there's not too much script injecting going on. Perhaps it would be worth going over the specific process. Then we can coordinate with TSLRCM to increase the compatibility for future modders. Though scripting has proven itself to be extremely buggy in the past.
It's pretty simple really, you either replace the OnEnter script for the module to point at something like: OE_PER202, probably found in an "OnEnter" subfolder -- for ease of modification. The last line of the script would have an include for the original OnEnter script if the module had one. An alternative -- depending if the uncompiled scripts are available -- is to edit the original OnEnter script to have an include for the new OE_PER202 script. Regardless, the script can be easily found within the new "OnEnter" subfolder and modified by modders or those using mods. Users should be able to resolve some conflicts by simply modifying the load order for the included scripts -- EDIT: via a script editor / compiler.To be frank, I use an SSD drive so I don't notice any real "performance" issues to do with scripts, but I can see how scripts loading a lot of things will cause lag.I don't really see the benefit of this. Aside from being a lot of work to put up you:
I didn't think you would agree with this, and to be frank once again, I don't expect you to do this at all. However, I will comment regardless:* Basically shift incompatibility from one file to another, solving nothing.
* Risk increased errors if different mods modify the different file seperately and incompatable.If users have power in that they can edit the new OnEnter script -- EDIT: via a script editor / compiler if the uncompiled version is packaged with the mod -- and modify load orders or even comment things out for debugging; well, I don't see how that is shifting "incompatibility" (or problem) from one file to another.Another option is that modders can provide multiple versions of this script to support compatibility for various mods.I don't really see the benefit of this. Aside from being a lot of work to put up you:
* Limit yourself in the options, for example to have something NOT happening outlined in the original enter script. Which I did a fair number of times with TSLRCM, like not having 201TEL remove a global that was supposed for 209TEL.
* Run increased risk the game will go "kabloem" with several potential mutually exclusive scripts running, and hiding the conflict source (say, script 1 unsetting a local, when script 2 checks for that global).I think we have a different view of what the OnEnter scripts would do and how they work. The original OnEnter script would still get called rather than being replaced. And if you are simply using it to add various things based on an initial check to see whether it is necessary, then I don't see how there is the conflict you are suggesting. My understanding and use of the OnEnter script is that they are called once and run once on entering the module, rather than this being a script that is called every so often by the game. Further, when a script is included, it is essentially run before the next included script is loaded and run. It's procedural not concurrent -- though, I could be assuming here.It's an interesting idea, but I don't see it adding value and compatibility rather than being a source of more trouble and hidden conflicts.
I really don't agree, and think it is quite easy to take that point of view when your mod is TSLRCM and you don't have to make it compatible with any other mod, rather, every other mod has to make their's compatible with yours upon every single release.OnEnter injection gets around this to a degree, in that I don't have to update anything other than the scripts if I even have to do that at all.Any issues OnEnter injection has, is more to do with bad scripting and a lack of conventions for scripts and the usage of this type of script IMO, and I doubt that I won't make use of it in the future as it makes my life easier at the very least.Good point on this here, but I don't know what we can do about the tools for that now (other than editing UV Mapping for area models...?). We'll have to come back to this at a later time probably.
There are several options for rescaling UV maps, though most are fairly tedious.
First, if a texture is scaled badly, you can obviously enlarge the texture by a factor of 4, which would fix the badly scaled portion. But, this unnecessarily makes the regularly scaled portion a bit too fine of a resolution.
You could find the object names of the portions that are scaled badly in 3DSMax and hex edit those portions to use the larger tiled texture. This process is going to be pretty tedious, but it would seem to have the best results.
You could also pull the whole model into 3DSMax and adjust the UV maps, and use the Replacer function to change only the maps and preserve other qualities like animations and lightmaps. I'm not 100% sure that would work though. Once again, this would be somewhat tedious, but probably a bit easier than hex editing.
Yeah, hex-editing along with up-scaling is the usual way to go; don't believe that the modifying of UV maps and the use of the Replacer function works that well if at all. Don't recall it doing so.
-
1
-
-
I'm getting pretty tired of bouncing files between Max and Blender so I made this.
Here's a random mesh I made, exported and compiled:
http://oi57.tinypic.com/8we2kh.jpg
Latest version download (0.4):
http://www.mediafire.com/view/1cyc0b753c2f278/kMDL_export.py
Previous versions:
How to use:
2. Trimesh all models (CTRL + T in edit mode)
3. Select what you want exported
4. File > Export > KotOR Model(.mdl)
5. Use KAurora to convert to binary
Textures tverts will be assigned to the first UV map and lightmaps to the second, if there are no UV's assigned to the model, the exporter will just skip exporting them. There are still a few things that I wish to add, so more to come.
Thought I'd give this a bump by asking whether anything was new with this and what you still had "to do."
Nice to see another tool that supports another 3D modelling package; especially as Blender is widely used for modding and indie games.
Plus, really nice to see a tool use something other than Perl
. -
Anything that we do show will be in a complete state, not something that we've spent 10 minutes on and want to get a little attention for.
Amen to that!
-
I think the skybox looks great; not sure I'll ever bother to make my own version.
The graininess may have a lot more to do with the renderer, it may be more obvious out of game as seen via a screenshot over in-game.
Though, you may consider simply downsizing a version of it, then up-scaling it back up to the original size, then overlaying it via the first in PS and playing with transparency and blend modes. Might be a bit quicker than trying to replace certain textures you've used... Just a thought.
Regardless, I think most people -- apart from the odd whiner
-- would be really happy with that. -
thanks!! its look like its far more complicate that JKA procedure.
shame there is no tutorials about this, to aid in the process.
I
Well, it's not really done all that much, so no one's really bothered to jot down all the little details...
Might this not be something best moved or recreated as a tutorial found within the tutorial section of the forums..?
-
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.
Just thought I'd mention that you are limited to how many levels (branches) there are to your override folder. From my experience, you can have a sub-folder, but, you can't have a sub-folder within that one. At least that is my experience from using them to organize my mod project work.
In way of standards for these folders, I would suggest that for base-game shared files that they go into the main override folder. For those specific to certain modules, they go into module subfolders. I would also suggest that if you are creating new assets, that if they are for a specific module, they go there, if they are "generic" and used across the game like weapon models / textures, then they go into a new subfolder for weapons, however, prefixed with an identifier for your mod. Alternatively for the last, you simply have a Weapons folder for all weapon file assets -- you'd do the same for armor, characters, etc.
I have a similar structure for my own mod WIP, mostly to make it easier for me to work with the assets and to separate mine from TSLRCM. However, if you want to ensure "compatibility" then you have this folder structure by default in use with TSLRCM. You would create the various folders even if you end up putting nothing in it -- so that other modders, would make use of them instead of creating their own with some idiotic naming convention
.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.
If this is the old NWN command prompt tool, I recall it did an ok job of it. But as long as it is doing a good job of converting TGA to (proper) DDS, then I think by default those that reskin should be using it; primarily for things like environment textures, as DDS will support mipmapping. May not be worth the trouble of any extra tweaking for one-offs or characters -- depends on the end quality, though.
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.
The issue with scripts is due to the OnEnter script injection process. It's problematic, if others use it as well, however, probably the better way to get "compatibility" with TSLRCM.
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.
I think TSLRCM could actually do a better job of supporting compatibility with other mods. For example, by making it easier for others to OnEnter inject their scripts and not interfere with TSLRCM.
Basically, you set up a script call to another script that does nothing other than include other scripts. You set this up for every module, even if they don't have an OnEnter script for the module -- you create one in such cases. Then if anyone wants to inject anything, they add their script include to this script for the module, and then add the script to the Override folder.
I agree wholeheartedly with this, VP! I'll work myself on fleshing out some guidelines and "best practices", but let's see what I can post here...
(I'm going to try focusing more on things that apply to both games)
5. Avoid Override Clutter
This one is rather simple: if it doesn't need to be there, don't put it there. The list of files that need to be in the override folder (or optionally sub-folders in KotOR 2's case) is as follows:
.2da, .mdl (and .mdx; the mdl and mdx files only need to be in the Override if they are not models that make up levels), tga*, dds*, and txi*
*These files most modders will install to the Override folder for ease-of-access. It's easier to get at the files here than extracting them from the level files...
Lastly on this rule, the only other time you should add a file of any type to the Override folder instead of the level file is when the file in question is or will be used in multiple levels without changes. Otherwise, the file should be added to the level itself.
6. If making new levels, make them friendly:
The game prioritizes the .mod level format and so uses it before using the .rim level format. Because of this, if you intend to let others use your level files, it's a lot nicer to use the the .rim format originally so that others can throw changes in a .mod file. This allows users of the newer copy to quickly uninstall the new changes if they desire. It also works great for testing a level, as you can use the .rim thing to "backup" a level at a point that you want to keep it before trying something different and are not sure if the changes will stay...
Some good points, however, not sure I entirely agree; especially where you should be putting certain files instead of the override. It's easy to make these rules if you've never worked on a large mod that deals with all sorts of models, textures and scripts -- among other things. This might make it easier for people to use a bunch of mods together -- kind of doubt it -- at the cost of making the modder's task far more difficult.
But, that is just my opinion.
7. More Polygons DOES NOT Equal a Good Model
Too often (at least in the old days), people will equate a large number of polygons with a better model. This is almost certainly not the case. A good modeler should be able to be efficient with the polygons that they use. Especially with KotOR and TSL, the smaller details will be better coming from a texture, not the model. I say that a good texture makes up for a poor model better than a good model makes up for a poor texture. Spend the extra time on the texture, and it will make a difference.
For instance, you do not need to model a 6,000 poly lightsaber. Nobody is going to see that detail. A 200-500 polygon lightsaber will be plenty detailed for KotOR and TSL. I'd say another general rule of thumb would be 500-1500 polygons for ranged weapons.
I agree. Can't remark on poly limits, as it really depends upon the model, however, it's clear that some folks need to spend more time learning the basics of low-poly modeling and UV mapping. But hey, from my experience, most mod users tend to not to even notice the difference.
8. Larger Texture Resolution DOES NOT Equal a Good Texture
Don't overcompensate with the texture either!! You don't need a 2048 x 2048 texture for that lightsaber either!! Nobody will be able to tell that it's larger than a 512 x 512 one. For just about any item, 512 x 512 or 1024 x 1024 will be a plenty large texture. Don't create larger files that aren't going to make a difference. If you use a 512 x 512 texture instead of a 2048 x 2048 texture, you're file size will be ONE SIXTEENTH!! That's a huge difference, and it will save space for those who download.
Very much agree. And I'm agreeing from a point of view regarding texture mods in general -- not just for KotOR / TSL.
Having said that, in the right context, 2048x2048 isn't a bad choice. However, 4096x4096 -- or worse, larger than this -- for these games is utterly pointless due to the engine...
I would also like to point out that when you modify any original image file, make sure you're grabbing it from the C pack. You always want to be editing the highest resolution version of the image.
Also a rule of thumb when it comes to texture sizes and what sizes to use:
Heads: 512x512
Weapons: 128x128 or 256x256 depending on the definition
Armors: 512x512
Placeables and Area Textures are the exception. These typically are really low resolution in-game and are in dire need of upscaling.
Obviously, never go smaller than the original size.
I'm going to suggest something different here:
Heads: 1024x1024
Weaps: 256x256 -- or 512x512 for new weaps; yes, there is a difference if you know what you're doing
Armors: 1024x1024
Items/Head-gear: 256x256 -- or possibly 512x512 for new models.
Inventory pics: 128x128
Creature: 1024x1024
Skybox: 2048x2048
Environ: 512x512 -- 1024x1024 for special cases
It really depends upon the skill of the modder when it comes to texturing for some of these. For example heads, you may be better off with 512x if you don't have advanced skills and can't make use of specularity properly. However, even so, you will find that there is a noticeable difference between a head using a (decent) texture resized from 1024x down to 512x.
The same is the case for "armor" or any body texture, like those for aliens / robots.
I might suggest higher for the skybox, however, either the renderer fails to display the extra detail or the textures are down-sampled as there is a size cap for these. Largest I can get to work, is 2048x and yes, there is a noticeable difference between it and 1024x.
Environment textures are funny, in that if you compared it to the minimum size for later games, then you might argue that 1024x is the best option. If you can get DDS to work correctly, this might be the best option, however, I find that the main issue with environment textures it that they are used all over the place at scales they weren't meant to be used at. The better option here is better model tools so that you can switch textures or reset the scale of those that are used for certain parts of the mesh.
However, so far I have stuck with 512x as there are a lot of environment textures and there would likely be negligible improvement in way of the environment by using anything larger. You are better off hex editing environment models to replace textures used at horrible scales with something else instead.
Anyway, that's my opinion on "best practice."
-
The only thing currently out of the question is 3D-Rendering, such as a Model Viewer and all that that entails (You'll still have to use GMax or 3DSMax for your modelling...)
You really should consider moving away from Perl, even if it is to something like Python. You would at least be able to do "3D" stuff that way I'd imagine; but honestly, you should take a good look at C#. Even if it is just playing around in Unity with it's version of C#.
Anyway, I say it as any "future" TSL modding will be reliant on better 3D tools -- exporting and viewing of.
EDIT: didn't you get C# source code for one of the model viewers floating around?
It's still worth a consideration at some point. Ideally (and this is FAR OFF in the future), I want to make a level editor with Unity where you would be able to add placeables and waypoints and all the sort.
Disclaimer: I have no idea how to do it yet, or if it's even possible.
That's interesting. You would need to do it will the full version as it will require specialised tools, like an importer/exporter for Unity -- that would require engine source-code assess. Would have been a problem to do with the free version, but now you should be able to score a pro license for cheap / free. Big shake-up with game dev middleware due to Epic making Unreal 4 pretty much free to develop with -- still royalties required for anything commercial. For those who don't venture that far beyond KoTOR/TSL modding
-
This may have been deliberately unanswered - but I thought I might bump this question. I am especially excited for the skybox!
After spending a hour reading this entire thread, there is some phenomenal work. I would be greatly disappointed, although understanding because IRL makes it hard, if it never got finished.
I have always liked other modders work, but this brings a whole new dimension to the 'vanilla' feel (which I liked when I played it 6 years ago), some 're-textures' can look a bit comical and out of place, so this mod is just amazeballs.
*insert whatever inspirational anecdote that might re kindle the passion*
Hmmm... Probably not
Though, seeing that some of you have discovered ReShade, I thought I might share some screens of it using MasterEffect:
Outdoors with a combination of effects running that I like, with my tweaked settings, and, depth-of-field:
DOF has issues with the HUD elements as that is not part of the depth buffer, but, I think I can fix it so that it doesn't affect static UI elements
Another screen with all the bells and whistles (I like) on showing DOF indoors as well:
This one is a relatively good one for bloom and the lens flare/dirt effect:
This one shows a good example of Screen Space Ambient Occlusion (SSAO), with Kreia's hair casting a shadow on her body -- there are "issues" with SSAO like the white edging with the hood:
Another shot for bloom and lens flare/dirt, this is using a custom texture:
That's from a while ago, since then I've been busy creating my own custom selection of shaders from MasterEffect and SweetFX; along with some new stuff. SweetFX in particular people have issues getting to work with OpenGL and 32bit games, resulting in a black screen. So far what I have ported to my version works accept for SMAA -- but, I think I've an idea of what's going wrong
Screens that have High Dynamic Range (HDR), Sharpen and Lens dirt -- this is my version that is not dependent upon the MasterEffect multi-pass bloom:
Better screen of the lens dirt effect, still a WIP as I think I can improve it more, but the idea is that most of the big lens "flares" are to the edges of the screen -- FYI: the snow is very bright due to the HDR and lack of corrective passes by other effects still to be ported:
The screens don't show everything, as I found that FXAA had almost nil positive effect and bloom was a little too much in combination with HDR -- especially without other corrective effects still to be ported.
EDIT: forgot to add that I brightened the screenshots as things look darker out of game; may affect things like contrasting details however.
-
Very sinister.
Thanks. Too bad the male Twi'lek voice is so the opposite of that; hands down, the worst voice to visual representation paring for the series IMO.
Every time one of the male Twi'leks in the game starts waffling on in that impotent and verging on aging-senility sumo-wrestler voice... I click as fast as I can
. -
What the hell, a quick run through for a Sith skin variant for Twi'lek males...
This one helps show off the Sith dark-side stained teeth:
-
Spent some time doing the other male Twi'lek textures...
Orange skin -- originally Komad for K1:
Purple skin -- originally Xor from K1:
Red skin -- originally Zhar from K1:
And the older male Twi'lek textures...
Yellow skin:
Aqua(ish) skin:
Lavender(ish) skin:
That last one is actually based on one of the original textures in the game but I've decided to replace with the aqua skin instead; leaving this one as an alternative. I kind of like the tail coloring on the tails of the others, kind of like a change in appearance that happens with age. The lavender-grey to me seems like I could re-work it to create a Sith appearance instead.
-
Final tests with the updated green tex again, albeit with some tweaks to make it more vibrant along with the other variants I've done...
And this last one should show more clearly the bump-specular effect to the textures...
-
Decided to do the alt textures for the (young-ish) male Twi'leks:
First is the blue...
Next is the orange...
Finally is the green again, albeit with some tweaks to make it more vibrant along with the others...
And this last one should show more clearly the bump-specular effect to the textures...
-
1
-
-
a couple interesting points i'd like to bring out,
keep in mind these are animateable as well as every other texture in game (other than particle textures, they are controlled by the model)
the controls i brought up from nwn in my first post are valid for use in kotor.
bumpyshinytexture is like a reverse envmap, ill explain in a diagram shortly, how ever it works with non-bumpmappable surfaces as well (with out bump mapping effect)
i'm gonna test out the acid texture in kotor, maybe we can get it to be valid and not crash the game.
the bump map effect (not bumpyshiny texture) is basically the same as bumpyshiny, but with a dynamically generated cubemap based n the light in a room and from what i can tell the aforementioned controls, this changes in every room and is noticeable with no smooth transition, in fact maybe its related to the rooms models as some rooms have two or more "hot-swaps" in them.
though this is for dx-8 it resembles eerily what we see in kotor
http://developer.download.nvidia.com/assets/gamedev/docs/AGDC__Per_Pixel_Shading.pdf
p.s.
SIC, that's the texture (acid one) that i had in mind
As far as I can tell these don't work:
isdiffusebumpmap 1isspecularbumpmap 1Only isbumpmap will work without throwing an error on load; you can use these with isbumpmap, however, that does not mean that they work only that the engine will ignore them if they don't work. As far as I can tell, they do nothing when used in conjunction with isbumpmap.
As far as bumpyshinytexture, it seems to work the same as envmaptexture when used in conjunction with bumpmaptexture.
And bumpmapscaling does work, how I'm not sure as it doesn't seem to work the same as I would expect from regular bump/height maps -- seems to make the effect wider than heigher.
I haven't used specularcolor but I suspect it will and will work along the lines I suspect.
Yeah, I think that what you can achieve with this will be limited as this seems to be more of a bumpy reflections implementation of bump mapping and not really normal mapping as you would expect it from modern games. Mainly good for things that are (hard and) reflective, with limited use for organic things -- especially as it only works with models that have existing bump map textures.
-
My current attempt. It's hard to see the bump/specular out of game with the screens, that's due to going for something more natural rather than strong.
The first uses my original bump map texture, skin specular sheen appears more pourous -- bit hard to tell when not seen in-game.
The second one uses an alt bump map resulting in a more glossy uniform sheen to the skin -- again, hard to see when not in-game.
-
OK, so I guess I couldn't help but "re-skin" the texture anyway; it's just to ugly to look at, the original texture and model I mean. They shouldn't of used the only male Twilek to appear in the movies as the reference for all the Twileks in the game.
The first uses my original bump map texture, skin specular sheen appears more pourous -- bit hard to tell when not seen in-game.
The second one uses an alt bump map resulting in a more glossy uniform sheen to the skin -- again, hard to see when not in-game.
As for the re-skin part, I altered the shading to the forehead bumps along with some eyebrow elements.
-
He said "re-skinning the texture", not every texture in the game. And "re-skin" does not mean "re-create", "re-do", or "create from scratch".
Wow, I think you've found your calling in life.
-
Looks good bringing more features out however, i think re-skinning the texture then applying a bump texture would also do wonders.
Feel free to re-skin all the textures of the game; I however, have better things to do than create everything from scratch, especially for a texture that is only used TWICE in TSL as far as I can tell
.My final work on the texture below, the bump/specular effect is more subtle as anything stronger looks weird when seen in-game and animated. Like a lot of things, what you can do is limited unless you want everything to look like glossy plastic.
-
Well, posted this already in this thread but thought it's worth posting here as well:
Kind of replacing the specular effect I was using/developing for characters with a bump/specular effect. This was a quick test to see what I could do with it -- once a few hiccups were overcome
.I also found some better ways of upscaling existing textures; if only I had discovered them earlier...
-
My own initial play with using "bump mapping" for characters:
-
1
-
-
the water bump maps are gray scale, for both games iirc. Personally I've only been testing tsl but I did find an interesting bump map, that wasn't like the normal maps or grey scale maps, it's the bump map for the frozen acid effect from naga shadows tomb, when I get on my PC I'll post the texture, which is present in both games. I think that directx is used for sound functionality iirc. Opengl does the rendering. A good easy to tell way to test the bump mapping is on the male twilek head, try making the diffuse texture's alpha all black, then replace the bump map texture with greyscale, or don't call it at all in the diffuse' txi. The difference is really noticible. With no bump map its super apparent.
Yeah, my comment about DirectX/OpenGL was more to do with Obsidian having made "improvements" to the engine; things like shaders.
Anyway, I realised what my issue was, I had created a test folder within another folder inside of Override. Forgot that TSL will look within folders found in the Override folder, but, won't actually look at any folders nested within those.
Seems to be working now, at least with the twilek_m01 set of textures. Looks like their normal map effect is heavily tied in with alpha and specular -- why the existing ones tend to look like shiny plastic. Still, probably can do some interesting things with it...
EDIT: if you mean the acid-ice texture set I think you mean (below) it does indeed appear to have what looks like to be a valid RGB normal map and not a grayscale image
-
Wouldn't this be better place in the "Tutorials" section of the "Kotor Modding" forum?
Just seems that this is something that might help some people and will likely get lost in time in the WIP thread :/
-
Yeah, I think that perhaps people are assuming it is easy to update these models files for areas; it's not as the tools available don't really support it -- from my experience.
What it really needs is new tools -- preferably not written in Perl -- though it requires a bit more knowledge of the model formats.
If I'm wrong about it, I would love to know how -- specific tools and steps involved -- as I'm sure would a lot of people. But, I think that sticking with dated tools written when much was not known about the various file formats, or much was available via the internet as is now, is NOT going to improve the situation for KoTOR/TSL modding
.
[WIP] SWTOR-Style Alien Player Heads (Nautolan, Kel Dor, etc.)
in Work In Progress
Posted
I'm at a bit of a loss. How does creating 4k textures actually translate into 4k textures in-game..?
Sure, the new steam update means that the game can support 4k resolution, however, that does not mean that the game's renderer can make use of 4k textures. Likely they will be down-sampled to something it can use, or, simply get lost in some other way. Meaning the end result isn't going to look all that much different if you simply used a texture that was 1024x1024.
EDIT: it's like the support of widescreen displays via the new steam update; sure, you can use widescreen resolutions, however, all the UI elements get stretched out. It's not a "complete" fix for the problem, just a patch of sorts.
I don't have any 4k displays, so, perhaps there is some big difference that is lost on me.
Anyway, like the head model. Nice to see some new and really interesting work.