Bad Surface Extents Created 18 years ago2006-05-15 00:11:11 UTC by [VDC] Rad Brad

I know what they are and I (unfortunately) know what needs to happen, and I've been doing it. Since Hammer finds no errors in the map, I am individually hunting down the offending surfaces and re-texturing them. What I'd like to know is this: Is it better to check the world box or the face box as far as the texture is related. Most of these textures are at the surfaces that touch, so they are never seen. I am selecting them, resizing them to 1x1, centering them, and checking the "face" box... so... is that the best way to fix them when you don't know if they're truly the problem?

If the corodinateds of the face are given in the compile log then just go to maps menu->find brush number and paste in the corodinates. The brush will be marked and I think the 2D views will center view it.

Cool, I'll use that, as well! I didn't know you could use the coordinates. ^^

Good to see you Rad Brad!

Is it better to check the world box or the face box as far as the texture is related.

I've never really understood this either, though I'm able to work with it--If a decal is "backwards" I check whatever one makes it show the proper way, and when aligning textures, sometimes clicking one or the other makes the texture line up just right, but I really have no idea how it works!!!

I've only encounterd that error by mistakenly scaling textures way too huge, so I'm sorry that I don't have more to add....

Those checkboxes are for texture alignment. They're not magical stuff - in the end it's just texture coordinates for the engine to handle, all the same.

Usually, you only notice the difference on angled faces. With world alignment, all textures are aligned along the axis. If you have an angled face, the texture looks stretched (because, the texture is applied as if you were looking at it from one of the 2D views - from that particular view, the texture looks ok, but an angled face is always longer than you can see in the 2D view).
Face alignment aligns the texture taking the surface normal (direction) into account, solving the stretching problem.

This is why flat, axis-aligned surfaces have both checkboxes checked, but other surfaces can have only one checked.

Aanyway, onto those surface extends, those are usually caused by extreme texture scales. Above mentioned alignment modes have no effect on this as far as I know.

Well, I'm guessing it's extremely small textures... mixed with large ones... along the lines of 1.67x 0.21 kind of stuff... Every time I fix them, a new one comes up somewhere else. Is there a way to make it list all the objects? It appears to compile through VIS. I'm not sure how it does it, but I would think it could know all the offenders after a once-through.

Hiya Rowley!

Pasting the co-ordinates into the brush number fails. I'm sure it would like an actual brush number.

Look for textures stretched to .02 or something very small, or things over 10 or something.

Did you accidentally hit 'fit' on a small, 1 unit thick brush or something?

You also get this error if theres something outside the grid or close to the edge, check that.

Did you accidentally hit 'fit' on a small, 1 unit thick brush or something?

My little brother did that a few times. This error and my explanation have caused him to more or less hate the Fit button.
And then I have to explain it's usefull now and then, when used carefully...

Hmm, I've just found the .map file format specification on the old VERC, turns out texture scales are found at the end of each brush plane (oddly enough, faces are stored as planes and their intersections are calculated to get the edges and vertices... :S). A line like this:

