Vehicle Tire and Wheel Creation in BRL-CAD

Traditionally, BRL-CAD tire models have been created using a single cylinder, a torus intersected with a cylinder, or in some cases additional combinations of these primitives. While these approximations are often sufficient for analytical purposes the resulting model is typically a poor visual match to the real tire when raytracing. Creating more complex models to better approximate the tire’s shape almost always requires more resources than can be justified.

The tire tool offers a method to generate a model that is dimensionally close to a "real" tire using primitives and CSG operations. The primitives used are the elliptical torus (eto), right circular cylinder (rcc), ellipsoid (ell), and truncated general cone (tgc). When tread is added, the sketch and extrude primitives are also used.

By default, a basic steel wheel (a.k.a. "rim") is included in the model. If this wheel does not work for a given modeling purpose, it is quite simple to remove it and substitute in a user-defined wheel so long as the dimensions of the user supplied wheel match the standard wheel at the key points (radius and width).

While the tire tool can supply tread, it does not do so by default. Complex tread patterns can SIGNIFICANTLY increase the time for analysis and visualization, so the modeler needs to bear this cost in mind.

The tire generated is always centered at the global origin.

The default behavior for the tire procedure with no arguments given is to produce a tire of dimensions 215/55R17 without tread in a file named tire.g.

Since this default is unlikely to meet the needs of most specific modeling tasks, almost all uses of tire will need the "-d" flag to customize the dimensions:

There are actually a wide variety of standards used in practice to specify tire dimensions. Generally the majority of them have the same "core" information plus additional performance and rim compatibility notations. At this time, BRL-CAD supports the following input format:

The supported ISO-style separator form is width/ratioRdiameter. The R may be upper or lower case. ^[1] The ratio specifies the sidewall height in terms of the overall tire width - for example, if a tire is 100mm wide and the Ratio is 40, the sidewall height is 40mm. Examples of valid input strings for tire dimensions include:

All three values must be present to have a valid input string. Also note that at the moment this procedure takes ONLY integer arguments and single non-numeric character separators, so the above formatting restrictions need to be observed. Examples of INVALID inputs include:

If more precision is needed on any of these inputs, the tire tool offers other command-line options to use instead of (or even in combination with) the d flag which accept floating point input. When used with the d flag, they override the value for their particular parameter supplied to the d flag. They are the W flag for maximum width, R for the ratio, and D for the diameter of the wheel. For example, if a width of 255.5mm was needed, the command could be:

There are limits to the dimensional configurations that can be modeled by tire (for example, hub width can not be wider than the maximum tire width), but it should cover most real-world dimensions. Some examples:

The model that is created by this routine results in a hollow tire with a thickness (by default) related to its radius - the greater the tire radius, the thicker the tire "walls". The structure created is a fairly good geometric tire shape, but does not contain any internal structure within the tire material itself. Modern radial tires in reality are composed of several different layers of varying materials designed to enhance structural strength and performance, but (as of April 2008) the tire tool approximates tire surfaces and walls as being a single region.

Tread is the most difficult part of a tire to define in terms of the amount of input data required. The tire tool provides several built-in tread presets and can also read a custom JSON tread pattern definition.^[2]

Tread profile and tread pattern are the two factors to consider when specifying tread. Tread profile is the "shape" of the tread on the edges of the tread pattern. Many truck tires have a "squared off" tread, while automobile tires tend to have more rounded tread. Named tread presets select a default profile and pattern count, and the legacy numeric aliases remain available.

The t flag controls the tread profile, and the p flag controls the tread pattern preset. The following legacy aliases are available:

Use --list-tread-patterns to list all built-in presets. Current presets include highway-rib, all-terrain, mud-terrain, winter-siped, commercial-rib, and the legacy aliases. Use --tread-pattern-file to supply a custom JSON definition.

Using either the t or p flags to the tire command will trigger tread generation. If a named preset is supplied, its default profile is used unless a t profile is also supplied. Here is the default output for legacy style one:

Style two is intended more for trucks and other rugged vehicles:

Using t in place of p with one of the legacy profiles also produces a treaded model. Internally the tire command must use some pattern and profile for every tread it creates, and for ease of use it will select a default if a pattern or profile is specified by itself. Using the flags together can produce different results - for example, profile 2 with the legacy-rib preset:

There exist two additional user level flags that can change the behavior of the tread routine. The first is the g flag, which can be used to specify different tread depths in integer numbers of 32nds of an inch. For example, the default number two style previously can be rendered with a deeper tread:

to produce a different look:

The other flag is the c flag, which allows user control over how many copies of the master tread pattern are used to encircle the tread surface of the tire. This can be used to create courser or finer tread with the same geometric pattern. For example, if the first profile, second pattern and count of 100 are used:

Adjusting the count of patterns can be a way to get a different visual tread style without defining a new tread pattern, although it is unlikely to result in a "real" pattern in the sense of representing an in-use tire tread.

Tire thickness is manipulated via the u flag. By default, the tire procedure will adjust the thickness of the tire according to the size of the tire, but there may be cases where it is desirable to change this thickness.

Let’s say, for the sake of argument, a model of a large vehicle tire is needed and it is known that a very thick wall is being used. To start, input the dimensional information:

Now, examine the cross section in normal and surface normal views (the tread pattern and depth are added so the cross section WITH tread is shown - it will change with and without tread):

This is a visual check - other tools are available for actual dimensional testing. Let’s say the desired thickness is 70mm. The tire is re-generated thus:

Examining the cross sections again, the thickness increase is clearly seen:

The default behavior of tire is to make the rim width (the width of the tire at the point where the outer wall connects with the steel wheel) equal to the width of the tread, which is in turn defined internally as a fraction of the total width. This normally produces reasonable tires, but tire does provide the j flag to allow custom values for rim width. The input units are inches.

When tire accepts a maximum width specification, it internally decides on a default distance from the tire center where that maximum will occur. This parameter can be adjusted by the modeler with the s flag. Some examples using the narrow rim width model settings from the previous section:

The other flags available in tire relate to naming of the top-level tire object. The a flag automatically appends the dimensional information to the name, making it simple to import multiple tires of different dimensions into a single .g file with the MGED dbconcat command. The n option allows the modeler to specify a string other than "tire" for the root name of the top level object. These options can work individually or in concert. So, for example, to generate a top-level name of "car-255-55R17" instead of "tire" for the top level object the following will work:

By default, the procedure creates a file called "tire.g" to contain the model. If some other name is desired, a different file name can be supplied as the final argument to the tire procedure. For example,

will create the "mytire.g" file and insert the default tire model.

Although it is not visible to the eye in normal raytracing, the tire models do include knowledge in the model of the presence of air inside the tire as well as the tire and wheel structures themselves. For illustration purposes, the following image displays the air region inside the tire:

The three material regions are defined immediately below the top-level object:

The names of these regions will change with the dimensions of the tire requested, but the basic form will remain consistent. The tire-215-55R17.r region holds the tire and tread (if tread was requested), wheel-215-55R17.r holds the rim and internal hub of the wheel, and air-215-55R17.r defines a volume inside the tire and wheel not occupied by the other regions.

Below this level, the structure describes the details of cuts and combination interactions needed to specify the tire shape.