Compiler Distortion?

taleden · April 2003

<div class="IPBDescription">the compiler is distorting my brushes</div> Hey.. I'm working on a dropship-style object to put in my map which is made of brushes, and I'm having trouble with it. In the editor, I have texture applied to all outward-facing sides, and all inner faces have the null texture (to save on compile time) - no null textures are visible in the editor. However when I compile and test my map, slivers of null texture become visible in places where verticies of my brushes appear to have been moved during the compile process, distorting the brushes to which they belong and causing these previously hidden sides to become partially visible.

Can anyone explain why this is happening and how I can stop it?

Thanks for any help,
tal

Relic25 · April 2003

This can (and will) happen if you have vertices that are not snapped to the grid at its smallest resolution (ie: 1 unit). This is most frequently caused by carving or clipping that hasn't been 'cleaned up' with the node tool. It can also be caused by non-planar brush surfaces, although you should see those as invalid solids if you check for problems in the map editor.

Oh, also, distortions can occur if you have brushes that are rotated in more than 1 plane, but it's really due to the same causes discussed above.

Ollj · April 2003

ALT+P to find "invalid solid structures".
This happens when a polygon is not flat/planar, or 2 polygons of one object are planar ,or 3 points are colinear, or one brush is concarve....
Some of this errors get corrected automatically by moving vertexes around.

taleden · April 2003

There are no errors in the map - the vertex shifting is happening in spots where I did heavy vertex manipulation/face splitting/etc to create triagonally constructed rounded shapes, this is true, but I was careful to check for errors frequently and fix any non-planar surfaces etc. Also, since it was all done in vertex manip mode, the verticies must all be snapped to the grid (I don't think I've ever turned grid snapping off); also, the distortions involve vertex movements of far more than 1 unit (probably 16 or so at the largest that I've seen so far).

I guess what I'll try next is to move the corners of my shapes manually to try to match what the compiler is doing, so it won't be quite the original shape, but at least it will be consistent and no null will show through. Other suggestions would be welcome, of course. <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

thanks,
tal

Jedediah · April 2003

Invalid brushes can be sneaky sometimes.. post some screenshots from VHE of the problem brushes

taleden · April 2003

Ok.. screen 1 from VHE of one of the corners in question (vertex mode on so you can see all the corners):

taleden · April 2003

Screen 2 from VHE, from a little to the right (so you can judge depth and see the actual shape):

taleden · April 2003

This is what happens in the game when I run it - note how it moves two of the corners of this brush upward, revealing the null texture on the brush next to it:

NerdIII · April 2003

I'm always editing with QuArK. I don't want to talk about its advantages and disadvantages, but to me it seems that exporting a .map from one editor to the other and checking for errors finds all and any invalid brushes. The code of both tools together makes up the perfect problem finder! (Though I do believe that QuArK produces less odd compile errors...)

Rozdower · April 2003

simplify your brushes, a general rule is dont have a brush with more than 6 sides. you .rmf will be not be compiled, the .map will, so you can export to .map, open up the .map in VHE and you can see what the compiler will output.

Rozdower · April 2003

here...

Rozdower · April 2003

and here...

Cagey · April 2003

Your brushes in the pics shown aren't being exported as strictly convex shapes (usually because they weren't constructed as convex). When they are reconstructed, some information is lost.

When brushes are written out to .map format, all vertex information is lost and the compiler must reconstruct the brush from the planes provided in the map file. The compiler doesn't have information about brush corners, so it constructs the smallest shape caused the the intersection of the planes that Hammer exports. I've already posted the attached picture in the tools thread, but it's an effective summary of what's going on.

Any concave shape can be expressed as a sum of convex shapes, so you just need to figure out where to divide your brushes for those corners to be part of separate convex brushes.

VHE catches some but not all cases of concave brushes... it would catch the simple example in the pic, but it's missing your brushes.

Ollj · April 2003

next time try 2 picks with just a small x-axis moxement like making screenshots out of 2 eyes -> magic eye stereoscopic 3d image like
<a href='http://www.antiquephotographics.com/images/ForSale/Louisiana/lou4.JPG' target='_blank'>http://www.antiquephotographics.com/images...isiana/lou4.JPG</a>

when i got the 3d image correctly this change should make it convex:

you just need to make one aditional line inside the surface that you need to change AND that is touching the red line (e.g. blue line).
move this new (blue) line ending points to the end points of the green line and you got the green line.

whenever you get this again remember.

Ollj · April 2003

...or this?

gaggle · April 2003

And lo, God gave The Leveldesigner the ability to make custom models and place them where He <span style='font-size:8pt;line-height:100%'>[;D]</span> saw fit, and God saw that that it was pure goodness.

blue2k · April 2003

simplify your brush, use the vertex manipulation tool to snap the points to the grid. this should clean up those gaps.

taleden · April 2003

Hrm.. I'll muck around with it more, but I'm still not sure if we've hit the problem yet.