( -128 384 128 ) ( -128 384 0 ) ( -128 640 0 ) AAATRIGGER [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 2 0.1

stands for a face with it's texture scaled up 2 on the x axis and 0.1 on the y axis. Might be easier to find that way. A tool that checks texture scales surely is a lot easier, too... hmm, I'll see if I can do something.

Wow, that's a bloody odd way to store faces :|.

A tool to check for terrible scaling would be very nice.

May I present you: Scalehunter

Simply drop 'n drag your .map file onto the program, enter the minimum and maximum texture scale and you'll get a nice little report. Have fun with it.

Another excellent doo-hicky for the upcoming User Tools section, methinks.

Hehe. If anyone would like to see some more functionality like this, give me a yell. I can occasionally do a little program now and then.

Oh, and for questions, demands and bug reports, you can PM or mail me - I prefer mail, since my PM box is at an all-time full... mail adress can be found in the readme or you can mail through my sites contact form.

Wow! I will give that program a try! Thanks, Captain P!

I don't usually hit the "fit" button, except to fit one side (or two, if it's a door. And I only do it one side at a time.

It's not that I don't expect to have them, but to compile for an hour to find out the next object that needs correcting, well, it's driving me crazy! Usually I have an error or two and I fix them, but it's almost like every object has this error. I'm just looking for someone to say I'm doing right by fixing each one instead of throwing out the map because it'll never be fixed.

Script kiddies.

I assume you know enough about programming to see this wasn't a scripting job...

Ok... it works very well... too well, since I didn't want to see the answers.

Now the questions:

I am showing something like 1200 discrepancies. I set it for 0.2 and 10. Nothing is larger than 11. I'm guessing that the decimal following the error text is the actual size of the texture?

Is 0.2 a good number to search for? Is that a stable size for a texture or should it be larger or smaller?

What program can I open a .map file in that will show me line numbers? Otherwise, I'm doing a ton of division in MS Word, since it at least tells me what line per page...

Can I edit the .map file, open it in Hammer, then save it as a new .rmf file?
If I can edit it, I would try to replace the low decimals with 1, then fix them again in Hammer.

A suggestion for future versions would be to add the brush number to your list as well as the texture size and a method for saving to a log file. Then noobs like me could waltz around in Hammer and take care of it in an environment we're familiar with... and I'm not so noob I don't know how to mark and select it to paste in a notepad file. But others may not know how.

Ok... I selected EVERYTHING and changed the texture size to 1x1. I checked a bunch of textures and they had changed. I saved, exported to .map, and compiled it... with a bad surface extents error... so I have copied the log for the RAD section for everyone to comment on. Please tell me if I have something set weird.

[quote]= Current hlrad Settings =
Name | Setting | Default
-------------------|---------------------|------------------------
threads [ 1 ] [ Varies ]
verbose [ off ] [ off ]
log [ on ] [ on ]
developer [ 1 ] [ 0 ]
chart [ off ] [ off ]
estimate [ on ] [ off ]
max texture memory [ 8388608 ] [ 4194304 ]
max lighting memory [ 6291456 ] [ 6291456 ]
priority [ High ] [ Normal ]

vismatrix algorithm [ Original ] [ Original ]
oversampling (-extra)[ on ] [ off ]
bounces [ 3 ] [ 1 ]
bounce dynamic light [ on ] [ on ]
ambient light [ 0.000 0.000 0.000 ] [ 0.000 0.000 0.000 ]
maximum light [ 255.000 ] [ 256.000 ]
circus mode [ off ] [ off ]

smoothing threshold [ 50.000 ] [ 50.000 ]
direct threshold [ 25.000 ] [ 25.000 ]
direct light scale [ 1.000 ] [ 2.000 ]
coring threshold [ 1.000 ] [ 1.000 ]
patch interpolation [ on ] [ on ]

texscale [ on ] [ on ]
patch subdividing [ on ] [ on ]
chop value [ 64.000 ] [ 64.000 ]
texchop value [ 32.000 ] [ 32.000 ]

global fade [ 1.000 ] [ 1.000 ]
global falloff [ 2 ] [ 2 ]
global light scale [ 1.000 1.000 1.000 ] [ 1.000 1.000 1.000 ]
global gamma [ 0.500 0.500 0.500 ] [ 0.500 0.500 0.500 ]
global light scale [ 1.000 ] [ 1.000 ]
global sky diffusion [ 1.000 ] [ 1.000 ]

opaque entities [ on ] [ on ]
sky lighting fix [ on ] [ on ]
incremental [ on ] [ off ]
dump [ off ] [ off ]

colour jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
monochromatic jitter [ 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 ]
softlight hack [ 0.0 0.0 0.0 0.0 ] [ 0.0 0.0 0.0 0.0 ]
diffuse hack [ on ] [ on ]
spotlight points [ on ] [ on ]

custom shadows with bounce light

[               off ] [               off ]

rgb transfers [ off ] [ off ]

[Reading texlights from 'D:Program Fileszhlt33lights.rad']
[59 texlights parsed from 'D:Program Fileszhlt33lights.rad']

11364 faces
Create Patches : 53458 base patches
98 opaque faces
356082 square feet [51275944.00 square inches]
4985 direct lights

BuildFacelights:
Error:
for Face 39 (texture c1a4_silo3) at
(1008.000 1281.000 -1392.000) (1008.000 1434.000 -1392.000) (1008.000 1530.000 -1392.000) (1008.000 1530.000 -1264.000) (1008.000 1510.000 -1264.000) (1008.000 1281.000 -1264.000)
Error: Bad surface extents (17 x 9)
Check the file ZHLTProblems.html for a detailed explanation of this problem[/quote]

Error:
for Face 39 (texture c1a4_silo3) at...

Did you make a change to the bad face listed to see if that corrects the problem?

You can mark that texture in the texture window.(tick the only used ones) After you press mark the window will be closed and all the brushes with that texture will be marked.

(17 x 9)

Maybe this line indicates the size of the texture. 10 is the maximum.

(1008.000 1281.000 -1392.000) (1008.000 1434.000 -1392.000)

Is there anyway to center view this given point?

He can just scroll to the coordinates.

The bottom middle of the hammer editor, there is a status bar.. When you move the pointer through the 2-d views it shows the coordinates relative to the origin (duh) if you dont see it, go to view>>toolbars>>status bar. something like that. im at school right now so i cant find out for you

I'm guessing that the decimal following the error text is the actual size of the texture?

Yep, that's the scale that violated your tresholds. The line number is given in front of it, and .map files can be opened with simple text editors like Notepad. I wouldn't recommend MS Word for these plain text files. Personally, I use Notepad++ for things like this.
Yes, you can edit the .map file and load it into Hammer, provided you didn't make it an invalid .map file of course.
Tommy14 recommends scales between 0.1 and 10 bytheway, so I think those would be good tresholds.

A suggestion for future versions would be to add the brush number to your list as well as the texture size and a method for saving to a log file.

Good suggestions, I'll see what I can do. The logging is definitely a good one, I had it in mind when I was busy with it but thought, oh well.
I figured out how to get brush numbers now so that's no problem either.

Too bad this wasn't the cause of your problem though...

Bad surface extents, malformed faces..
I had a whole bunch of annoyances with those two errors, before I figured out, how to find the brush.

They're one of the most annoying errors in mapping. CP or someone skilled in this should write a tutorial for errors like that.

Malformed faces? They usally apear in the check for problems menu as texture particular to face error, just fix it. If it can't be fixed then you must rebuild the solid.

Ok, I updated my tool: it now logs the report to mapname_log.txt, storing it in the same folder as the .map file. Violating texture scales are now sorted by entity and brush number and the log file contains a little text info to get people started.

Here's the download, again.

Very nice stuff, but the English in the log file explanations could do with a little tinkering, and I see "Log file created by ScalehunternnMap: modeltest.map" at the top. nn?

Heh, thanks for the fast comments. Just a mis-type after a quick recompile. Fixed now.

About the English, feel free to rewrite it and send me a message.

With some minor alterations to make it easier to read, and a couple of little corrections:

This log shows all faces with a texture scale below 2 or above 3. The violations are ordered by entity and brush number, makingthem easy to find in Hammer: press Ctrl + Shift + G to open the 'Go To Brush Number' dialog (or access it through the Hammer menu) and enter the entity and brush number as given in this file.

The other information shown is the line number and the offending scale. The line number is nothing else than a line in the .map file - this is a text file. Yes, you could open it in Notepad if you wanted to.

Please note that this tool was built with the Bad Surface Extents compile error in mind. Texture scales lower than 0.1 or higher than 10 could be the source of this problem, though a 'texture axis perpendicular to face' may also cause this error. That one however can be found with Hammer directly by checking for problems (Alt + P).

Might be nice to have n before "Entity #" to break it up a bit, and maybe save the double-colons for the brush numbers, using single ones for the actual errors, like this:

  : Scale too low at line: 430 (1)
  : Scale too low at line: 430 (1)

Entity #6
:: Brush #0
  : Scale too low at line: 439 (1)
  : Scale too low at line: 439 (1)
  : Scale too low at line: 440 (1)

Oh, and check if you need an 's' for this stuff if you want to, of course. Makes it look a bit more professional.

Summary: 600 violation[m]s[/m], spread across 4 entitie[m]s[/m] and 50 brushe[m]s[/m].

PS: treshold -> threshold!

BJ,

With this paticular texture, I have not searched it out and changed it, but I have with several before... not only the texture, but the entire family those textures were in.

Elon,

The only way to center that view that I know of is to pick through the map using your cursor in the x/y and y/z or x/z views. It's a big pain to do, especially with a detailed map. And I believe the 17x9 example is the size of the brush face, though if you do the math on the tri-ordinates, there isn't one that size.

Captian P! OUTSTANDING!

This will help me out alot. I could think of a whole range of problems I have that could use little programs like this, if you're looking for work. I will look for Notepad++.

Using your old version, I have many faces less than .1. I haven't had time to try your new version, nor have I had time to attempt a blanket fix yet. I had hoped changing the textures to 1x1 would have solved this problem, but not yet. I will be back with an entire log file, since RAD didn't spark any response.

And I didn't notice a second page... or I'd have added this to my above post!

Thanks, All!

And I'm just noticing the little edit button... that's new since I've been away!

Notepad++ is superb.

Thanks for the help, Seventh. I inserted your text, I'm now checking for the 's' (not only for violations, but also for brushes and entities :P) and I'm updating the log formatting. How about a nice 'n tidy html format, which allows much easier-looking formatting?

@[VDC] Rad Brad: I could do a little work now and then. If you've got some suggestions, feel free to PM or mail them, or just post it here. Perhaps a tool (or an addition to this tool) that also fixes the 'violating' scales to the minimum/maximum you set? Would save you some work...

Awesome app there, CP.

How about a nice 'n tidy html format, which allows much easier-looking formatting?

That would be excellent... how about calling the page up in the application associated with HTTP (not with HTML, I wouldn't say, 'cos lots and lots of people have HTML files associated with Notepad++, Dreamweaver, etc. :)).

