http://img140.imageshack.us/img140/9210/hammererror.jpg

(1) The glitches shown in this picture are not visible in the game, they do not give out any errors while in valve hammer, and they do not give out any errors while or after compiling (in the log file). Lag is not an issue in game either.

The pipes that has been translated in an angle (usually unacceptable by Valve Hammer) on the other hand, does not give out any errors while in valve hammer, and they do not show up as glitches in valve hammer. But while in game, under direct light, the glitches appears greatly. (These pipes was not modified after translation, clipped or otherwise).

The problem occured after I changed the pipes angle.

----- END hlcsg -----
----- END hlbsp -----
HLVIS seem to crash while processing LeafThreads, so I have to end the process manually in windows or else hammer will crash.
The message "Warning: No vis information, direct lighting only." is displayed in the hlrad information (of course).
----- END hlrad -----

I THOUGHT those pipes were my problem, but after I had deleted them, the hlvis problem still occured.
I also tried to delete the target_mp3audio entity that I had placed in that area right after I fixed the pipes, but the problem still occured.
I also tried to delete the last light entity I edited in the room (I only changed the color a bit).

If the map visability procedure won't execute properly, what could be the source of the problem? The map is not too big just yet, I deleted the last three brushes and entities and tried to compile again but the problem was still there.

There are NO errors displayed in valve hammer, NO errors in the log. hlvis just seem to be mocking me it seems.

I tried to delete half the room, of all the last brushes and entities I created, the problem is still there... I'm back to square one, basically, where I KNOW for a fact that map visual worked perfectly.

I'm not sure what your problem is.

Does hlvis really crash or does it only seem that way, because it takes so long?
LEAFTHREADS usually takes longer with each percentage, which means the last 10% (or even more) are gonna take very long, if the steps before already take an unusual amount of time.
Usually it just takes that much time, when you have high r_speeds/wpolies and thus single leafs just see too many other leafs, or when really complex brushwork is kept as worldbrushes and causes many, little leafs.

Regarding your pipeproblems, I'm not sure, wether you can just rotate complex brushes without getting errors in-game. It works in hl2, if you make it func_detail or something, but in hl1 I make sure that every vertex is on the grid, because otherwise the compiler will set them on the grid, which can result in weird shapes, errors or worse, although hammer doesn't give an error!

In case you wanna rotate complex brushes, make sure to set the vertices back on the grid manually, which can be very tricky with faces using more than 3 vertices though (invalid solid/ coplanar faces).
If you know which skewed faces of a brush cause the invalid solid error, you can divide them into triangles using the vertex mode. You select two vertices and press CTRL+F to create an edge between them to split a face with more than 3 points. Just make sure the brushshape stays convex, which means you have to pick the proper vertices to create the appropriate diagonal.
If you wanna insert multiple edges into one brush, make sure to deselect vertex mode and the brush in between or hammer might crash.

All other procedures seem to spend 0.20 to 0-70 seconds processing, while LeafThreads doesn't even come to 10 percent. I know I shouldn't touch my computer at all while compiling or I'm gonna be sure to crash Hammer. Unless, of course, I press ctrl+alt+del. In other words, the LeafThread procedure never ends, and it never hits 10%. Usually, the maximum of seconds I've seen LeafThreads processing is 10 seconds, and this time, I made dinner while LeafThreads was processing.

The one thing I haven't done so far is delete the current hlvis executable and extract a new one in its place, in case the hlvis.exe has been corrupt somehow, sometime (which seems very odd btw).

Edited: Yes, hlvis does crash. hlvis works just fine. No leaks. No errors. Hardly 50 entities.


Can this be caused by map information problems
skyname, default light level, max view distance, etc? probably not.

Oh, I almost forgot. You don't compile with hammer running in backround.
Try to use a .bat file or some batch compiler programm, where you can set the parameters.

If you run hlvis or any of the other tools with -estimate, you can maybe see, if there is any progress at all, because it shows a little more information, what it's doing at the moment.
What are your options for hlcsg and hlbsp and what does -chart show about the .bsp?
Try to compile a simple room to check, if hlvis is running correctly.

There are no additional parameters.

I downloaded a batch compiler, batchcompiler312.exe, that I cannot seem to configure by myself. I was too lazy to get involved with more hows and why's, it looked like, excuse my language, a piece of ######. So I ignored it and went with the oldschool compiling, which worked just fine until now.

I found the problem, it was the pipes... The pipes that weren't glitching.

I forgot you couldn't make ANYTHING detailed for HL1 mods. I guess this map will take me a week to finish now since I can't add anything to it but regular square walls, regular square floors and regular square ceilings.

