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 .map format isn't flexible enough to handle multi-plane rotations appropriately. It'll end up looking like the white bricks in the center here. Other map formats like Valve 220 can make it work. As long as the compilers support that map format (the Tx- ones do in this case), you can use it and it'll run in any engine. It's not possible in Netradiant, however.

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. 

And FYI, QuArK has the best texture tools any map editor has. 

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. 

http://www.quaketastic.com/files/single_player/maps/crater.zip 

Can't really think of anything apart from the floating point issues that quark does not do better than other editors... 

User interface? 

Follows intuitive Windows GUI experience. Have you ever tried the Radiants? 

Quarks interface described as "intuitive". I think that's a first... 

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. 

Is this thread turning into a level editor debate or something? 

It happens every time someone brings up QuArK. Spirit's trolling attempts prove sucessful once again. 

i am honestly not trolling.

I had to read tutorials before I could even place one brush in a radiant.

Faces in quark are selected by clicking the icon at a face (squares) or by clicking on the in the 3D view. Then I don't remember much but the properties are shown somewhere in the left panel. 

Radiant is driven mostly by keyboard shortcuts, those icons are apparently made by people who felt they were necessary for some reason.

Netradiant has a Help menu that lists the keyboard shortcuts. 

I was being unclear - that "multiple rows" remark was directed at Quark again. Radiant's UI is a bit better IMO, but also suffers from a lot of issues. But back when I was still mapping, I found Radiant to be much quicker, as in, I generally was able to map faster with Radiant than with WC or Quark. 

Quarl still the only intuitive for me :\ 

I stand corrected. I looked at the crater map provided by Preach and the 220 texture thing does indeed work in plain old Quake. Unfortunately it looks like Netradiant doesn't support it. 

http://i.imgur.com/E3rFS40.jpg 

http://quaketastic.com/files/screen_shots/ericw_wip.jpg

This is done in QuArK, but I've got to switch away from it - it's so slow.

AFAIK the vertical shearing I'm using on the sides of the staircase needs something other than vanilla quake .map, so it looks TB1 isn't an option for this map (I exported this as vanilla quake .map in QuArK, opened in TB, and the staircase sides are rotated instead of sheared):

http://quaketastic.com/files/screen_shots/ericw_wip_trenchbroom.jpg

Any suggestions? learn radiant for now? Or maybe the tilted wood panels look OK and I should stick to vanilla .map. :P

I noticed Tyrann's compile tools can read the Quake 2 .map format. Does anyone use that in combination with Radiant? I'm assuming the Q2 map format can handle arbitrary texture alignment?