What do you dislike about Hammer?

[Earl]

I agree with you, transformation gizmos/widgets/manipulators would be very useful, especially in the 3D view. These tools are common to almost every 3D app I've used. Being able to use a manipulator on textures (along 2 axies) and displacements would also be very handy.

The other features I wish Hammer had are the free drag resize, create room, and selecting setup from DarkRadiant (open-source fork of the GTK/Qe Radiant level editor made for Doom 3 mods). In radaint, you use Shift+LeftMouseButton to change the selection, this helps prevent accidentally changing the selection off the object you're working with due to a misplaced left click.

Something like that is exactly what I'm talking about.

 

[Brandished]

Well hammer really hasn't changed much in a decade, so it's no surprise that newer map editors run circles around it. I guess that's why I've taken on this project.

I only recently started looking through some publications I found digging around the QuArK forums a year or two ago documenting the layout of the original ".MAP" format for Quake 1.
http://www.gamers.org/dEngine/quake/QDP/qmapspec.html

It really surprised me just to see how much of the old, 1996, Quake 1 game design aspects have remained inside the Source Engine and the vmf file format to this day. It's been 13+ years, 5 game engine updates (hl1, hl2, ep1, ob, l4d), and 2 updates to the compile script (map > rmf > vmf) and so many things haven't changed much, if at all.

Something like that is exactly what I'm talking about.

Heh, glad I could be of some assistance. Right after I hit send, I think I did one quick edit then went to go run some errands, I didn't see all the other replies that came in ahead of mine until a few minutes ago. I spent too much time creating those GIFs, although they really do help convey the idea.

 

[zornor]

A quick idea on the in-editor arrows or whatever:
By default clicking and dragging on the arrows will move it.
But Shift+Clicking will scale it.
Alt+Clicking will rotate it (by increments of 15 degrees by DEFAULT for the love of god, at least in 3d view D

You'll just have to remember to make it so you can't rotate and scale at the same time. I've seen editors that overlooked that, results were not good.

 

[grazr]

The first and second manipulation to your cuboid Brandished (scaling and movement) can be achieved using the vertex manipultor in the 3-D view by selecting either the yellow or white vertices, specific to the movement/manipulation you desire.

Unfortunately.. rotation is still restricted to the grid, and i admit this is a somewhat fiddly task as you need to position your camera along a certain axis to avoid accidently pulling your object along the wrong axis.

 

[(s2a) yahodahan]

Earl- thanks for the detailed response to my extremely lengthy post! Obviously I am not a coder, just an art guy who likes to muck with engines too, but doesn't truly understand their deepest inner workings- I openly admit to that!

However, in my opinion, it is the true purpose of a good engine to pander to the artist, and no longer to the programmer- at least not on the outside! As it stands today, less and less game work is being done at those "inner workings" level, and more and more artists are slowly but inexorably being funneled into "Technical Artists", as game engines merge with 3D and 2D apps. Again this is just my opinion, but I believe the leaps in technology that are allowing 3D art to become further and further distanced from programming, "higher level", if you will, that engines need to follow the same example.

To point to a new engine, "Unity", now THERE is an engine that is beautifully crafted and quite obviously built with the "programming dumb artist" in mind. It is a purely visual program that just plain makes magic! However, beneath that magical skin lies a very complex, customizable, and controllable engine that any coder would be happy to dig into and do all they want.

Anywho-

Impossible. VBSP needs your map to be a bunch of blocks that may or may not seal entities from the void. There's really no way around this.

Oh well. I assume this "feature" is also part of why Source games run so much better on older systems than UT3 games? Tougher to build, but more efficient?

I was going to have these options. Select an object, and you get axis-constrained handles to drag. Similar to Blender.

Sweet Really looking forward to this one!

This wouldn't be too hard to implement. However, it has the capability to make the 3D view chug, because the 3D skybox wont be vis-sealed from the rest of the map.

What if it was something only manually activated though? Say I hold down "shift-alt-v", and as long as I hold that I can see my skybox in the 3D view? So it would just essentially take a quick snapshot and show it on the skytexture? Again, I know nothing of how all this works, so please don't laugh too hard if this is absurd...haha...but man oh man it would sure be helpful!

Engine limitation, not Hammer limitation. (Is that particle editor still beta-only?)

Nope! UT3 is fully functional, has been for several years now Which is what makes it even odder that Hammer hasn't caught up yet.

Models are always vertex lit. Engine limitation... If you want lightmapped surfaces, it has to be brush geometry.

Now that just makes me sad. Lightmaps on models can really bring a map to life, in UT3 you can toggle them on/off, and choose thier complexity, as well as exactly what "channel" of lights they accept (dynamic, static, user, etc) and what type of shadows to cast. Wahh...

I believe there are some hard-coded maxes on various objects in the compile tools. There's nothing I can really do here unless I want to rewrite VBSP or VRAD, which I'm not going to do.

Hehe, fair enough

The tradeoff for the beautiful radiosity lighting VRAD does, is that you can never have a realtime lighting preview.... You can simulate it, but it's never going to be fully WYSIWYG. And I can't recreate the fragment shaders in the editor (e.g. normal mapping, specular) -- Source uses Direct3D, I'm using OpenGL. Maybe I can approximate them though....
...
Pipe dream. Although, I've never tried reverse engineering a compiled BSP.

Hmm, well, I understand of course that we can't have realtime radiosity (although certain programs have almost reached it!! check out "bunkspeed"!). I meant more to the point of what you called a "pipe dream", haha. The way UT3 does it is:

A) Run compile
B) As soon as compile finishes, all those lightmaps (ie, the radiosity lighting in hammer) are then SHOWN on the brushes/models/etc, right in the editor. Essentially all that pretty pretty lighting is simply "baked" right into the map.
C) If you move anything/change a light, you can then choose to quickly compile only the lighting that has changed! Woot! :wow:

So, I guess a better question would be- anyway at all to extract and then "bake" that radiosity lighting into the editor map? it would sure be nice.

Way out of scope of what I want to do.
...
Already exists, will keep it in my editor.
...
Way ahead of you.
...
Out of scope...

bummer, noted, good to hear, and more bummer

There are a bajillion ascii model formats. .OBJ is most popular I believe. But I'm not integrating a front end for studiomdl.exe for this project.

Okay, that one was a little silly to request. But boy oh boy would it be nice to have a simpler 3D-to-engine workflow for Hammer.

If you've ever looked at a .vmt there's a bit more to valve materials than just a targa. Some tighter integration with VTFLib wouldn't be impossible, it's just a bit out of scope.

Absolutely, the VMT is essentially the shader, yes? However, I prefer the visual in-engine shader creation method of UT3 and most other engines, where you can see the changes as you apply them, and have lots of easy visual control. Node-based scripting is wonderful!

Well hammer really hasn't changed much in a decade, so it's no surprise that newer map editors run circles around it. I guess that's why I've taken on this project.

Well, kudos to you for taking on such an enormous and much needed task! Can't wait to see the end product

Thanks again for your detailed response!

 

[(s2a) yahodahan]

A quick idea on the in-editor arrows or whatever:
By default clicking and dragging on the arrows will move it.
But Shift+Clicking will scale it.
Alt+Clicking will rotate it (by increments of 15 degrees by DEFAULT for the love of god, at least in 3d view D

You'll just have to remember to make it so you can't rotate and scale at the same time. I've seen editors that overlooked that, results were not good.

just my opinion, but...

oh god no GOD NO FOR LOVE OF ALL PLEASE!!!

haha...this system makes me tremble with horror, remembering the (shudder) days of UT2K4 editing...

for those who havn't seen what I mean by "axis constrained movement", check blender, 3ds max, maya, any true 3D app, and you will wonder how you ever lived without.

(warning: going back to hammer will be sad and painful, in that regard at least...)

then again, others may feel completely different about this and I am just a lonely idiot...

 

[Brandished]

The first and second manipulation to your cuboid Brandished (scaling and movement) can be achieved using the vertex manipultor in the 3-D view by selecting either the yellow or white vertices, specific to the movement/manipulation you desire.

I know it's possible in Hammer via vertex mode, but the precision just isn't there. There's no way to restrict a drag translation to a single axis, you can somewhat compensate with the nudge option checked, but then you're restricted to 2 axes depending on the position of the camera. The other nice thing about Radiant is it dots which surface you can manipulate based on where you click in the 3D view, you don't have to have your mouse perfectly over a manipulator point either (well, to resize anyways).

Nope! UT3 is fully functional, has been for several years now Which is what makes it even odder that Hammer hasn't caught up yet.

I believe Earl was referring to the particle editor built into the Orange Box engine, not UT3's. The Orange Box Engine also includes a material editor that lets you see a real-time preview of different shader setting effects as well as a commentary mode editor.

 

[(s2a) yahodahan]

Being able to use a manipulator on textures (along 2 axies) and displacements would also be very handy.

this would be GREAT, love it. I'm always wishing for an easier texture manipulation tool in Hammer

 

[medd]

Would it be possible to implement some kind of notepad within the new editor, that is saved somehow in the .vmf? It would make it easy to keep notes on things you realize you need to do, but can't get to quite yet while mapping.

 

[A Boojum Snark]

Would it be possible to implement some kind of notepad within the new editor, that is saved somehow in the .vmf? It would make it easy to keep notes on things you realize you need to do, but can't get to quite yet while mapping.

I use the comments box on info_null to leave notes around my maps

 

[zpqrei]

I use the comments box on info_null to leave notes around my maps

Or create a 'note' entity, which can have comments in.

 

[Earl]

Well, I haven't had much time to work on this in the past couple weeks, but I'm back on the project. I also just reached another milestone:

It might not look like much, but this represents a texture extracted from the tf2 materials gcf using HLLib, loaded using VTFLib, and displayed in OpenGL, with Python as the glue that holds it all together. This means a textured view will be possible, and should be here shortly.

 

[Altaco]

Well, I haven't had much time to work on this in the past couple weeks, but I'm back on the project. I also just reached another milestone:

It might not look like much, but this represents a texture extracted from the tf2 materials gcf using HLLib, loaded using VTFLib, and displayed in OpenGL, with Python as the glue that holds it all together. This means a textured view will be possible, and should be here shortly.

Bricks have never been so sexy.

 

[Schmoe]

It really surprised me just to see how much of the old, 1996, Quake 1 game design aspects have remained inside the Source Engine and the vmf file format to this day. It's been 13+ years, 5 game engine updates (hl1, hl2, ep1, ob, l4d), and 2 updates to the compile script (map > rmf > vmf) and so many things haven't changed much, if at all.

Makes you wonder when they'll upgrade from Q3.

 

[BrokenTripod]

This just started bugging me about hammer: when using the vertex tool, you hit shift + v, and then make a box to select the verts, then you have to hit enter...

And enter is on the opposite side of the keyboard, so it's just kind of annoying.

Not sure if there's any keys on the left side that could maybe act as an enter button? Or mouse3 or something?

EDIT: Oh man, this is major (for me)

I'd love if the grid was like...dynamic. Sort of.

So, let's say I'm making a multi-storied map. I've got a room that's height is 192 and I need to make a room underneath that that is 192 as well, but I can't have the ramps be too long, so I make the floor between them 16 units. This means that I have to change the snap on the grid to 16 units to make all of the rooms and stuff underneath. (Alternatively, I could just move the whole map up 16 units...but like a grid that could be changed would be cool.)

Yeah, I really have no idea. It just doesn't seem like good practice to move the whole map like that.

 

[Tydax]

There is an option that you can tick to make you able to select without hitting enter. Very useful.

Btw, I really hate the ugly very slow model brower. It is not handy to use.
And I would like to be able to resize, at the same time, two different size blocks.

 

[BrokenTripod]

Use the prop library that ABS made. It's insanely useful.

http://forums.tf2maps.net/showthread.php?t=4674

 

[Earl]

Argh, sorry for the MIA action. Things got really busy at work and it sucked up all my programming ennui. However, I do have an update:

Texture loading is working. Still a few kinks to work out (some missing textures, offsets are ignored for now), and I'd also like to get some rudimentary shading working, but it's there.

Next up on the list:
-Displacement parsing/rendering.
-Starting UI work

 

[SiniStarR]

looking good, wish i could help but i cant XD

 

[LunchBox]

i know this wont help you out in any way shape or form...but since the question was what dont you like about hammer... I dislike how it is extremely delicate and pretty hard to learn but also take note i am no computer whiz.