4. ViewBSP Compiler Options

This section details the user-alterable options of ViewBSP's BSP compiler.

This section contains the following subsections:

4.1 General Options
4.2 Geometry Options
4.3 VRML Options
4.4 Message Options

 

4.1 General Options

 general options
 
Convert color indexes to RGB triplets
If an *.aod or *.bsp file contains a valid palette specification and some face colors are specified via color indexes, the palette is used to convert those colors to (r,g,b) triplets. Note that the color specification in the output file will then be rgb_col, not indexed_col anymore! If ViewBSP doesn't know how to color a polygon it will be displayed as being red! Incidentally, the same holds for texture-mapped polygons.
 
Apply specified object scale factors
If an *.aod or *.bsp file contains a #scalefactors section, these scalefactors (one for x, y, and z each) will be applied to the object. Note that separator plane and bounding box info will not be correct after reading and scaling the input data, therefore this option should normally not be used for *.bsp files! Use "Geometry Options/Maximum object extents" instead, to scale your already bsp-compiled objects.
 
Apply axes mapping
Applies axes mapping specified in section #xchange. This will not function correctly if separator plane and bounding box info is contained in a *.bsp file! Thus this should only be used for *.aod files!
 
Only triangles and quadrilaterals
This determines if for input data read from a *.aod file (does not apply for all other file types!) faces with more than four vertices are not allowed. Normally this should be enabled, since faces with more than four vertices read from *.aod files are not checked for planarity!
 
Check doublets on object merge
When two objects are merged, their sets of vertices need to be merged together. This option determines if non-unique vertices are eliminated or kept. Note that in VRML files exactly identical vertex sets are a frequent case since Coordinate3 nodes used multiple times via USE instancing are attached to each of the objects using them. If this option is not activated these Coordinate3 nodes will occur in the output data as often as they have been instanced. Nevertheless, the elimination of vertex doublets can take a considerable amount of time for models with a large number of vertices.

Splitter Selection
This determines the splitter selection heuristic. An object is basically a randomly ordered (from ViewBSP's point of view, so to speak) list of polygons. During BSP compilation polygons have to be selected along which space should be partitioned. Regarding size and rendering efficiency of the generated BSP tree this selection can be anywhere from very bad to quite good. On the other hand, the more polygons are tested (sampled) before choosing one as splitter determines how long compilation time will be. The compiler can always sample the entire list, the first n polygons in the list, n randomly selected polygons from the list, or just take the first polygon in the list (although the first polygon that comes along is usually the worst to use, due to some law of tough luck).

With respect to BSP tree quality the ordering from best to worst is as follows:
Sample entire list > Sample first/random n > Take first.

Well, with respect to compilation time, it's the other way around.
Normally the default option (sample first n) works best for all models, except for objects with very few polygons (say, up to 200). Whether sample Random n or First n is better in terms of quality depends on the order of polygons in the model. Most of the time First n is better, because those polygons are pretty random anyway. Random sampling is a little bit slower during compilation than Sample first n.
 
Sample size
Selects n for two of the aforementioned splitter heuristics: Sample first n, and Random sample (n). Values between 5 and 30 are usually fine.

 

4.2 Geometry Options

geometry options

Insert trace vertices
After BSP compilation the compiler will insert trace-vertices to avoid t-junctions. Trace-vertices are not new vertices, but only additional vertex-indexes in the vertex-lists of polygons. The reason for this is that if two polygons share an edge and one polygon traces this edge as two or more edges and the other as single edge, pixel dropouts will occur. So, the compiler inserts the additional indexes into the other polygon to make it trace that edge also as two edges. Note that this operation will take an excruciatingly long amount of time for large models!

Check for multiple vertices
The compiler will check whether some vertices are contained in the vertex set more than once. However, doublets will not be removed, only counted and displayed.

Calculate node bounding boxes
Bounding boxes will be calculated for each node (encompassing that node's polygon and all polygons of its children). They will also be written into the output file.

Attach separator plane info
Explicit separator plane coefficients will be calculated for each node and written to the output file. A plane is specified via four coefficents: Three components of its normal vector, and its distance to the origin. Alternatively, you can interpret these as coefficients of the plane equation.

Numerical Thresholds (Part 1: things for experts)
The first three of these are epsilon-areas used in geometric computations by the compiler. Normally, you don't want to tamper with these!

Numerical Thresholds (Part 2: maximum object extents)
This forces a scene's extents to a fixed maximum value. On the one hand useful to actually see anything in ViewBSP, because the camera will not adapt to different object sizes (the default extents value will do fine for this). On the other hand you can use it to scale your model.
Note that the model is assumed to be symmetrical about the coordinate origin for this calculation. That is, if a model extends from 500 to 1000 it will actually count as being 1000 big in each direction (that is, 2000 all in all). So, a symmetrical bounding box is calculated and the model scaled accordingly!

 

4.3 VRML Options

vrml options

Triangulate all VRML objects
All objects read from a VRML file will be triangulated after the file has been parsed. Note that this will not necessarily generate triangulated output objects, since the triangulation is done prior to BSP compilation.

Use full material specification
Full VRML material information will be written into the output file (e.g. ambient and diffuse lighting). ViewBSP will only use the diffuse component for shading, however. Note that this makes the output file substantially larger!

Mirror texture v axis
VRML files assume a texture v axis from the bottom up. This mirrors the v axis so that you get your v axis from the top down in the output file which is more convenient to calculate texture offsets.

Tessellation steps per PI/2
All VRML primitives will be tessellated during the VRML file parse. This determines how fine-grained this tessellation will be. The specified value sets the number of angular steps that will be done for an angle of PI/2.
Note that VRML files containing many spheres will take ages to load (and tessellate) if this value is set too high!

 

4.4 Message Options

message options

Show Message on...
Here you can select/filter what witty messages the BSP compiler should display (write into the message log).

Create message log
Additionally writes all messages from the BSP compiler into a file called "viewbsp.log" in the current directory, so that you can come back and appreciate them.

Basic statistics
Displays some statistical information at the end of compilation. Basically, this is the same information as in the "File/Object Info" window.
 


back to ViewBSP main page.
ViewBSP documentation copyright (c) by Markus Hadwiger, 1998. ALL RIGHTS RESERVED.