The shape cannot possibly be convex (whether VHE thinks it is or not) because every face is a triangle, and a three-pointed polygon in 3 dimensions cannot possibly be convex (a four-pointed one, of course, can me - place them all on a plane and then move one of the points off it, presto). The only sides of that brush that have more than three verticies/edges are the ones inside the shape, and these all line up perfectly with the world axes, so I am sure they are not convex either.

So, since the shape can't be convex, I'm still unsure how even what Caged describes could create this problem, because if you expand all of those triangular sides into planes and try to find the smallest shape enclosed, it would produce the original shape - or at the very least, something so strange that it would look nothing like the original shape, which isn't what's happening.

One possibility, which Caged could comment on, is whether this planar deconstruction/vertex reconstruction process somehow has less precision - if the planes generated during the write-out to .map operate on a coordinate system with larger units, then I could see it creating a best-fit plane that would offset my verticies and create this effect. But why would they operate at different precision levels?

Also, I am sure the points are snapped on the grid because that's how I made the thing in the first place - with the vertex tool, grid set to 2 or 4 or so, grid snapping on.

Thanks everyone for your help <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>
-tal

Cagey · April 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ Apr 8 2003, 02:35 PM)</td></tr><tr><td id='QUOTE'> The shape cannot possibly be convex (whether VHE thinks it is or not) because every face is a triangle, and a three-pointed polygon in 3 dimensions cannot possibly be convex (a four-pointed one, of course, can me - place them all on a plane and then move one of the points off it, presto). The only sides of that brush that have more than three verticies/edges are the ones inside the shape, and these all line up perfectly with the world axes, so I am sure they are not convex either.  </td></tr></table><span class='postcolor'> 
A concave polyhedron can be constructed from convex faces. I'll provide a simple example if you need one.

taleden · April 2003

Bah, I'm an idiot, you were right.. the two little triangles on the left side were convex, just so slightly that I wasn't seeing it.

Thanks for your help everyone. <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>

-tal

Ollj · April 2003

You cant make a cup or a doorframe out of a signe brush in HL.
Even if each face itself is flat the whole brush might have 2 faces convex to each other.

The first thing a compiler does is determing the center of each solid brush.
From out of this brush-center go normals (lines that have 90° angle to the face and a "direction" pointing "outside") to each face of the brush.

Simple language:
2 triangles/faces/textures of the same brush will never see each other if they had eye-textures, they always look away from the brushes central point.
If 2 textures might see each other this gives your error!

taleden · April 2003

Yeah, no, I understand the geometry of it and how convex/concave works and all that.. I just had two sides that I had thought could not see eachother, but in fact could (just an itty bitty tiny bit). Anyway, thanks again everyone for the help.
tal

watch_me_die · April 2003

This is unrelated to the distortion, but are you sure you're using the correct compiler?

Those NULL-textured faces should be invisible in-game...

Yamazaki · April 2003

In one of those pics it looks like it's completely dropping entire faces, as if they were textured with NULL. This can occur with lots of VMing that involves merging vertices. I've had perfectly constructed cylinders that suddenly missed a face or two, because I merged some faces together. This sort of error isn't the result of faulty design on the mapper's part, but merely a problem with WC/VHE when it comes to handling VM.

Avoid merging vertices in VM when you can, and definitely don't do more than several at once.

taleden · April 2003

Nod I've had that trouble too.. usually if I wasn't able to undo it, I was able to destroy the empty face by merging its verticies into valid faces, and then recreate it by splitting a nearby face. As a last resort, you can always carve off the bad part and split faces to rebuild it.. but of course, the more vertex manipulation you do, the more you're asking for things to get wacky.. heh.

In this case, however, the problem was, in fact, a concave brush.. a couple of the triangular sides were slightly concave, it was just too small for me to notice at first. With Caged's description of the export/compilation algorithm, however, I was able to realize where it was going wrong and fix it accordingly.

I'm using Zoner's compile tools, but it's very possible I don't have them configured correctly, I just started mapping for NS on saturday.. the null textures definitely appear blue in-game for me just like they do in the editor, in any case, so if they shouldn't, how do I fix that?

-tal

Cagey · April 2003

</span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (taleden @ Apr 8 2003, 08:05 PM)</td></tr><tr><td id='QUOTE'>I just started mapping for NS on saturday.. the null textures definitely appear blue in-game for me just like they do in the editor, in any case, so if they shouldn't, how do I fix that?

-tal</td></tr></table><span class='postcolor'>
Make sure you're using version 1.6 or later of Merl's custom build of Zoner's 2.5.3.... you can find version 1.7 <a href='http://collective.valve-erc.com/index.php?go=mhlt' target='_blank'>here</a>, or use my own modifications to 1.7 which are webbed in this forum.

gaggle · April 2003

hint: go with XP-Cagey's <img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'>

NerdIII · April 2003

Yeah, and if you keep having trouble with vertex manipulation, use QuArK instead... it doesn't offer *free* vertex manipulation - only safe ones - at the moment, but it works on the plane level and will therefor be more accurate and find all concave shapes. <img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'>
Btw... have you guys tried QuArK? If yes, what's your opinion about it. There are still people working on it, so I think most wishes could be included in future releases... Personally I like that path extruder very much for making bent pipes.

Compiler Distortion?

Comments