Some powerful functions work within Quark but may produce unknown problems in the pipeline to a production build. Extruders take predefined geometry and replicate it along straight and curved paths, but how that geometry will work when it is integralized may be an issue. Diggers allow you to create subtractive geometry which is not removed from the world until the MAP file is compiled. This keeps the QKM file clean and easy to edit, but can create complex cuts in the world that the designer never sees and which can cause unexpected build errors. Terrain brushes work correctly, but the high poly count produced may cause problems in both bsp and final frame rate. Curves and Patches are not supported at all.
Procedures for creating a map for RLC QuArK maps are limited to an area from -8000 to 8000 QuArK units on the X,Y and Z axis.
Placing anything beyond these boundaries will cause a corrupt build. The RLC BSP engine is very sensitive to non-integral geometry. Polygons which require floating point calculations can produce drawing problems and collision detection failure in our engine, as well as PVS calculation failure in large or complex maps. As noted above, QuArK should save MAP files out without floating point values. In order to make sure it is doing this correctly, it is wise to keep the source QKM file geometry integral.
Geometry should be build snapped to non-fractional grid lines. You can check to see if geometry is integral by using Search-->Find Non-Integral Faces on the pull down menu. Non-integral faces should be snapped to grid when possible.
QuArK 's native geometric primitives are generally integral and but should be checked periodically. Non-integral geometry can generally be fixed by snapping vertices to grid.
- QuArK's snap to grid functionality, accessed by holding the control key while moving geometry, is based on snapping the center of the object to grid, not the vertices which make up the object. Snapping a poly to grid does not place its faces or vertices on integer boundaries. Warning - Moving a group while holding control will cause all elements in the group to snap to their individual centers, destroying the relative placement of polys in the group!
- Selecting a face and dragging while holding control down will snap it to grid. This does not necessarily insure integral vertices. Make sure to exit face selection mode before performing any operation on the poly such as copy/paste or rotate. Corrupt geometry can result from performing these operations on a face.
- Selecting a vertex and dragging while holding control down will snap it to grid, but it may be necessary to select and drag it in more than view window to get the vertex on grid on all three axes. It is sometimes not possible to move a vertex without moving QuArK moving the vertices which are connected to it, making it impossible to get all vertices on grid.
- Warning - Wedge primitive brushes in QuArK are non-integral and cannot be fixed , use triangular prism and drag a vertex to make a wedge, or brush subtract to build one from scratch.
- Warning � Don�t have faces from two different polygons in the same plane overlapping and assume that they will be drawn in the same order as you see in your testing. Always offset faces slightly if they are overlapping.
Even if all vertices are on grid, it is possible to create dangerous floating point geometry by intersecting faces at odd angles. This should be avoided whenever possible. When an angled face must meet another face, make sure they are intersecting on an integer unit. Surfaces on perfect 45 degree angles are good for this since they will always intersect integral geometry on integer boundaries...but there's a bug in our exporter which effects texture placement on perfect 45 degree angles. Alternately, calculating the rise over run of a slope to determine safe integral intersection points is an option.
Having two surfaces meet on an odd angle is only safe if they meet vertex to vertex...and maybe not even then. Try to build everything out of rectangular solids where possible and then add details with angled brushes that meet other geometry on a flat surface.
In small maps it is possible to bend these rules, but on larger maps they can cause flaws in the bsp.
Textures should be jpg (or png for transparency) and MUST be scaled to a power of two on each axis (64, 128, 256) for best results, try to keep textures applied at 1:1 scale.
Textures may be moved on a face, but may only be rotated at 90 degree angles.
Also try to create as few textures as possible, and keep any textures you do make to a maximum of 256x256 in size to conserve memory.
Sealing Maps A box made of brushes flagged "sky" needs to be placed over the top and sides of the map so it will seal. This will not only stop users from going skydiving off the map but allow the BSP to be built correctly for game use.
The way that the BSP compiles--in ridiculously simplified terms--is by starting at a point off in the distance and trying to find a path into the map. It looks for a light entity, since those should be placed inside the live area of the map. If it fails to find any, it can safely clip away all of the exterior faces it found, leaving an optimized BSP made of nothing but the absolute essential faces and ready for a PVS set calculation. That's what SHOULD happen.
Continued
