The first 6 brushes of any map are the bane of my existance. If there was a tool thatd let you draw out a cube, and have each face of that cube be covered by a brush, "sketching" out a map would be so much quicker.
[QUOTE=TheTrainRider;45870234]The first 6 brushes of any map are the bane of my existance. If there was a tool thatd let you draw out a cube, and have each face of that cube be covered by a brush, "sketching" out a map would be so much quicker.[/QUOTE]
You can make a block and use the "hollow" menu dropdown by using a negative value, but the resulting brushes are gonna be funky lengths and need to be fixed.
[QUOTE=TheTrainRider;45870234]The first 6 brushes of any map are the bane of my existance. If there was a tool thatd let you draw out a cube, and have each face of that cube be covered by a brush, "sketching" out a map would be so much quicker.[/QUOTE]
Another option is to have a base save file to start with.
Almost every time I use it, it ends not by me turning it off, but by closing without warning and without an error message/reason.
Really, at least give me an error message, jeez!
[QUOTE=Enhex;45872096]Another option is to have a base save file to start with.[/QUOTE]
[QUOTE=GiGaBiTe;45870435]You can make a block and use the "hollow" menu dropdown by using a negative value, but the resulting brushes are gonna be funky lengths and need to be fixed.[/QUOTE]
Both are true, but I've always felt that hollow creates sloppy brushwork, and having a base map isn't like having a document template in Microsoft word; There is always the possibility of accidentally saving over it.
Even still, a save file wouldn't let me just sketch out a hallway. Trying to manipulate the dimensions of multiple brushes at once always leads to floating vertices.
Edit: Clarity.
Double Edit:
Unless you use the vertex tool. I've had bad experiences with it though so I dunno.
[QUOTE=RonanZer0;45873375]Almost every time I use it, it ends not by me turning it off, but by closing without warning and without an error message/reason.
Really, at least give me an error message, jeez![/QUOTE]
Does this usually happen when you're changing the entity type or pasting entity properties in?
[QUOTE=TheTrainRider;45873853]Both are true, but I've always felt that hollow creates sloppy brushwork, and having a base map isn't like having a document template in Microsoft word; There is always the possibility of accidentally saving over it.
Even still, a save file wouldn't let me just sketch out a hallway. Trying to manipulate the dimensions of multiple brushes at once always leads to floating vertices.
Edit: Clarity.
Double Edit:
Unless you use the vertex tool. I've had bad experiences with it though so I dunno.[/QUOTE]
I usually just make the external cube of a map by making a solid block that's 8 units beyond the internal width/height/depth on each side, clipping along the internal x/y/z on all sides, using the 3d view to deselect the faces visible from the inside, then hitting delete with all of the excess selected.
I made a sloppy frame-by-frame, hopefully that'll make it easier to understand if you don't already: [url]http://imgur.com/a/LwPVg[/url]
Optimization. Other than I like the engine.
The fact that you can't turn a value from, say, a math_counter into a string. How many times I tried to display a dynamic value from a counter onto a text. There is just no way to work around this.
[QUOTE=NiandraLades;45869148]This is probably due to lack of experience, but I find lighting really tedious to do[/QUOTE]
Nah, lighting is just tedious in general. Especially considering you can't get a good feel for it without compiling the map (I've not touched Hammer for quite some time, but I sincerely doubt the "real-time" renderer actually works yet, outside of the Source2 branch anyway).
8192 brush limit.
Lack of an updated interface that makes it look like it's from 2002.
The fact that using Source SDK to get to Hammer Editor is impossible now.
When you make a huge brush and then it deletes everything.
When you try to test something and then all of a sudden it goes *crash*
Compiling times...even though you just want to see how it looks like for a split second.
How subdividing only goes to 4.
I think I can continue, please point something out if one of my complaints isn't worthy of being complained about.
With compiling times, if you just wanna check something small, just use the cordon tools to section off what you wanna see so you don't need to compile the whole map.
[QUOTE=LATTEH;45862423]-No setting for rotation degrees (there is one in the tools but its only for 15 degrees)
[/QUOTE]
i remember back in the day i was talking about ctrl+m and a bunch of people told me they preferred the handles in the 2D viewport to rotate
they are insane
[QUOTE=GameDev;45878172]i remember back in the day i was talking about ctrl+m and a bunch of people told me they preferred the handles in the 2D viewport to rotate
they are insane[/QUOTE]
That should practically be an idea that's drilled into people's heads. There's absolutely no guesswork involved and it always works.
Only if you use the 15° snapping.
I ALWAYS use ctrl+m. (Would be cool if it had a preview, but after a while you get used to it)
[QUOTE=pilot;45876676]8192 brush limit.[/quote]
This is only an issue on extremely large and complex maps (ie. evocity.) In my 10 years of mapping on Source and 15 years on GoldSrc, I've never once hit the brush limit. It's always some other limit that I hit first, like planes, clipnodes, allocblock, lightdata, etc.
[QUOTE=pilot;45876676]Lack of an updated interface that makes it look like it's from 2002.[/QUOTE]
1997*
Worldcraft dates back to 1997, but here's a screenshot of I think 1.6 which is sometime in 1998:
[t]http://members.optushome.com.au/dflood1/images/slawfare/worldcraft1.jpg[/t]
I think this was the first version with Quake 2 support, but not Half-life support.
I think Worldcraft holds the record for the longest continually used and visually/functionally unchanged level editor. It would make it 17-18 years old.
As a modeler who maps in hammer, i absolutely hate not being able to scale models. When i want a model a different size, i have to rescale it in the modeling package and re-export it as a whole new model. Waste of fucking space i say.
I also hate the inability to view lighting in-editor.
I hate the compile times. It's a pain in the ass when other engines (cryengine, unreal engine, unity) can just pop-in game. hardly any compile needed.
I hate leaks. If your map has holes, so be it. LET IT BE! why you gotta be a dick about my mapping skills, hammer?
I hate additive brush workflows. No option for subtracting. That's annoying. Instead of a door frame or window being a single brush with another brush subtracted, it has to be a whole bunch of additive brushes.
I hate how hard it is to import custom content. Source is easily the hardest engine to use as a modeler, requiring so many different third party programs to get your assets in the engine. It's got the most difficult learning curve by far and is the clunkiest engine i've ever worked with.
But i still use it. I guess i'm a masochist.
I reiterate: It's hard to complain about hammer without complaining about the actual engine. :v:
Things randomly going offgrid after reloading hammer.
[QUOTE=HGrunt;45856443]Obligatory: when you create a cylinder and forget to change the brush type back to normal.[/QUOTE]
Nothing has been said more truer then this.
That the size is too small for gmod
Also if you have a brush that isn't exactly square but has a triangle side with the vertex tool in order to let 2 fit seemlessly on an outside corner, and you forget that it isn't a square brush and you move one side that the triangle goes offgrid, so you have to edit it in the vertex tool instead of normal dragging.
I hope I explained it well lol, no idea how to explain this but I think others have it too
when the model browser locks up and you have to keep reopening it to get to work
I hate that every once in a while, the 3d view bugs and walls start disappearing as you go through the map. Sometimes takes restarting hammer up to 5 times to stop.
My materials browser showing textures fully black half of the time, and the other half it shows them just fine.
Alpha textures on models causing opaque parts of the model to be translucent in the model browser.
Lack of an OpenCL-based RAD. GPUs are vastly multi-threaded and thus particularly nice for quickly processing ray-traced lighting. Hate waiting nearly 30 minutes for a map to compile to test/tweak your lighting, especially when you haven't got into optimizing your map yet. (or those occasions when you can't due to size/complexity, displacement abuse, or vast open spaces.)
[QUOTE=Mossj32;45964575]Lack of an OpenCL-based RAD. GPUs are vastly multi-threaded and thus particularly nice for quickly processing ray-traced lighting. Hate waiting nearly 30 minutes for a map to compile to test/tweak your lighting, especially when you haven't got into optimizing your map yet. (or those occasions when you can't due to size/complexity, displacement abuse, or vast open spaces.)[/QUOTE]
If you looked at the compile tool code, you'd run screaming away from it. It's basically hacks bolted on top of hacks.
But the compile tools have a distributed compile mode called VMPI where you can get multiple machines to work on a single compile job. Depending on the CPU speed of the slave machines, it can considerably shorten compile times for both vvis and vrad. It is a bit of a pig to setup initially but once you get it running, it works pretty good.
I have a map that takes 30-40 minutes on RAD on a single quad. With VMPI and with 20 cores working on a compile, it brings down the compile time to 2-3 minutes.
Visleafs. And all the hoops you have to go through to optimise them well which makes creating interesting level geometry a nightmare
I hate how limited the tools are and how crappy the existing ones are. If you want to manipulate geometry, you have to do it by hand one at a time using the vertex editing tool. The displacement painting tools are tedious to use and hard to control, displacements don't map textures correctly unless you use $seamless_scale, and if you want to stitch displacements, the brushes that created them have to be aligned. Displacements are just a pain in the ass in general.
1. I can't jump in-game in real-time without rendering the map and loading it afterwards;
2. The damn skybox not only makes rendering impossible (void leaks) but has a huge impact in performance;
3. Can't see the lightening in real-time as i add the elements, i must always render and then check it in-game. Its a pain in the ass to get things right;
4. Everything must be within the grid, if any brush goes off-grid hammer goes full retard;
5. Can't scale models, if the game happens to feature bigger player models than hl2 for example, i can't use assets from hl2 because everything will seem like a miniature. Im making a map for "insurgency" and ported some hl2 models, such as cars, chairs etc, but it looks stupid in-game because those ported models are too small since insurgency players a bigger than hl2 ones. We should be able to make models bigger/smaller on the fly, cryengine and unreal engine style.
Sorry, you need to Log In to post a reply to this thread.
