Compiler Distortion?
taleden
Join Date: 2003-04-06 Member: 15252Members, Constellation
<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
Can anyone explain why this is happening and how I can stop it?
Thanks for any help,
tal
Comments
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.
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.
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. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
thanks,
tal
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.
<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.
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 <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
-tal
A concave polyhedron can be constructed from convex faces. I'll provide a simple example if you need one.
Thanks for your help everyone. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
-tal
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!
tal
Those NULL-textured faces should be invisible in-game...
Avoid merging vertices in VM when you can, and definitely don't do more than several at once.
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
-tal<!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
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.
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.