 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
A lot of the textures are just cut and paste, highly modified versions of the standard id textures.
The stone textures are modified versions of the zstn3 set (I think) from Kell's Apocrypha wad. The brick textures are based on a couple of full color jpgs from a site called Spiral Graphics. I had to modify them a lot to work in Quake, and I created nearly two dozen unique variations just for this map. (Just in case, BTW), I wasn't disagreeing with you or anything, as a matter of fact I pretty much agree 100%, I was just trying to point out that Quake is pretty unfriendly with regard to texture alignment when it comes to oddball brush orientation.
I actually went to a lot of trouble rotating that tower and even though the effect is subtle, I like it a lot. You need to use an editor with proper texture locking. Build it on axis and then rotate it later. Should save you a lot of pain...
The problem with funky rotations was older compilers which lacked support for floating point rotation of textures, or not being consistent with editors when to switch between projection planes when dealing with 45 degree surfaces.
Quake itself has no issues as long as the information in the while, some/many of the old compilers would flip rotations or planes or both, that's not exactly what I see.
As far as I can tell, it (Quake) always seems to project directly on axis (90 degree angles), never at 45 degree angles or anything else for that matter. When a surface is exactly vertical, simple scaling will usually fix any horizontal texture distortion, but once the surface is tilted 45 degrees away from vertical it becomes hopeless. The texture projection is entirely up to the compiler. If you feed a standard map file to a modern compiler, it will however use the paraxial texture projection which you are seeing.
If you want more control over texture projection, you will need to use an editor that writes and supports Valve's 220 map file format, which basically allows you to set up the texture projection in whichever way you like. TB doesn't support this yet, but it's planned for TB 2.0 (I think you are using TB?). OTOH, there are many examples of Quake maps with paraxial texture projection which have proper texture alignment on rotated objects, but it's tricky. Hi all, I realize this is mostly me just ranting, but could you please be more clear when you decide to discuss non-standard Quake stuff. I'm really tired of these cases where someone says "Oh, yeah, you can do that", then, after wasting much time, I find out that, well no, you have to use this, or do that, or something else, and no it's not really possible in standard Quake, or it pretty much won't work in regular old Quake.
It's not that I don't find the information useful, but at the moment, I'm not interested in mapping for any other game besides Quake. I probably wouldn't be here if I was. This site is pretty much the last Bastion of old school Quake mapping info. I sure hope it sticks around. OTOH, there are many examples of Quake maps with paraxial texture projection which have proper texture alignment on rotated objects, but it's tricky.
This is not entirely true though because when a face is off-axis on more than 1 axis, then the texture projection creates a skewed texture which is impossible to align no matter what is done. I'm really tired of these cases where someone says "Oh, yeah, you can do that", then, after wasting much time, I find out that, well no, you have to use this, or do that, or something else, and no it's not really possible in standard Quake, or it pretty much won't work in regular old Quake.
As a frequent advocate for the benefits of backwards compatibililty, I can assure you that you can create maps that take advantage of these new features that still run in the original winquake engine. You need a new compiler, that's all. The texture alignment problems are not a compiler issue. This is the way Quake normally works.
Necros has very clearly (thank you) re-stated the issue in post #103374 when a face is off-axis on more than 1 axis, then the texture projection creates a skewed texture which is impossible to align no matter what is done. Again, if anyone has a fix for this in vanilla Quake, please share. However, I'm pretty sure it's not possible. For the record, I'm not about to incorporate some weird Valve texture alignments in a Quake map or be forced to recommend a "not really Quake" engine to play one I make. That's just the way it is. Also please note, I was not complaining about this or asking for a fix. I was simply responding to a prior post in order to point out the difficulties and problems faced when surfaces are significantly off-axis in Quake. BTW, I use txqbsp_xt. I think it's a whole year old. The only newer one I'm aware of is in tyrutils v.14 and that one has marksurfaces issues. The editor I use is Netradiant, the only one I know of newer is Trenchbroom. From what I see, these newer compilers and editors are still experimental and buggy. Surely that's not recommended? Also, I still stand by what I said in my previous post. Please be clear if something you recommend either will not work in, or has not been tested in, vanilla Quake. It may save others from wasting time. This is not an engine problem. The engine doesn't care how textures are projected - the appropriate information is generated by the compiler. You can "fix" the problems by switching to an editor that fully supports Valve's 220 map format, which was invented to solve exactly this problem. Most recent compilers will understand the 220 map format and generate proper texture coordinates for your map file.
The problem is that you need to find an editor that supports this map format. I don't know if Netradiant does. All this will work great in vanilla Quake - it's all about the tool chain in this case. necros' post only pertains to the paraxial texture projection which is used for standard Quake map files. It has nothing to do with vanilla Quake. It's just that the standard
There are no simple workarounds; it's needs a lot of experimentation and manual fiddling. I found that sometimes it's beneficial to change the shape of the brush/face ever so slightly in order to make the texture fit better, rather than trying to fix it by means of aligning. It usually won't be visible if it's just one or two units. Though often textures on multi-axis faces (at least those with only one spacial definition, e.g. horizontal seams) can be aligned neatly even without floating point offsets by changing the scale on the particular axis in very small increments. An example for this would be the trim inside the window frames on the roofcony in mce.bsp. But it's a pain in the ass, indeed. allow better texture alignment, Rick.
I don't use worldcraft because Trenchbroom is fun to use, though aligning textures is more problematic. Despite its excentric appearance it has the potential to get things done. But you really got to know how to handle it, otherwise it'll refuse to cooperate and the whole thing will end in frustration.
Can't really think of anything apart from the floating point issues that quark does not do better than other editors...
Also, Radiant is not much better. I mean - multiple rows of toolbar buttons with random icons? Seriously, whenever I use Quark to check something out that doesn't work properly in TB I'm at a loss. I don't even know where to begin just to select a face and see its properties, for example.
I'd guess that the Jackhammer editor supports the 220 format, from the way they describe their texture features. Haven't tried it myself though.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |