Does it try to blend blend pixels with next pixels.. if I offset it by 1 it is already in beginning, so it tries to blend with those pixels? 

What I did when making a series of similar textures was to create one common frame to use for all. Basically just the outer 1 pixel border of a 64x64 square. I used that to make different variations where the middle part was different but the pixels around all four edges are exactly the same for all.

For 128x128, I just repeated the 64x64 frame. Textures made this way have no GL filter seam/line as long as they meet at the 64 unit boundaries.

To make sure no weird texture alignments happen, I never use texture lock. I only turn it on if I really need it. 

I thought we would have moved on from GL filtering as a society by now. Horrible concept really. Yay filtering. Let's blur all the textures. No glasses for you and contacts thrown away for you and baske in the glory that is nearsightedness on a screen.

</endrant>
(P.S. I'm nearly blind and need powerful contacts so I may be biased.)

Also this blending is not a compiler issue. The adjacent face has a different texture alignment and therefore is split into a separate face for blending purposes but thats the extent of compiler related. 

I might have used texture lock too much.. sometimes it was just left pressed down. Checking something like that multiple times, especially when placing lamps and such things confuses a bit.

I must be weird, because in some cases I want to have more control over things how wide/high some brushes should be.. and if there is only texture available that is 32x32 for example, but I want it to be 16x32 or 32x16 I have to cut it and offset other half so 'borders' are in right place. Creating new textures sounds like, I would probably fail at trying, I'm not an 2d artist by any mean. 

You could split an existing texture in two halves in PhotoShop, then use them in your maps. This way you wouldn't have to offset your textures, which can be tedious. 

Just make the road so there's three brushes across the width instead of just two. 

Thanks Kinn, but I also tried out.. scaling up a bit and it worked. But if I need to do wider roads.. then I need to use your advice. 

don't worry, Linux package management just sucks..
what's the error?
I have hit the same thing on debian/ubuntu before, there's some magic flag to make apt-get work usually. also maybe we should move this to the OS thread...?

Thanks for being willing to look at it.

Initially when I typed "cmake .. -DCMAKE_BUILD_TYPE=Release" from within a newly created "build" directory as per the instructions that come with tyrutils-ericw, I was told that I had to install cmake using apt-get ... which I did, and then weird things happened.*

I thought the installation of cmake failed, because I still could not get the build process to work. I had another look, though, and it seems like the installation did work, but I need a higher version of cmake than the one that is in my OS's repositories:

cmake .. -DCMAKE_BUILD_TYPE=Release
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
CMake 3.1 or higher is required. You are running version 2.8.12.2


-- Configuring incomplete, errors occurred!


...which means I need to compile cmake from source, I guess?

*If you're interested, I can post the weird stuff that happened too. Basically, as soon as I typed "sudo apt-get install cmake", the terminal window was taken over by the drupal configuration/installation process, which keeps failing. This happens whenever I type "sudo apt-get install cmake" again. 

OK, the problem is on my end; I thought I supported Ubuntu 14.04 but mixed up which cmake version it had. I'll see if I can adjust the cmake script and report back.. 

Ok, I made some changes and updated the instructions for Ubuntu 14.04 x86_64:
https://github.com/ericwa/tyrutils-ericw#ubuntu-1404

If you are running 32-bit there will be more work to do but it should be possible as well 

https://github.com/ericwa/tyrutils-ericw#ubuntu-1404-x86_64 

Not sure this is a bug, since it look deliberate in the code, but it would be interesting to know why. :) It treats any argument that begins with a '-' or with a '/' as a switch. Absolute path (linux), including relative to home, will begin with '/'.

Anyhow. It was an easy fix and the tools are awesome. 

Thank you! Will check it out and report back. Luckily I'm running 64 bit on my current primary computer. 

Thanks, those instructions worked. :)

Now I just need to gather enough courage (and set aside enough time in case of repeated failure) to attempt building TB2 as per your instructions, and I'll be back in business. 

 

How are you guys going about finding leaks using netradiant and qbsp/txqbsp? Specifically looking to find the "Detail Nodes facing the Void". I can use q3map2 to find normal entity leaks, but it doesn't work for func_stuff. Is there an easier way than hunting through the map seams? 

The main idea is to use the pointfiles (mapname.pts) output by qbsp/txqbsp. The quake engine can load them with the "pointfile" command. I use Trenchbroom to load them.

re: "Detail Nodes facing the Void" warning, this is unique to how func_detail was integrated into Quake tools. It's not the same as a leak.. as far as I know, the only problem that warning can cause is reduced vis quality (the fact that this is an issue at all may be a bug in vis, not sure.)

To avoid the warning: having world brushes seal in the func_detail is not good enough, because detail clips away world, and the warning happens after the CSG phase when every brush is clipped against every other one. You want to ensure there are some non-detail *faces* left in the final bsp (what you see in-engine) that, if you extend the planes they are on, enclose all of the detail faces.

e.g. if you have an outdoor area where the entire floor is detail, I think you will get that warning 

So, I did some experimenting and func_detail can actually be used to seal the map. Um...what?? Also, func_detail brushes are still being used to slice up the space into more and more leafs. Again...huh?? So func_detail is essentially worthless except to speed up vis then? I could use func_wall to save on leafs and not worry about leaks mysteriously showing up when I hide the (leak would be there anyway).

I thought the point of func_detail was to not affect vis, like, at all. No leafs added, no slicing other brushes. Is it possible for func_detail to work like in Source: https://developer.valvesoftware.com/wiki/Func_detail 

func_detail will always cut up brushes. It's sole purpose is to speed up vis. 

Assuming latest ericw tools are used, what are the downsides of using buttloads of func_wall in place of func_detail? 

func_wall lighting might get a bit funky. You'd have to remember to include things like _shadows and _dirt etc.
That's the thing I can think of mostly being affected. 

The other issue with using brush entities is that you are contributing to the entity count. If you're trying to stay under 255 ents for extra compatibility I guess then it's better to stick with func_detail. 

func_wall downsides:
- counts towards entity limits (I guess they are probably static ents?)
- likely will have overdraw?
- they can have different rendering performance quirks depending on the engine (and how well the GL driver optimizes what the engine is doing).

Quakespasm: there is some setup cost per-func_wall rendered, but they use the same drawing code as the world, so they can have lots of faces and still render fast

Fitz085 and I believe MarkV use R_DrawSequentialPoly which scales badly on funcs with lots of faces 

Also, func_detail needs to create leafs, otherwise collision wouldn't work, rendering might break depending on the engine. The engine needs to have been designed with func_detail in mind to support not creating leaves (q2/q3/source?). 

Ok. On a related note, can func_wall have keys added to receive and block lighting identically to a func_detail.