Yeah, annoying stuff, but that's how you learn it

When hlvis crashes/takes forever, it means something is messing up your leafs. So entities can't be the reason.
Do you still have complex worldbrushes like those pipes in the map? ..or rotated brushes in general?

You could also run a fastvis (hlvis -fast), which doesn't start LEAFTHREAD and then start the map (without hlrad, you don't need that to check out a map) or watch the map in some bsp-viewer programm and check for distorted shapes/faces that aren't supposed to look like that and then you'll know which brushes cause the error.

I fixed it and made boring "square" edged pipes. The pipes aren't square, they have the normal triangle,square,triangle,square,triangle, etc... but now all edges are square, as if the pipes were made in 1950... it doesn't look good but, it's supposed to be right outside the pipeline so I guess it will have to do. Inside Pipelines I will just add the pipes next to the walls with concrete around them as seen in a lot of other maps on NS.

Just split up the pipes into mutliple brushes, less brushes that do not contain all that much detail. However, put them together and you've got yourself a nice and detailed pipe. Also creating one brush with lot's of detail, the compilers are bound to change some vertex and crash or make the engine crash if your try and run the map. Even if Hammer says there are no errors. Malformed brushes can occur at the BSP tree building process with brushes that look good in Hammer, but fail in the compile process.

HL1 mapping is all about using visual trickery, to fake high detail. Just make sure those fake detail bits do not touch any walls or the HL compilers or engine will explode

Check out the stock and crazier custom maps for how they did higher-detail brushwork. Achio and my own Nexus have plenty examples, including some tricky pipes.

The pipe was made out of multiple parts ?
And you made sure they all were ON THE GRID ?

Kouji_San, the problem with your advice is that more planes are created and that you get stuck at convex shapes build out of multiple brushes.
It's fine for little details that are avoided movement-wise anyways or are covered by clip-brushes, but you can see in every single, even simple map (veil, eclipse) that players get stopped at slopes and skewed faces, which is sometimes crucial for bhopping, blinking and charging aliens.

Otherwise I agree, you don't need square pipes to make the compilers work. Just put some work into the vertices and make sure all are on the grid, while the faces stay valid.

Yeah, I know I forgot to mention clipbrush work. It is indeed a very imporant part of controled mapping. Clip brushing inaccessable areas (scenery), it a must as well. It will make sure those parts are not used in the final clipping hull and in turn will give you loads of clipnodes back to use.

However, using multiple brushes for detailed objects is still the best way to get the most detail out of this engine. A nice side effect is that it will also prevent the engine from getting graphicla glitches on face edges, something that could happen when using one brush with loads of vertexes. Even if it looks perfeclty fine in the editor...

I clip brush everything that could screw up clipnodes or a player just can't fit in between. Just make sure you're not using a too large clipbrush, as it would look odd to see floating skulks on walls!

Heck even Valve is making some very stupid mapping mistakes with some of their TF2 maps. Getting stuck on silly little protruding things (dustbowl first section in the tunnel parts for instance). Tisk Tisk Valve!

Sidenote:
Glitches like the getting stuck on things while bunny hopping is usually fixed by turning this kind of slope, built up from 2 brushes (warning ASCII artwork):
___
|-|-\
-----

Into a slope like this this (continuous brush):
___
|---\
-----

But this is not full proof, more like 7/10 times it does work in getting rid of the sticky area at the top of the slope.

