|
Posted by SleepwalkR on 2013/03/01 18:37:12 |
Today I am releasing TrenchBroom 1.0 for Windows and Mac OS X. TrenchBroom is a modern cross-platform level editor for Quake.
Features
- True 3D editing, no 2D views required
- High performance renderer with support for huge maps
- Vertex editing with edge and face splitting
- Manipulation of multiple vertices at once (great for trisoup editing)
- Smart clip tool
- Move, rotate and flip brushes and entities
- Precise texture lock for all operations
- Smart entity property editors
- Graphical entity browser with drag and drop support
- Comprehensive texture application and manipulation tools
- Search and filter functions
- Unlimited undo and redo
- Point file support
- Automatic backup
- Support for .def and .fdg files, mods and multiple wad files
- Free (as in beer) and open source (GPLv3)
- Cross platform (Windows, Mac OS X and Linux supported)
Check out a video of TrenchBroom in action here.
You can download the editor here.
If you would like to give feedback, please do that in this thread. If you find a bug or have a feature suggestion, please submit them at the issue tracker.
If you are wondering where the Linux binaries are then sorry, but currently there are none. The Linux version has a few problems which I could not fix before this release. I will get working on those right away so that the Linux version should be available in a couple of weeks, too.
Finally, I would like to thank necros for all his work over the past year. Without his tireless efforts, TrenchBroom would simply not exist. Or it would suck.
Alright, enough of this. Have fun with the editor!
Update: 2.1 here:
https://github.com/kduske/TrenchBroom/releases/tag/v2.1.0-RC1
Features "cool shit". |
|
|
That's A Bug
Please file it on github.
OK
#2302 posted by Mugwump on 2016/09/23 07:29:19
Selecting And Editing All Brushes Within A Group?
When I double click on a group of brushes, I am able to select and edit the individual brushes within that group (e.g. by holding shift and extruding contiguous selected faces).
If I double click on a group and press Ctrl+A then it selects all of the brushes in the group, which is the behaviour I would expect. But then I don't seem to be able to edit the brushes in the same was if I had selected them manually. Is this intended behaviour?
No
Sounds like a bug.
Clipping Again
#2305 posted by anonymous user on 2016/09/24 01:18:18
When placing clip points in 3D view, could you add an option to trace/glue the points onto the selected brushes only (i.e. the ones about to be clipped). Currently, if there are any obstructing, non-selected brushes the clip points will instead glue to their surfaces, which is usually not desirable.
#2306 posted by muk on 2016/09/29 22:13:28
Im working on reproducing some vert manipulation errors and I'll add it to Pritchards issue report.
Basically, theres times I move verts with arrow keys and the verts deselect. I then have to select them again and can continue moving in my intended direction.
Additonally, "snap to integer" appear broken. Any attempt to "snap to integer" crashes.
This is all on 2f3c498.
A Follow-up...
#2307 posted by Mugwump on 2016/10/04 14:55:47
...to the conversation on the "best editor" thread:
SleepwalkR said: "You can select the axis yourself, it's the one you have moved the farthest distance on. Why is that difficult to handle? I'm asking out of genuine interest - maybe I can improve it?"
Maybe a better way would be to select either x or y axis beforehand with a simple toggle key like [ALT] does with the z axis?
All My Axes Live In Texas
#2308 posted by anonymous user on 2016/10/04 16:13:30
iirc you can hold shift to lock the axis you're moving the brush.
#2308
#2309 posted by sevin on 2016/10/04 16:24:13
That was mentioned in the best editor thread. That only applies once you've already begun moving the vert.
That's What I Meant
#2310 posted by Mugwump on 2016/10/04 17:37:51
Maybe instead of holding [SHIFT] AFTER you've started dragging a vertex, it would be best to have two different keys to select the axis BEFOREHAND, like for example [SHIFT] for the x axis and the >/< key next to it for the y axis. Or maybe even simplier and more intuitively, [X] and [Y] keys. The latter would imply using the [Z] key for z axis lock, freeing [ALT] for other context-sensitive manipulations. Sleep, does that sound good to you?
Hmm
#2311 posted by sevin on 2016/10/04 19:06:31
How about having a separate right-click functionality. You can keep free movement of vertices/edges on the left-click, but have right-click draw some axis arrows on the vert so you can click and drag on the axis you want to use.
Maybe a better way would be to select either x or y axis beforehand with a simple toggle key like [ALT] does with the z axis?
The problem is that it's very hard to select the correct axis that way. Either you make it relative to the camera, i.e., left/right and forward/backward, but then it becomes guesswork if the camera angle is close to a multiple of 45 degrees. Or you make it so that the keys are hard wired to a specific axis, (i.e., X locks to X axis always), but then you still have to take a moment and think about which axis you wanted to lock to. We already had that system in an earlier revision, and it did not work very well.
The current system allows you to select the lock axis by moving the mouse into the direction in which you want to go anyway. It's simply the best option IMO and I don't see why it shouldn't work.
You can keep free movement of vertices/edges on the left-click, but have right-click draw some axis arrows on the vert so you can click and drag on the axis you want to use.
Right click is already used for other purposes. What you're suggesting boils down to using a handle like many professional modeling tools do:
https://phoenixanimation.files.wordpress.com/2010/08/translate_handle1.png
We have toyed with this idea a couple of years ago, and it has its merits. But in the end I decided against it because it requires you to click into precise areas to select the axis of movement.
The system we have now is essentially liftet from SketchUp, and I think it is far superior to all of the above ideas. So far you guys have made suggestions how axis lock could be done, but you haven't mentioned any particular scenarios where the current system doesn't work, or I have missed it. What is the problem, apart from that you may be used to doing things differently from other programs?
Addendum
But in the end I decided against it because it requires you to click into precise areas to select the axis of movement and I wanted the user to be able to just click and drag on objects to move them. That was the main reason for the current system, and it's a big part of why TB is regarded as intuitive by many users.
Word Of Support
#2314 posted by mjb on 2016/10/04 19:59:02
Having basically only used TB and TB2 for my Quake editing needs, I can say I find the navigation, commands, and everything else work great! I actually only use the 3D view! (So far)
#2315 posted by sevin on 2016/10/04 20:07:02
I mentioned my problems in the other thread and I think you responded to it. When I try shaping brushes to match the curvature of, say, an arch texture, I have a lot of troubling getting an edge to slide along only the x-axis. In the current system, to reliably move an edge/vertex in the direction you want you must position the camera above the vertex so your viewing angle is large. But if you do that, then you usually can't see the texture you're trying to match in the first place. If I want to see the texture, I have to make the camera coplanar with the x-axis, which makes dragging something on the x-axis almost impossible. That's why we need lock functions. I think a bind to enable handles on a vertex/edge would be very useful.
#2314
#2316 posted by sevin on 2016/10/04 20:09:32
Providing constructive feedback is one of the definitions of supportive lol
Yeah
and I appreciate your feedback. My main objective is to make TB as easy to use as possible.
Can you post a screenshot of the situation you were describing in post 2315? I think I understand it, but I'm not sure.
Sleep
#2318 posted by Mugwump on 2016/10/04 20:40:06
[QUOTE]Or you make it so that the keys are hard wired to a specific axis, (i.e., X locks to X axis always), but then you still have to take a moment and think about which axis you wanted to lock to.[/QUOTE]
I don't see much difference between taking a moment to check the axis and taking a (possibly longer) moment to position the camera. The advantage of my solution is that holding [X], [Y] or [Z] seems more intuitive than the current system (which is already very good, as Bloughsburgh said) and it would solve Sevin's problem. I don't see how it wouldn't work very well.
On a side note, MWHEEL click+drag to position the view currently stops the camera panning when the cursor hits the screen borders. Would it be possible to make it continue infinitely?
Sure
#2319 posted by sevin on 2016/10/04 20:41:51
I'm not at home right now, but I will when I get back. If this clarifies any more, I'm just working with a vertical brush that I want to chop around a door texture. The situation I'm describing is when I'm trying to create the actual arch brushes. I'll make a video when I get home for you.
#2320 posted by Mugwump on 2016/10/04 20:42:20
Off-topic (sorry): How do you guys make your quotations white like that? I thought the [QUOTE] tag would do the trick but apparently not.
Mug
#2321 posted by sevin on 2016/10/04 20:44:37
Probably just using HTML color codes for it, not actually quotes.
Like This:
#2322 posted by anonymous user on 2016/10/04 21:10:23
<q >But without the spaces.</q >
Oh
#2323 posted by sevin on 2016/10/04 21:20:14
<q >But without the spaces.</q >
Cool.
Thanks #2322
#2324 posted by Mugwump on 2016/10/04 21:32:22
(whoever you are)
The advantage of my solution is that holding [X], [Y] or [Z] seems more intuitive than the current system (which is already very good, as Bloughsburgh said) and it would solve Sevin's problem. I don't see how it wouldn't work very well.
Well, maybe you don't see it, but it was tried and discarded for the very reason that it doesn't work. The argument that it may prevent you from having to reposition the camera does not hold for me because 1) expecting to not have to move the camera in a 3D view is unrealistic IMO and 2) you can use orbit mode to very quickly reposition the camera.
It looks like we'll have to agree to disagree. Or you can try if one of the older betas still contains the old axis locking (the first 2.0 beta might) and see for yourself why it doesn't work better than what we have now. Or maybe it works better for you, but I'm afraid that I'm not inclined to change it again.
On a side note, MWHEEL click+drag to position the view currently stops the camera panning when the cursor hits the screen borders. Would it be possible to make it continue infinitely?
That's a limitiation with wxWidgets on Windows and unfortunately there's nothing I can do about it.
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|