ATTRIBUTES(5)

📦
version 7.44.0 · 2 versions
, in nixpkgs unstable

💅 STANDARD ATTRIBUTES(5) 💅

BRL-CAD Standard Conventions ✨ (that's the fancy subtitle up in the header, bestie — the man page name is STANDARD ATTRIBUTES(5) and the section is 5, as in file formats and conventions, iykyk)

🎀 NAME 🎀

attributes — the standard attribute conventions in BRL-CAD databases, fr fr 👑

🦋 BACKGROUND 🦋

okay so, story time, because this one actually has lore 🌸

Starting with BRL-CAD database format version 5, BRL-CAD supports storing arbitrary attribute/value data on any database object. literally any object, any attribute, go off 💅

But before that generic ability existed, BRL-CAD already had a set of standard attributes it used to hold key info about specific properties. and the way these conventions predate not just the version 5 database format but BRL-CAD itself?? iconic. genuinely older than the thing they live in 😭

So the purpose of this man page is to:

  • identify the standard attributes 🔥
  • document situations where two or more attributes are used to identify the same property (yes, duplicates, we love a legacy moment)
  • and identify, where appropriate, what actually constitutes meaningful values for an attribute 💖

🧚 the ancestral lore drop 🧚

The earliest ancestor of BRL-CAD was the MAGIC code, written by the Mathematical Applications Group, Inc. in 1967 to implement geometric modeling ideas developed by BRL and AMSAA from 1958-1967. that system was entirely non-graphical 💀 no pixels, just vibes and math.

Some years later it was followed by the GIFT program — that's Geometric Information From Targets 🎯

Then LIBRT, appearing around 1983, became the successor to GIFT. And today LIBRT is the core library of the BRL-CAD solid modeling package 👑 main character energy honestly.

For more background (and if you're a nerd like me, you are), see:

http://ftp.arl.army.mil/~mike/papers/96thebook/

LIBRT inherited both geometric primitives and attributes from GIFT — and that heritage is occasionally apparent in attribute names 🫶 like yeah bestie, the name is weird because it's ancestral, leave her alone.

⭐ core vs. non-core, the distinction that matters ⭐

Note that with the introduction of support for arbitrary attribute/value pairs it becomes much simpler for both developers and users to formulate new standards of their own for storage of metadata in attributes. 💀 (yes, that means you can just... make your own. do with that what you will.)

But — and this is the vibe check — attributes should only be documented in this file if one or more core BRL-CAD tools has implemented one or more features that require specific attributes to be present. Like, if a tool doesn't need it, it does not belong in here, periodt 🙈

Conventions for attribute names that do not involve tool support should be documented in appropriate user-level documentation instead ✨

And in documenting attributes, one additional distinction gets made:

  • non-core attributes — attributes that exist only as post-v5 attribute/value pairs 🌈
  • core attributes — the older attributes (which may also be represented in core data structures) 💜

so yeah, that's the whole setup. two little buckets, and everything gets sorted into one of them 🎀

✨ STANDARD (CORE) AND REGISTERED ATTRIBUTES ✨

okay so bestie, this is the master list 💅 the table below has every known standard (core) BRL-CAD attribute plus all their aliases. Think of it as the group chat roster of attributes — everyone who's anyone is here.

⚠️ real talk though: any code that sets or reads the value of one of these attributes must handle all the aliases, so that every function asking for that value gets a consistent answer. no cap, that's the whole rule. if you only handle one alias, you're gonna have a bad time 😭

🎀 Table 1. Standard (Core) Attributes List 🎀

  • region — the Region Flag 🚩 · Is Binary: 0 · Definition: boolean · Example: Yes, R, 1, 0 · Aliases: none
  • region_id — the Region Identifier Number 🔢 · Is Binary: 0 · Definition: an integer · Example: 0, -1, and positive integers · Aliases: id
  • material_id — the Material Identifier Number 🧱 · Is Binary: 0 · Definition: zero or positive integer (user-defined) · Example: (none given) · Aliases: giftmater, mat
  • material_name — the Material Name ✨ · Is Binary: 0 · Definition: empty or content-filled string (user-defined) · Example: (none given) · Aliases: material
  • aircode — the Air Code 🌬️ · Is Binary: 0 · Definition: an integer (application defined) · Example: '0', '1', or '-2' · Aliases: air
  • los — the Line of Sight Thickness Equivalence 👀 · Is Binary: 0 · Definition: an integer in the inclusive range: 0 to 100 · Example: '24' or '100' · Aliases: none
  • color — the Color 🌈 · Is Binary: 0 · Definition: a 3-tuple of RGB values · Example: "0 255 255" · Aliases: rgb
  • shader — the Shader Name 🦋 · Is Binary: 0 · Definition: a string of shader characteristics in a standard format · Example: (none given) · Aliases: oshader
  • inherit — Inherit Properties 🫶 · Is Binary: 0 · Definition: boolean · Example: Yes, 1, 0 · Aliases: none
  • mtime — the Time Stamp ⏰ · Is Binary: 1 · Definition: a binary time stamp for an object's last mod time (the time is displayed in human-readable form with the attr command) · Example: (none given) · Aliases: timestamp, time_stamp, modtime, mod_time, mtime

Given how important these bad boys are, it's appropriate to briefly outline the meaning and purpose of each one. let's get into it 🧚

region

The Region Flag identifies a particular geometric combination as being a solid material. In other words: any geometry below this combination in the tree can overlap without that overlap being regarded as a non-physical description, since it's the combination of all descriptions in the region object that defines the physical volume in space. slay, that's the whole point 💅

region_id

The Region Identifier Number identifies a particular region with a unique number. This lets multiple region objects be regarded as being the same type of region, without requiring that they be included in the same combination object. iconic behavior honestly 👑

material_id

The Material ID Number corresponds to an entry in a DENSITIES table, usually contained in a text file. That table associates numbers with material names and density information used by analytical programs such as rtweight.

material_name

The Material Name corresponds to an entry in a DENSITIES table or material objects, usually contained in a text file that are imported through the material command. This table associates numbers with material names and density information used by analytical programs such as rtweight. (yes, it's basically material_id's twin — they're giving matching outfits 🎀)

aircode

Any non-zero Air Code alerts the raytracer that the region in question is modeling air, which is handled by specialized rules in LIBRT. 🌬️

los:, color:, shader:

LIBRT can use a variety of shaders when rendering. This attribute holds a text string which corresponds to the name and other details of the shader to be used. 🌈

inherit

The Inherit Properties value, if true, indicates all child objects inherit the attributes of this parent object. 🫶

mtime

💀 okay so the original literally just says mtime: and then… nothing. no definition. that's it. that's the whole entry. the manpage gave up mid-sentence and honestly? relatable. not me inventing content for it, so this is all you get, iykyk.

🌸 SEE ALSO 🌸

  • attr(n) — go read this one next bestie, it's the whole vibe

💜 AUTHOR 💜

BRL-CAD Team 🫶

This software is Copyright (c) 2010-2026 United States Government as represented by the U.S. Army Research Laboratory.

🐛 BUG REPORTS 🐛

Reports of bugs or problems should be submitted via electronic mail to devs@brlcad.org 📧

and that's the tea 🍓 — this page comes to you from BRL-CAD, filed under STANDARD ATTRIBUTES(5), with the date slot in the footer doing a little disappearing act so i'm not gonna make one up 🙈 mwah, go handle your aliases 💋

📦 where this page comes from