Random Mapping Questions Created 18 years ago2006-02-14 11:15:57 UTC by rowleybob

For my DM map I'm running into some problems--Also learning a lot too

Here are a couple:

Terrain:
I've made some nice looking sloped terrain--a crater. It looks great, but everywhere there is a seam, the player get's stuck, and you have to jump or walk around. Another thing I've noticed about creating smooth-looking, sloping terrain, is that if you texture it perfectly, you can barely even tell or notice it in-game, because it blends so well. So, I guess I'm looking for general suggestions/tips for dealing with terrain like this.

Dynamic Lighting:
As my map gets bigger and more detailed, I've noticed my dynamic lighting isn't working properly--slow strobe isn't working anymore, although it does work for a cordon compile

R_speeds and VIS:
I've func_walled much of my complex bits to save on vis time, and lifted stuff off the floor to prevent splitting. I'm guessing in terms of r_speed reduction, for the final compile, I should "to world" the complex bits to reduce wpolys?

ZHLT Light-flags:
When you set an entity to opaque, does it also block VIS?

K. That's all for now! Thanks in advance

The opaque flag doesn't block VIS I'm afraid. About your walls- how do you want to improve them? I find that layering brushes on top of one another, but avoiding them touching as much as possible, can make good-looking rock walls, and judicious use of the clip tool helps.

RE your r_speed question, you'll have to strike a balance between e- and w-polys. What are they on average in your map at the moment?

1. Terrain in HL is a pain. Not only does creating smooth terrain cost a lot of time, there's also the buggy movement issue. I'd say, Keep It Simple Stupid. Is that smoothness really worth your time and polygons, or are those resources better invested otherwise?
Anyway, perhaps some clip brushes will help, and you should use lighting to your advantage to give the terrain more shape. But perhaps you can give a much simpler version of the terrain a similar look through lighting, so again, is that smoothness worth it?

2. Probably a problem with maximums or such? You're not getting the maximum amount of light styles per surface error?

3. Not the complex bits, at least not the small complex bits. About the lifted brushes, are those large and potentially effective at VIS-blocking? Then don't lift them - face splitting isn't that bad, especially not if it saves the engine from having to render a whole other region.
It may well be a more structural problem bytheway. Perhaps your layout doesn't allow so much detail, so you'll have to cut down on some less important details, or rework the layout a bit. It may also be usefull to just deny access to an area where the player can see a lot of poly's (as in, the player sees a lot of poly's when he's in corner A and looks at corner B. Instead of blocking sight to corner B, why not dump some obstacles in A so the player can't get there anymore?).

4. No. It only blocks light. This increases compile times radically though.

Llama: my mean r_speeds are about a 900, but as high as 12-1300 in a very few spots.

Cap P:

I think you're right about the terrain. The end result in-game is not worth the time spent building it, the bugs, and increased wpolys. Again too, it doesn't even look much better than more simply designed stuff

Not getting the dreaded "light styles" error, and I only have two groups of four blinking lights in the whole map. Reduced it to two groups of one, and they still don't blink. Like I said, it worked fine in earlier compiles and in cordon...

The stuff I've lifted off the floor is in a lower part of the level and doesn't block vis that much/r_speeds aren't so horrible down there either.

I found changing all the complex stuff "to world" saves me +200 wpolys--and adds ages to the compile time--, so it might be a necessary evil.

Initially, I was hoping to seperated the upper and lower portion of the map with hint brushes--crater opens to the lower level--, but I've learnt the hard way and since read that Hints don't work in open spaces

So I had to "seal" the upper and lower levels and did a bit of simple trickery to make it seem they're not

Thanks for the 411 about zhlt light flags too...that is really good to know.

Thanks for your thoughts guys!

Re the dynamic lighting: I'm assuming from what you're saying that the light in question is actually affecting a large area of the map? If so, that is an awful lot of information which the engine has to keep changing continuously. (The slow strobe ramps the light level up and down, doesn't it?)

I had a similar issue in one of my levels. lab17_storage has a freight elevator. When activated, the lights throbbed on and off, and affected much of my warehouse area. It looked great, and worked well in tests, but when more than one player was in the map, it just brought everything to a halt. I had to switch back to a much simpler flashing sequence - and reduce the strength of the lights, and hence the number of surfaces lit by them - to make it playable.

For terrain use Nem's Terrain Generator, it works wonders.

If you are thinking about using the Nem's TerraGen, keep in mind that you go to need to make some changes (VM) to prevent unnecessary poly...

Of course that you can leave it, but you'll have a high r_speeds...

And after, if you want a lot of details, put some CLIP brush, to avoid the player get in stuck...

And after, if you want a lot of details, put some CLIP brush, to avoid the player get in stuck... laughing -

Func_illusionary does a nice job for details too...

Thanks everyone! Yeah, Nem's has some awsome stuff. I've only tried Hlfix, GCFScape--of course--, and the bsp viewer. Someday I'll try the try Terrain Generator and Batch compiler...

Regarding the blinking lights, they're now working in later compiles, but it's strange how buggy they are... Sometimes they don't work, and don't really look the same after each compile. Probably end up eliminating them, or tucking them in a more secluded area of the map...

@Capt. P/Nemo: Yeah, I found with more complex terrain, there were only "stuck" problems where a gentle/gradual slope met with a steep one, so I'm either just decrease the slopes, or clip as you said

Thanks again!

If you are thinking about using the Nem's TerraGen, keep in mind that you go to need to make some changes (VM) to prevent unnecessary poly...

Select everything, null it, texture only the faces that you will see, tie it to an entity. Saves w_ and e_ poly like nothing you've ever seen.

Select everything, null it, texture only the faces that you will see, tie it to an entity. Saves w_ and e_ poly like nothing you've ever seen.

I don't know if this happens with Nem-generated terrain, but if the whole terrain patch is made one entity an absurd lot of unexpected face-splitting may happen. Perhaps I pushes things too far in Mudanchee (the HLDM version), but be cautious.

Ahnn.... Worldcraft...
About the "unnecessary poly", I was talking about that semi-coplanar faces that you just can't see any difference between each and other...
But the engine sees...
And the game breaks the land in little triangular chunks...

And thanks, Captain... I forgot that func_illusionary is better than CLIP Texture in some times...

I used Nem's terrain tool for the snow in cs_office_css. There's no face splitting, you just have to be careful with it(kept it locked on a 4 unit grid).