New Tool: Hlfix
Jedediah
Join Date: 2003-01-27 Member: 12847Members
Join Date: 2003-01-27 Member: 12847Members
<a href='http://extension.ws/hlfix/' target='_blank'>http://extension.ws/hlfix/</a>
hlfix is a tool that converts Worldcraft/VHE format files (.rmf) to standard .map files. In the process, it performs a number of geometric operations to fix common problems with brush geometry. hlfix is far more sophisticated than VHE's built-in map export feature. The purpose of this tool is to give map designers much greater flexibility in the type of geometry they use to build their maps.
hlfix is a tool that converts Worldcraft/VHE format files (.rmf) to standard .map files. In the process, it performs a number of geometric operations to fix common problems with brush geometry. hlfix is far more sophisticated than VHE's built-in map export feature. The purpose of this tool is to give map designers much greater flexibility in the type of geometry they use to build their maps.
Comments
This was the main thing I was looking for.
This might help a few mappers... too bad it's still beta, though.
Edit: Now with less jubilation!
<!--QuoteBegin--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->hlfix is a tool that converts Worldcraft/VHE format files (.rmf) to standard .map files. In the process, it performs a number of geometric operations to fix common problems with brush geometry. hlfix is far more sophisticated than VHE's built-in map export feature. The purpose of this tool is to give map designers much greater flexibility in the type of geometry they use to build their maps.
To begin with, hlfix outputs floating point coordinates to .map files as opposed to VHE which rounds all coordinates to integers. This alone solves a number of typical mapping problems. hlfix also performs three phases of geometry correction:
-Tesselating non-planar faces
Faces that do not lie entirely in one plane are decomposed into planar polygons which approximate the intended surface.
-Decomposing non-convex solids
A convex brush has all it's edges "pointing" outward. Non-convex brushes are cut into convex pieces.
-Uniting coplanar faces
The .map compile tools do not allow a brush to have multiple faces in the same plane. Any such faces are joined together by hlfix and a warning is given if they have different texture information. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
check it out!
<i>also, for cagey and other coders, he has a tech page and the .rmf coding format.</i>
And encourages sloppy design, all at the same time! woo!
Not to demean the efforts or anything, but floating point support is hardly the godsend so many people make it out to be...
But I am curious what Valve will have to say on it, and what Cagey would have to say when (if) he looks at the code.
And encourages sloppy design, all at the same time! woo!
Not to demean the efforts or anything, but floating point support is hardly the godsend so many people make it out to be... <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
There are a few things that FP support fixes on its own but mostly it is there because it's necessary for the other geometry correction. I had some very specific cases in mind when I designed this tool. When I have time, I may write an article illustrating them.
You'd be surprised what you can do with careful and well-placed vertices on the 1 or even 2 or 4 unit grids.
Indeed, but this is also where the sloppy design factor comes in. A lot of this -can- be avoided, though, either through vertex manipulation, or in some cases well-placed rotating entities.
Regardless, it's nice to have this for the times it can't be avoided. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo--> Anyway. This is far too much waxing on theory for me at the moment - I've got work to do. <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Yeah, and this is the case even when you stray from 45/90 degree geometry.
With some intelligent unit transformations you can get good approximations for 6,12,16, and 24 sided objects while sticking to a 1 unit grid--if you are careful about using consistent angles by using multiples of a small line segment you'll end up with much less resource intensive (leaves, planes, etc) maps.
Examples for a ~16 unit long line at various angles:
0 degrees : 16,0 units in x,y dimensions
~15 : 15,4
~30 : 14,8 (also useful for 8 unit long segments)
45 : 11,11 (I use 12,12 frequently because it's evenly divisible)
Once you have the ratios down, you can orient things just about any way you want while maintaining exact proportions and being faithful to the grid -- by using multiples of the above segments, you guarantee that you can chop up the angled walls at regular intervals and still have your brushwork aligned to a single plane (the compiler tools will thank you)... I've almost entirely written off the in-editor rotation tool unless I'm using it for multiples of 90 degrees.
That said, just having an independent RMF -> MAP converter that's open source is a step toward preserving visgroup information in a neutral format for other editors to import, flagging bad brushes that VHE doesn't catch, and potentially helping mappers fix problems automatically (although I definitely agree with KFS that people should be avoiding bad brushwork in the first place instead of fixing it). It also means I won't necessarily need to remember to export to .map before I run the tools in an external batch, which is something I have a mental block about... HLFix as potential IMO <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->.
Now...if only we could get a scripting language that is part of the bsp file that HL reads....mmmm, yum yum custom FX
My bad - if you decide to keep your code, I can always look at the format you published <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<a href='http://silencegreys.com/sa/conf_worldcraft.gif' target='_blank'>http://silencegreys.com/sa/conf_worldcraft.gif</a>
It got completely mangled mostly because the faces that join adjacent window segments were non-planar. I ended up having to manually split each segment into 4 tetrahedrons which was a huge hassle. What's worse is that all of the splits I made were ultimately joined by hlcsg anyway.
The original goal of hlfix was non-planar fixing, in particular, for joining faces as in the above example. However, non-planar tesselation creates non-convex brushes, hence the decomposition phase.
There are other cases that I know of and probably some that I don't.. as I said earlier, when I have time I'll write a tutorial or something.
The first thing I wanted to do when I started mapping was create oddly angled objects and curved surfaces. It was very frustrating discovering that VHE effectively limits you to architecture that is much simpler than what the HL engine is capable of.
Now, in my current map NS_Democles, my first hive has some serious rocky architecture, filled with triangles to make it look smooth. I wonder if this tool would help. But i doubt it.
I try to align everything to the VHE grid as much as i can.
I CANNOT stand seeing me map with lines that aren't straight and aligned.. unless im making rock or natural terrain.
Jedidiah did you figure out why it was renaming and retargetting buttons and such?
From my post above, but in an easier to read format:
<ul><li>preserving visgroup information in a neutral format for other editors to import
<li>flagging bad brushes that VHE doesn't catch before its map exporter mangles the source
<li>potentially helping mappers fix geometry problems automatically (although I definitely agree with KFS that people should be avoiding bad brushwork in the first place instead of fixing it). This has been the focus thus far.</ul>I will probably add .rmf input file support to the tools once the bugs are worked out of the HLFix source. Doing this will result in better error detection for VHE based maps and opportunities to halt on geometry errors that I can't detect now (you can add HLFix as a separate program in the compile chain in the meantime, much like opt_plns is used now).
<a href='http://countermap.counter-strike.net/Nemesis/batchspec.html' target='_blank'>http://countermap.counter-strike.net/Nemes.../batchspec.html</a>
Will add a few varieties of it latter.
~Nem
Yeah, and this is the case even when you stray from 45/90 degree geometry.
With some intelligent unit transformations you can get good approximations for 6,12,16, and 24 sided objects while sticking to a 1 unit grid--if you are careful about using consistent angles by using multiples of a small line segment you'll end up with much less resource intensive (leaves, planes, etc) maps.
Examples for a ~16 unit long line at various angles:
0 degrees : 16,0 units in x,y dimensions
~15 : 15,4
~30 : 14,8 (also useful for 8 unit long segments)
45 : 11,11 (I use 12,12 frequently because it's evenly divisible)
<!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Not to stray too far off topic, but I've got another option to add in addition to XP-Cagey's take on angled brushwork.
For 45 degree pieces, I rescale the texturing to 1.06 in both axis, stretch the object a bit so that the X and Y length of each line is 75% of the texture's unrotated length (ie. A texture 128x128, would have each side be 96x96, making the total brush 192x192), and this allows me to fit the object to the grid more easily.
For example, let's say I have a floor texture that is 128x128. I want it angled at 45 degrees to represent a bend in the hallway. I slap it down, rotate it 45 degrees, then stretch it out a bit so it occupies a 192x192 area (96x96 per side). I then texture it at 45 degree rotation, with a scale of 1.06 for both x and y. Since the brush is 192x192, it fits perfectly to a grid of 32 units. The 1.06 texture stretch isn't noticable at all either.
1.06 seems to be a magical number for 45 degree rotations, since it always fits perfectly as long as you apply the 75% rule.
fixes a couple of major bugs