You must use the master branch for the Linux version, it has a lot of fixes. The 1.0.5 branch is pretty much broken on Linux. 

ok, so there is no depth buffer it seems. The wireframe of all brushes is always visible - even when there are other brushes obscuring it, unlike in the windows version, and if I do a simple test with three brushes, it's obvious there is no depth culling. This is probably down to my shitty video card, the drivers or some combination of the two, and I don't expect you to fix it since TrenchBroom is just a personal project and fixing shit like that for one guy running on a Linux notebook from 2007/2008 is not of the upmost importance. Still, if you have any idea what the cause might be, it would be good to know. 

ok, I'll try that and see if it works. 

That's odd, but it could very well be a bug in how I am detecting the available pixel formats on Linux. I'll look into this, so keep that laptop around ;-) 

I am pulling direct from the master now and there are no differences with regard to bugginess on my machine.

I'm kind of done with this for today, but tomorrow or perhaps Tuesday I'll try and get it running on my Ubuntu machine and also use my experience from today to get it building with Code:: Blocks on Windows (I hope).

Ideally I'd love to have it running flawlessly on Linux, but I'll be happy to get the Windows version building so I can try adding new features. 

The menu issues are still there on the master branch? 

At least on Linux Mint Mate. Not sure if it's just an issue related to my specific setup.

Load TrenchBroom
Click on any menu (the file menu for instance)

The menu should appear then quickly disappear. The entire GUI is completely unresponsive after that and I have to kill the process to get rid of it :/ 

I fixed the errors with the hexen2.def file I had.

Fixed hexen2.def
Download: https://docs.google.com/file/d/0B0piElswxauhbnZJQ2Q2WGxHUDg/edit

Errors/fixes were:
1) Removed first 5 lines(a custom comment).
2) Search & Replace all " / " with "/"
3) Search & Replace all lines that tail: ") ?", and replace that tail with ")"

These fixes were based off the error messages I received in the console log of TrenchBroom. Thanks to the log messages, I was able to fix these manually myself.

It loads fine, and I get hexen2 entities now.

Models:
However, it's not loading the models. I tried renaming my hexen2 /data1/ folder to /id1/, because it has same pak files, and the pak files have same file structure. But, I couldn't get this to work.

Textures:
I could not get it working. TrenchBroom won't load the hexen2tx.wad file I downloaded from:
http://www.realm667.com/index.php/texture-stock-mainmenu-152/1090-hexen-ii-texture-pack?catid=56%3Aheretic--hexen-style

---

Perhaps these issues are side-effects from the fact that the hexen2 is a custom quake1 engine. 

Alright, I'm done with TrenchBroom for now.

I can't use it effectively unless I have grid information. Bit I have no grid information--all the opengl text is garbled--and I have no grid view or grid anything to look at for measurements.

I understand the editor is to be seamless flow for a mapper, but I prefer to be accurate and I always work with grid information and grid numbers, and a flat grid view.

Thanks, 

Hello deqer,

I suspect that it's not loading the models since they have a customized MDL format for Hexen 2. For each games meshes to show up Trenchbroom would need to have a custom loader for the various MDL, MD2, MD3 and so on.

Cheers 

Really nice! It's like Blender but with brushes...hmmm...hopefully there will be ample hotkey customization.

This looks and feels incredible! Fluid views, oldstyle graphics(not gl blurred! :) ), Brush splitting!! Amazing. Simply amazing.

However, I have noticed one minor issue. Texture application takes a while...about 2-3 to do any change to the texture. I have Nvidia driver 306.97, though I haven't noticed any issues with it, though perhaps it has something to do with having multiple monitors. It does slow down my texturing process a lot.

Anyways its great so far! Keep it up! 

Grid snap does't snap to the global grid! It's local. Instead of moving a face to the next gridline it just moves it the current grid distance. For example, if a face whose global X-value is 32 is moved 2 units to 30, then when switching back to any other grid size like, say, 16 then the X-value would go from 30 to 14, not 30 to 16 which is how other editors work. Is there a setting for this? 

I disabled and then reenabled one of my monitors and it fixed the slow texturing problem. Wierd. Just FYI. 

grid snapping to offsets is intentional. Force a vertex to snap to grid by holding shift while you move a vertex.
Not forcing the snap lets you do more such as work at large grid sizes without loosing small details. 

It is a spectacular editor though. The best feature is the texture rendering in 3d view, and texture management in general. I also like the grid lines on the brushes, and the extending helper grid lines when selecting a brush.

I will use 3d view a lot. But, I also use flat grid view just as much. Please provide grid view or something equivalent. 

Hello SleepwalkR,

Do you think its possible to add a world center and limits info to the 3d viewport? It would be most helpful in figuring out the center and maximum boundaries of the level. Some form of coordinate system that has a 3d grid which fades out after a set distance which can be turned on and off? That way folks that like a grid or none at all will live happy ever after. For me its good to get my bearings.

Otherwise loving this. 

add the name of the level and things in TrenchBroom? 

it took me until now recognise the origin of your nick, I should read more!

add a "name" field to the worldspawn. 

Showing where the center is and where the world ends has been requested by others. I'm still thinking about how to do it without cluttering the view port. Maybe it can be combined with a way to give people more orientation and a better idea of the relative position of objects. 

Compiled on my main pc running Ubuntu 12.10. Had some minor troubles during compilation, but fixed and it runs just fine as far as I can tell (not tested extensively yet, however).

Everything is working fine, but wxWidgets setup.h seems to redefine SIZEOF_LONG as 8, where it has already been defined in freetype. Commented out the highlighted line and it compiled without issues.

The z-buffer is working fine:
Renderer info: GeForce GTX 560 Ti/PCIe/SSE2 version 4.2.0 NVIDIA 304.51 from NVIDIA Corporation
Depth buffer bits: 24
Multisampling disabled
OpenGL instancing enabled 

It might be good to have some goto brush and/or world position tools in there to help find and eliminate problems. I guess that can easily be tied into the map explorer when you are doing that? 

Cool. Still annoying that it doesn't work correctly on Mint though. Which edition / desktop are you using on your Mint machine?

I'm aware of the SIZEOF_LONG issue, I have to do some include trickery to get around it. It's on my todo list.

Goto brush is on the todo list also ;-). Necros keeps asking for it. 

This editor really needs a cut tool. Lets say I want to remove a small area in a wall that is shaped like a box. It would be nice if you could put a brush into that area and then have the area occupied by the brush removed. 

I plan to add some CSG operations (most importantly CSG merge), but CSG subtract (or "cut" as you call it) is not among those. The reason is that it is very hard to make the subtract operation create "optimal" brushwork. Here, optimal means brushwork that creates a minimal amount of plane cuts when run through QBSP.

AFAIK, the general consensus is to stay away from CSG subtract operations because of this. And that's why I'm not going to add it to TrenchBroom. 

What's with that video - 'How to make a spiral staircase with Trenchbroom'. Basically - 'Use Quest'? Seems a little counter-intuitive.