Side-Sidenote:
Damnit you guys are making me want to open up Hammer again and fix cerberus and perhaps continue the moving parts thingy co_2benamed map I was working on (has 2 more areas then the video shows, but I already mentioned that in the post your screenshots thread WAY back, prolly only oldschool members know what I'm talking about )

Here I was, thinking I kicked the mapping addiction!!!

Walk away Kouji! WALK... SCREW THAT!!! RUN AWAY KOUJI BEFORE IT IS TO LATE!!!

This is literally how I put the brushes together at first, when they worked with hlvis, it's the oldtimer way of making a simple pipe without having to use models (like we do in source). And this is how they still look.

/-|-|-\
|-|-|-|
\-|-|-/

But as soon as I I wanted two pipes to meet eachother "smoothly", one pipe being at 0 degree, the other at 90 degrees (looking X/Y). This is where I screwed up, copy pasting the pipe, turning it 45 degree's (X/Y), because as it turns out, triangular shaped brushes can't be turned in any other degree but 0 degrees, 90 degrees, 180 degrees, etc.

Hard to explain, but it looked like this

|-|
|-|
|-|
\-\_____
\--------


They weren't on grid. But now, they look like this, and are on the grid.

|-|
|-|
|-|_______
|_________

Over the last couple of years I've been accustomed to the source version of hammer, where you do not have to worry about moving each individual brush edge on grid.

On source's version of hammer I used to make caves (caves, that actually looked like caves and not a halfpipe turned upside down), and large mountains, mixed up with large oceans, and not to mention I was one of the first to come out with a tutorial on how to make live lightNing, adding thunder with the logic_timer a couple of seconds later after the bolt hit the ground. And you can make up to as many bolts you want, and make them hit any location on the map you want. Not to mention the flash of LIGHT (entity) that you add 0.3 seconds after the bolt hit the ground, to make the mountains in the area lit up.
A lot of people did not know that, you do not have to make ONE light that exceeds a certain range to flash the area (because this will make sure your FPS drop below 5 every time a bolt of lightning hits the ground), but you can add a couple of small light entities across the map (you can find these spots by adding ONE HUGE LIGHT entity at first, and walk around your map screenshotting all the walls/mountains, then remove the huge light entitity and add a bunch of small ones where you want the lightning bolt to deflect light.) A lot of people made fun of me at first, said that my lightning would be a flop, that it would not only look ugly, but it would most certainly make all computers crash - but they were wrong.

Behind "me" in the picture there's an entrance to the cave I was talking about, the story says that it leads to a secret government facility under the mountain. There's also another entrance, which is on the other side of the rocks to the left in the picture. Which is a pipe-model I made illusionary, and added transparent solid brushes around so that you could walk throughthe mountain and in to a large, broken down, ventilation system inside that later on leads to the government facility I was talking about.

This lightning does not look good at all when captured (I used fraps to capture it, an made the screenshots from there), but the lightning hits so fast, that you can't focus your eyes on it, so eventually it looks good.

No lightning, no light, no thunder.


Lightning, no light, no thunder.


Lightning, light, no thunder.


No lightning, light, no thunder.


Thunder (2-4 seconds later...). Making the bolts distance aprox 2-4 kilometers away.

@Kouji: Your example of the slope brushwork is exactly what I'm talking about It always works for me and I apply this style to as many convex surfaces as possible, not only floors. If it doesn't always work, it's because of other, adjacent convex surfaces built with multiple brushes.

@Ikaros: You can make the two pipes meet each other smoothly, if you don't copy one pipe-brush and turn it 45°, but copy it and move the vertices of one side to the other pipe.
It works perfectly fine for me, if you keep the faces at 45° !
You just have to align the texture manually on the two faces looking up and down.
http://img518.imageshack.us/img518/6630/pipe.jpg

Edited:

Had to use prefabs, high detail brush, before I could change the angle of each vector in the pipe (vertex tool). It worked a-ok now, and I got me some smooth corners again. Thank you.

Not clipbrushed ones that is


Wouldn't it be cool to have displacement surfaces in HL1. Ah well, we'll just have to wait for the new toys in NS2...

Displacement is, just, sexy. If you want to make a chapel, then you just bowl out the roof once or twice in the same spot.

Very sexy indeed
I've mapped for II before it, well, died, and those II maps are usually almost only displacement brushes.
But then it gets annoying to build invisible visblockers with null-texture brushes and hint-brushes beneath and around those displacement surfaces.

As much as I love the displacement tool. I had major problems with it, real annoying ones too.

If I didn't group the brushes together before displacing them, each individual face wouldn't align. And I couldn't align the vectors manually either. If you think about those mountains and caves I was talking about earlier, they contain several brushes in order to make it look good - and when you make a cave that is supposed to work as exterior and interior at the same time, going from OUTside to INside of the mountain, you cannot group the cave brushes with the mountain brushes, or you'll end up displacing the mountain's faces when you're really just trying to displace the cave's faces.

I sort of had to overlap the brushes on top of eachother (you know, not aligning them as in a "V" but overlapping as in a "X") in order to make it look good, but the problem was that it didn't look so good when the lighting was added, because one texture was darker than the other, making it look like two completely different textures, sort of.

So I had to hide the glitches with models, such as rocks, grass, wires, small trees, etc. You know, basically entities, but solid models.

That's also a feature I love, adding models like that. We should have more options in the HL1 engine!!

Considering NS pushes the HL1 engine to its breaking point, I really don't think it's possible to do without making the engine more unstable than it already is. The HL1 engine is already a heavily modified Quake engine, adding more complex things to it like patch meshes and physics would really bog it down due to how unoptimized it is for modern machines.

If the engine was completely recoded from the ground up using a more modern source base from ioq3, you could probably do more with it, but as for 1996 technology, its hit a brick wall.