Anyway, you've inspired me: when I've got the hang of a little more C++ (working on a ROT-13 proggy at the mo') I'll set to work on something mapping-related. Very cool.

Hmm, I see what you mean... looks like a good idea. It could get difficult to retreive this info though, probably some looking around in the registry... and it would only work for Windows then (though I really don't know if this tool works on Linux in it's current shape :P).

Perhaps a tool (or an addition to this tool) that also fixes the 'violating' scales to the minimum/maximum you set? Would save you some work... smile -

Just because I like things to be complete, I think it'd be a good idea to be able to raise the tiny scales to a minimum and lower the huge scales to a maximum... Now if there were a way to identify the brushes associated with entities and either set them aside or "forget" them so that only world brushes were affected by the resizing of the textures,I would be even more inclined to use it. That way the lights and other little what-not wouldn't be changed.

But, like you say, it doesn't help me with my current problem. I think I can only find this by ripping the map into sections and recompiling each section... Divide and conquere...

CP, you could also add something, that LeakMarker does.
You could make an invalid entity/texture brush at the object, that has bad surface extents, for newbies to find it easier.

Hmm, I see what you mean... looks like a good idea. It could get difficult to retreive this info though, probably some looking around in the registry... and it would only work for Windows then (though I really don't know if this tool works on Linux in it's current shape :P).

Isn't it VC++ .NET? Yeah, definitely a registry job though.

You could make an invalid entity/texture brush at the object, that has bad surface extents, for newbies to find it easier.

I thought about that, but can't see that it would actually help at all. Perhaps texturing offending surfaces with AAATRIGGER, though, so one could easily see which face was messed up.

Just because I like things to be complete, I think it'd be a good idea to be able to raise the tiny scales to a minimum and lower the huge scales to a maximum... Now if there were a way to identify the brushes associated with entities and either set them aside or "forget" them so that only world brushes were affected by the resizing of the textures,I would be even more inclined to use it. That way the lights and other little what-not wouldn't be changed.

But, like you say, it doesn't help me with my current problem. I think I can only find this by ripping the map into sections and recompiling each section... Divide and conquere...

That's possible, the current version already checks what entity a brush belongs to. World brushes belong to the world entity, which is always the first one, so yeah. However, if an entity surface causes the problem, then you'd still want to fix those. I could throw in something that tries to keep the right x/y scale ratio while fixing, too.

As for your problem, rather than ripping the map apart you can also put a big brush over half of the map and compile. If the problem is gone, it's in that covered half of the map. Or perhaps use cordon compiling (which essentially makes Hammer only put the things within the cordon to the .map file that is being compiled).

Perhaps texturing offending surfaces with AAATRIGGER, though, so one could easily see which face was messed up.

Then Daubsters solution sounds better: invalid textures can be found with Hammers problem check so that'll take you to the problem straight away.

Aah, of course. I missed the word "invalid" when I read it this morning.

I must say I've never seen this problem so widespread before.

It would be very interesting to know what is causing all these "Bad Surface" errors, so please share with us if you come up with an underlying cause!

Is it possible your trying to compile decompiled architecture? I've noticed when trying to "fix" decompiled brushes--getting them on-grid, retexturing, etc--they are simply too fucked-up to compile.

edit: I've found sometimes that deleting an object that's giving you trouble, then compiling, then hitting Ctrl+Z--so you never close down Hammer obviously--and recompiling sometimes gets rid of various malformed, corrupted stuff. Maybe it's worth a try to do it to your whole map :P!

edit 2.0: Found this while searching tommy's for something else...interesting and may apply to your woes:

Odd errors that cause Mysterioius and Peculiar Problems:

* Most notable of these is the "too many wads" error. If you have more than 8 wads in WC, then weird problems CAN occur - but not always, and not for everyone. Always check that you do not have too many wads when your problem doesn't "fit" the solutions...
* Another odd problem that shows up elsewhere is the bad sky enviornment name. For most of us a bad sky enviornment name leaves us with the default enviornment. But for some mappers, this can cause odd error warnings: like a bad brush that does not exist, or brush outside of map, or bad lighting in the map. Make sure you get that name RIGHT! If the six sides are sky_lf, sky_rt, sky_up, etc. you use "sky_" in the cl_skyname field.
* A third odd problem is too small textures. If one over stretches the texture more than 10x, then zoner's compile tools usually give a warning. But there is little or no warning if you shrank the texture too far. When you get a frustating error that doesn't make sense, this one is something to keep in mind.
* A rare fourth problem is a single HUGE .wad that is too big for memory.
* If you have the a problem like malformed face and you do a check but do not get that error, but "Solid entity is empty", you may be a victim of the editor mixup.

RowleyBob:

I've been through that list of odd and peculiar errors before... I have 6 .wads. The sky thing might be a cause,though. I was putting cl_skyname and not sky_skyname. I've never had a problem with that before, though I use mostly default skies.

This map is my own creation (it attends the school for "special" maps, but I love it anyways), so no decompiling.

edit: I've found sometimes that deleting an object that's giving you trouble, then compiling, then hitting Ctrl+Z--so you never close down Hammer obviously--and recompiling sometimes gets rid of various malformed, corrupted stuff.

That I don't understand... You delete the object, compile, then in Hammer, "undo" the deletion, then recompile? I don't think I will do that one, since the error is with many little objects all over the place.

Captain P:

I'm realizing that the textures in the entities still cause a problem. I thought that they didn't.

So I'm using your tool with a cordon strategy. It gives me quite a head start on things. I'm wondering if this is what I'm reading with it:

Entity #55
:: Brush #4
:: Scale too low at line: 4759 (0.09375)
:: Scale too low at line: 4760 (0.09375)
:: Scale too low at line: 4761 (0.09375)

Is that brush #4 of Entity #55 or is that two separate items; Brush #4 and Entity #55?

And your tool will show a brush with a texture being 10.5, but I've changed it to 2 in Hammer, though it didn't need changing, and it still shows up as 10.5. I've saved it and also saved it with different name. Any ideas why this might happen? If I raise my threshold for maximum texture size to 11, my errors drop from 289 down to 27.

Also, a question not about the tool, but my problem:

In some areas, I find no texture violations, but still end up with bad surface extents. Other than textures, what might be the cause of that?

Brush four, which is in entity fifty-five.

You've re-saved the .MAP, right? Just re-saving the .RMF won't re-save the .MAP too; only compiling or manually saving a .MAP will.

Oh, yeah... Map_Rev1_Hallway, Map_Rev1_Hallway2, etc.

The .map file is organized into entities: an entity contains some data of it's own, and certain types can (or must) also contain brushes. So I organize brushes under entities because that's the way they're organized in the file itself. World brushes belong to entity 0, the world entity, bytheway. You'll need both of these numbers if you want to use Hammers Go To Brush number action.

Anyway, perhaps you can send me the map? Looks like you could use some more help than just a tool (plus, it could give me some more insight in what causes this particular problem).

And just a thought: I assume you didn't compile the map often? Looks like a lot of problem sources that seemingly all pop up at once. What helps me a great deal is saving the map under another filename after every major change, and compiling the map often. Good back-up system, allows you to fall back on an older version when you mess up one, and makes sure you always get a working map, or one with only few problems.
Of course, it's a little too late for that now, but still...

I have problems on every map I make. Not your everyday "texture perpendicular to axis" problems. They piss me off so much I set it aside for a while...a few months. Come back, start another one... same stuff. So this map is a compilation of several of those maps tied together. Not for the faint of heart, I know.

Every one of the sections in this map have worked flawlessly at one time.

Compiling is not my strong suit.

Thanks for creating the tool, but I've hit my "fuck this" stage for now.

tex perp problems are solved easily by alt-p finding them, then aligning the faces to world. there caused when you rotate an object so the face's Z cordinate is flat with the face. thats just a messed up normal and aligning it to world fix's it instantly.

and by your post above you mean your getting bad extents on all you maps?

If there is a hall of fame for weird errors, this gets it.

If it's happening to all your maps, something is awry with your Hammer/compile tools/os/other...but what?

Well I can understand why you don't want to mess with it anymore...that would be pretty annoying after while...

Well, perhaps that's why letting others take a look at the map could help. It might be that you've adapted a work method that structurally causes such problems to pop up?
The last years I mapped for HL hardly ever gave me problems, while in the first time I encountered many.

Same goes for programming: only recently I learned how to avoid memory leaks, something I didn't know how to for years. That's all because some other guy took a look at my code.

I think I found the problem. I had the compiler set to subdivide at 256. The default is 240. According to Nem, setting the subdivide too high can cause bad surface extents. My first cordon section compiled and ran through STEAM. 256 seemed a better "computer" number, but I'm guessing, now, it's not.

Thanks for the offer, Captain P, and I understand the logic behind your suggestion. In fact, I force my apprentices to do just that every day. I just make sure they've exhausted EVERY possible option they can think of before I look at it. So when I run out of options, I will send it your way.