If you include a small overlap between the two 256x256 textures and set the UV coordinates correctly, visible seams can be prevented entirely.
I'd still prefer very much if you released the pack for FM creators only and not as a package any FM player can install. It's already difficult enough to ensure that one's mission looks fine on most systems, and recent FMs are hitting the limits everwhere. Spitter used some of the upgraded objects in his FM Saints and Thieves, and I think it's way better if the author can decide what to upgrade and what not.
As arrogant as it might sound, I still prefer to be largely in charge how my mission looks on other machines without having to consider if anybody plays FMs with the upgraded objects installed or not.
I agree. Imagine if someone downloaded an FM after seeing screenshots full of replaced objects, only to find when they installed it that they could only see the originals.
I'd be pissed off if that happend to my FM because players would no doubt be dissapointed to find that it wasn't just a bug that the replacements weren't showing up.
Are you absolutely certain about this? Whenever I've tried to eliminate this artifact on very simple models (just two flat planes), I've never been able to. The UV mapping shouldn't matter, because the repeated pixels are taken from what's actually displayed. And overlapping doesn't help, since the pixel repetition happens on a per-polygon basis.Originally Posted by Eshaktaar
The only way I've been able to completely hide this artifact is to take an "if you can't beat 'em, join 'em" approach-- duplicate the bottom row of pixels from the topmost texture into the top row of the bottommost texture, and vice-versa.
That's what I meant with the small overlap. If you place two textures on top of each other, the bottom of the upper texture needs to have one or two pixel rows of the lower texture's top (or vice versa). This allows you to adjust the UV mapping of both textures a little so they end where they are supposed to meet.
Hey is there a place to just download everything thats been done so far so I can use this stuff in the original Thief 1/2 missions?
Ah, okay. I thought you were saying there was a solution that didn't require dinking with the texture data.
Sounds like a complicated explanation for what's called "seamless textures".
yes, where are some of these objects currently, i'd like the switches and things for my mission.
Seamless textures are generally tiled. What we're talking about here is how to work around Dark's rendering behavior when juxtaposing different textures.Sounds like a complicated explanation for what's called "seamless textures".
As things stand, there is no practical solution other than that. This whole thing comes about due to a fundamental 'flaw' with the graphics pipeline. Namely that the hardware does not have access to a polygon's neighbours at rasterisation time, so it filters the current polygon's edges against its own opposing ones, for lack of anything better. Now, there is an extension that solves this completely, the only problem is that it was introduced some time after these games were made.
I entirely agree with Eshaktaar and R Soul about the installation of the object package.
Besides what they already said, I also have a palette problem, I hit the limit for the second time now and since I have lots of custom objects and paintings, I had to create my own grouped palettes.
i understand lady r's problem too, all my objects share a lot of palettes, i have two texture families with the same palette, they are different texture types entirely and separate families is a management thing, i won't need more than about 12 families total i don't think anyway. my question is, just because we can texture the door with 2 stacked 256x256 textures, should we? thats a 512x256 texture on a 4x8 door, thats a lot, by my understanding of textures the door at that size should look fine with a 256x128 texture on it, t2 used 128x64 textures for "high" quality 4x8 doors, many doors used 64x32 textures, which look crappy, this is four times as large as it needs to be, and smacks of a, "why not do it if i can" attitude. can and should are different things.
Why? Because the entire point of the exercise to make Thief's objects look as good as this antique engine can possibly manage. By modern standards, a 256-pixel-wide texture isn't considered particularly high-res at all.
Plus, you have to consider that in Thief (or any FPS for that matter), doors are the objects most likely to fill the player's screen. They need all the resolution they can get. Heck, it might even be worth the effort to model some real surface detail into these doors.
I totally agree. Some of my old mission had this palette problem too. And I really don't want to test through all my fms again, just to see how it looks or if it crashes.
so by your logic zylon i should split the door into even smaller parts, maybe 8 squares and make each a 256x256 texture for a total of or 2048x1024 or something, that would be some super detail. what good is a door at 256x512 when its sitting next to a tiled 64x64 default texture at scale 16 that looks like garbage?
Ah, ok, I misunderstood. I thought you were talking about using the same texture, but twice, so you retain higher quality.
The limits are something to consider seriously, I think. What happens if a player has already downloaded many custom objects and textures? If your mission is pushing the game to its max, then the mission won't even run, will it? For example: Your mission is at maximum palettes, but the player happens to have their own custom doors skins, footlocker models/skins, etc... Could this end up being a problem? I'm not quite sure about how this all works, since I don't build FM's and have never seen "max palettes reached" errors.
Based on the discussion here and in other threads, it seems like it will be flat-out impossible to create a mod package which can upgrade the graphics in all FMs without unpredictably conflicting with other custom objects.
I'm guessing the final solution will be to create a unified pack that upgrades the OMs only, then make the individual objects available to FM makers on an a la carte basis.
I agree with OttoJ on the scale issue. I don't believe there is a point in trying to achieve modern levels of texture detail on otherwise ordinary objects - there is a happy medium that will fit in with the rest of the Thief artwork, and I don't think "as good as the engine can possibly manage" is a very good goal if the rest of the visual design is going to be woefully inconsistent with the handful of super-high-res objects.
In my opinion 256x128 for a door is plenty (not to mention neatly avoiding the seam problem) - it's what you *do* with those pixels that counts. Quality over quantity in other words. Plus effort should be put into improving the door meshes themselves as well as the textures.
Okay, maybe I'm being arrogant now, but I had somehow assumed that once people had seen the improved objects, no one would want to see the original ones again - I know I certainly don't!
The only thing I was worried about was the new objects interfering with semi-custom objects and overloading palette limits in existing missions; I had never considered that people might want to see the originals.
And I had assumed that no new FMs would be incompatible, since any authors with enough custom resources to touch the palette limits would surely be using the pack.
I was recently(ish) playing R Soul's excellent mission, 'All Torc', and at one point I happened to look at an electric wall light, noticed that it wasn't using Vigil's improved lantern textures (which I felt it should have been), and immediately saved, quit, and had to mess around with the files to get those textures back in there. You may tell me I'm crazy at this point.
I had assumed that people would sort this the same way SS2 authors work with SSHTUP, namely by including all the improved models and textures they've used in the FM archive.
On the other hand, I could see this annoying people with slower computers/graphics cards, so perhaps the better solution might be to simply include a line in the readme telling players to grab the Enhancement Pack if they haven't already.
Only 'Curse of the Falcon'; the rest of your FMs work fine and look much better with the pack installed.
In any case, I was thinking of writing a 'generic FM patcher' program to poke around inside all the zip files in a folder and make minor changes to the palettes of certain textures (particularly mine) in order to reduce the total number of palettes and allow the FM to be played with the EP. The patcher would also look for potential miss-matched objects/textures, and try to repair those too (probably by inserting a copy of the original models into the archive). The program could also be taught to fill an FM with original objects to override the EP if that was desired.
My idea was to have a list of files to look out for, and a list of actions to perform if a particular one is found; as such, I could look in the archive for Bequest.txt (for example) and, if found, insert all the original models into the archive.
I'm not sure what FM authors would think about this program poking around in their FM archives, though.
Another idea might be to make the program plug into GarrettLoader, and analyse and modify the files after extraction. This would mean that it would only work for people using GL though.
That's not really possible without modifying all the objects in the OMs to use custom models. Placing the EP into the Obj.crf in the root of the Thief folder (not in Res) would mean that the objects would be used only if the Obj folder doesn't exist, but what if someone has some other enhancement installed (such as Targa's bowsites)?
"This pack is for use in Original Missions only; although it greatly improves most FMs too, do not use it with them."
Basically, it's a mess. If I had made this years ago, before there were many FMs, then things would be different, but as it is there are just too many FMs for it to ever work with them all. I can only see two viable solutions:
a) Write the patcher program and release it with the Enhancement Pack; it will mean that people need to modify some FMs before they can play them, which might not be appreciated by FM authors.
b) Only release the objects for FM authors and not for players (even for those playing OMs). Of course, I would still be using them when I play FMs - whether other people use them or not doesn't really affect me anyhow.
I've removed some of the white patches and lightened the texture slightly, I'll just re-render all the door textures and see how they come out.
I think I'll stick with 256x128 for now; I have higher-resolution originals if I feel like upgrading them more later, but I think it might be a good idea to see what impact even 256x128 textures have on different people's computers before I think about going higher. I had idly considered the idea of another 'insane detail' Enhancement Pack, using even more detailed models (up to 1500 polys) and much higher resolution textures.
Note also that using two 256x256 textures will break any door in an FM which should be using a custom texture without a custom door model.
Oh, and I have been improving the doors, making parts of them recessed or raised, and rounding the doorhandles. Only the metal and Victorian doors so far.
Eshaktaar just gave a link to his switches a few posts ago. As for the others... I just sent another beta to Jason (without the demo mission this time), I'll post a link once he has it up.
Vigil: I was going to include your 'sea chest' model, but I see now that it's not a drop-in replacement, mainly because the original object is off-centre for some reason, and also because it's not quite the same size. I know the model names are different to stop it overriding the original, but you could consider tweaking it a little to make them interchangable.
What about if I have my own replacements for some objects? Just to make an example: I made a new texture for the fancy bed, will the EP override it if it has the same name?
What am I to do if I don't like some objects of the EP to prevent the replacement? I know, they are beautiful,
Already in this thread there are several occasions where people disagree over whether some of the replacements are really improvements or just "different" from the originals. An FM author might prefer not to use my switches in their mission, because they disagree with the artistic liberties I took.
If players have the upgrade installed, the author would basically have to repackage the old stuff or write "please don't use the upgrade pack for this mission, thanks!" somewhere in the readme.
To be quite honest, and on the risk of sounding arrogant again, for a few of the replacements that are already in the pack I'd rather prefer the old objects.
*ducks away to avoid being hit by various rotten fruit and vegetables*
Hmm, I don't think it's really that big of an issue, is it? The only real problem I see is the number of palettes limit.
The way I envisioned this being used is this:
All the objects in your EP use the same exact names as the originals, therefore they override the original crappy models and textures. Thus, a player simply needs to use Darkloader or GL to return T2 to its original state, unzip into the appropriate folders (and choosing whether or not to overwrite any of their existing models, as you say, like my bowsite.bin). When installing FM's via Darkloader (and probably GL also), the program will not overwrite a file if it already exists, and will not delete it when the FM is uninstalled.
FM authors should have been aware of this for years (that players may have their own objects or skins), and should be creating their custom gamesys with objects and AI that don't use the default names, renaming the models if necessary when adding them to their FM's. Thus, there won't be any naming conflicts between the EP objects and an authors custom objects. Duplicates can happen, but that's really not an issue. If a player has a custom footlocker object and skins overriding the default, and an FM uses the same model but has it named "lockerfoot.bin", lockerfoot will be in the mission, not footlocker.
So the only real issue that I can see is that because of the size of the EP, attempting to play an FM that is at or near the palette limit will probably push the game past the palette limit. In this case, the readme for the EP should state that if a player experiences a problem, they should uninstall for the duration of the FM. Which only leaves the problem of an easy-to-use installer/uninstaller, which could be as simple as a batch rename. You wouldn't want to delete files, because if a player has their own custom object with the same name as one in the EP, and chose not to overwrite it during EP installation, you'd end up deleting their object.
Am I missing something? Seems simple enough to me.
In response to the last couple of posts:
You really can't control "what you like and don't like" versus what the player decides they like and want to have installed on their computer. Players can be made aware that they may be missing out on some textures/objects that they may or may not think look better than the EP objects, but that's about it. You can't try to force people to use only the objects and textures that you decide should be used in a mission, because they fit in with your "artistic vision".
If authors spend several years creating an FM I think it's only fair to let them the last say about how their mission looks.
Sorry Targa, I can't disagree more. It's MY mission and I want to have the control of what goes in it.
The player chose to play the game which comes with its original objects, textures etc. If something has to be changed, I want to decide what to change, at least in my mission.
Nothing personal, of course.
Posting Permissions
Reply With Quote