NIRT_FORMATTING(5)

πŸ“¦
version 7.44.0 Β· 2 versions
, in nixpkgs unstable

🌸 NAME 🌸

okay so bestie, welcome to the DRAFT!!! NIRT ...SPECIFICATIONS(5) page from BRL-CAD πŸ’… this is the nirt_formatting doc, and it’s all about the supported output formatting specifications for Natalie's Interactive RayTracer (NIRT). yes, Natalie’s. iconic name, iconic tracer. πŸŽ€


✨ OVERVIEW ✨

One of the most powerful features of Natalie's Interactive RayTracer (NIRT) is that it supports user-defined output formatting for its outputs. literally the glow-up your terminal output deserves. πŸ’–

The fmt command lets you change β€” on the fly β€” what gets printed and how it gets printed for the various values generated by shotline intersections. It uses a subset of the C/C++ printf format specifier syntax (the docs live at http://www.cplusplus.com/reference/cstdio/printf/) for flexible template specification, plus a series of pre-defined keys that specify individual elements of the generated results. iykyk. ✨

The general form of a fmt command is:

fmt 'char' "format string" [keys]...

where the "char" argument is replaced by a single character identifying the category of output the format string applies to. The "format string" is the printf style formatting string, and the keys will line up with format specifiers in the string the same way variables in C/C++ line up with specifiers in a printf format string. no cap, it’s giving very structured. 🫢


πŸŽ€ OUTPUT CATEGORIES πŸŽ€

NIRT offers seven categories of output reporting. seven! a whole lucky number situation. here’s the category cheat sheet:

  • Ray β€” char r β€” Report of ray information. The formatting associated with r will print once per ray, regardless of whether a region is encountered. main character energy: it shows up every time. πŸ’…
  • Header β€” char h β€” First output after a ray hits anything, typically used to identify columns in subsequent output. Printed once per ray. it’s the little column-label era. πŸŽ€
  • Partition β€” char p β€” Output for each region encountered by the ray. Typically this will be where most of the information about a model is reported. the info dump we deserve. πŸ’–
  • Footnote β€” char f β€” Last output statement after a ray hits anything; a "footnote" line after the ray has completed its evaluations. Printed once per ray. little closing credits vibe. ✨
  • Gap β€” char g β€” Output written once for each gap the ray may encounter. gap rights! πŸ¦‹
  • Miss β€” char m β€” If triggered, prints a message that nothing was hit; maximum once per ray. the sad little β€œoop, nothing” line. 😭
  • Overlap β€” char o β€” Output written once for each overlap along the ray. overlap girlies stay winning. πŸ”₯

πŸ¦‹ FORMAT STRINGS πŸ¦‹

NIRT's format specifications are a subset of those found in printf implementations. Specifically, the d, i, and f types are supported, as well as width and precision specifiers. that’s the whole menu β€” cute, focused, not trying to be everything. πŸ’…


πŸ’– REPORTING KEYS - CONNECTING DATA TO FORMAT STRINGS πŸ’–

Unlike the full C/C++ printf, NIRT accepts only pre-defined string keys that identify elements of specific information related to each category of output. no random variables, bestie β€” just the approved little key squad. 🫢

Ray information is consistent over an entire shot event, and therefore Ray keys may be used in all categories:

Table 1. Ray Variables

  • x_orig β€” x coordinate of ray origination point.
  • y_orig β€” y coordinate of ray origination point.
  • z_orig β€” z coordinate of ray origination point.
  • d_orig β€” d coordinate of ray origination point.
  • h β€” h coordinate for the entire ray.
  • v β€” v coordinate for the entire ray.
  • x_dir β€” x component of direction vector.
  • y_dir β€” y component of direction vector.
  • z_dir β€” z component of direction vector.
  • a β€” azimuth of view (i.e., of ray direction).
  • e β€” elevation of view (i.e., of ray direction).

Footnote and Miss categories have no particular keys unique to them, although they (like all categories) can use the Ray keys if desired. Partition, Overlap, and Gap, on the other hand, have keys that are unique to their contexts and valid only within those contexts:

Okay so here's the big one β€” Table 2. Partition Variables πŸ’– this is literally the whole roster of variables you can drop into a format string when you're reporting on a partition. Every one of these is at your service, bestie:

  • attributes β€” a string variable made up of the names and values of the attributes you asked for β€” the ones requested by the attr interactive command or the -A command line option. πŸŽ€
  • x_in β€” the x coordinate of entry into the current region.
  • y_in β€” the y coordinate of entry into the current region.
  • z_in β€” the z coordinate of entry into the current region.
  • d_in β€” the d coordinate of entry into the current region.
  • x_out β€” the x coordinate of exit from the current region.
  • y_out β€” the y coordinate of exit from the current region.
  • z_out β€” the z coordinate of exit from the current region.
  • d_out β€” the d coordinate of exit from the current region.
  • los β€” the line-of-sight distance through the current region. ✨
  • scaled_los β€” the scaled line of sight: the product of the line-of-sight distance through the current region and the region solidity (sometimes called "percent LOS"). Heads up though β€” "region solidity" here means a thickness equivalence factor, the kind often used to simulate material properties like density. Ngl that trips people up every time. πŸ’€
  • path_name β€” the full path name of the current region.
  • reg_name β€” the name of the current region.
  • reg_id β€” the region ID of the current region.
  • claimant_count β€” the number of regions claiming this partition β€” like, the regions participating in a retained overlap. πŸ‘‘
  • claimant_list β€” a space-separated list of the names of the regions claiming this partition (again: the ones participating in a retained overlap).
  • claimant_listn β€” same as claimant_list, except it's newline-separated instead of space-separated. Little glow-up, same energy. πŸ¦‹
  • obliq_in β€” the entry obliquity for the current region.
  • obliq_out β€” the exit obliquity for the current region.
  • nm_x_in β€” the x component of the entry normal vector.
  • nm_y_in β€” the y component of the entry normal vector.
  • nm_z_in β€” the z component of the entry normal vector.
  • nm_h_in β€” the h component of the entry normal vector.
  • nm_v_in β€” the v component of the entry normal vector.
  • nm_d_in β€” the d component of the entry normal vector.
  • nm_x_out β€” the x component of the exit normal vector.
  • nm_y_out β€” the y component of the exit normal vector.
  • nm_z_out β€” the z component of the exit normal vector.
  • nm_h_out β€” the h component of the exit normal vector.
  • nm_v_out β€” the v component of the exit normal vector.
  • nm_d_out β€” the d component of the exit normal vector.
  • surf_num_in β€” the entry-surface ID of the entry solid. 🌸

That's the whole set β€” no skipping, no cap. πŸ’…

  • surf_num_out β€” the exit-surface ID of the exit solid. That's the last one from the surface crew, bestie πŸ’…

πŸ¦‹ Table 3. Overlap Variables

Okay so these are the ones that fire when two regions are literally occupying the same space β€” overlap reporting. Iconic of nirt to snitch on them 🫢

  • ov_reg1_name β€” the name of one of the overlapping regions.
  • ov_reg2_name β€” the name of the other overlapping region.
  • ov_reg1_id β€” the region ID of one of the overlapping regions.
  • ov_reg2_id β€” the region ID of the other overlapping region.
  • ov_sol_in β€” the name of one of the overlapping solids.
  • ov_sol_out β€” the name of the other overlapping solid.
  • ov_los β€” the line-of-sight distance through the overlap. πŸ‘€
  • ov_x_in β€” the x coordinate of entry into the overlap.
  • ov_y_in β€” the y coordinate of entry into the overlap.
  • ov_z_in β€” the z coordinate of entry into the overlap.
  • ov_d_in β€” the d coordinate of entry into the overlap.
  • ov_x_out β€” the x coordinate of exit from the overlap.
  • ov_y_out β€” the y coordinate of exit from the overlap.
  • ov_z_out β€” the z coordinate of exit from the overlap.
  • ov_d_out β€” the d coordinate of exit from the overlap.

🌸 Table 4. Gap Variables

And these are for the gap situation β€” the lil empty stretches where your ray is just... traveling through nothing. Not a crisis, just a gap, and nirt is keeping receipts ✨

  • x_gap_in β€” the x coordinate of entry into the gap.
  • y_gap_in β€” the y coordinate of entry into the gap.
  • z_gap_in β€” the z coordinate of entry into the gap.
  • gap_los β€” the line-of-sight distance through the gap. πŸŽ€

that's the whole variable roster, bestie β€” surfaces, overlaps, gaps, all accounted for. nothing dropped, nothing skipped, everything in its exact spot πŸ’–

🧚 a lil sign-off

That's the page, fr fr 🌈 This one's a DRAFT!!! from BRL-CAD β€” yes, the manual itself is stamped DRAFT!!! and titled nirt ... specifications(5), lowercase and mysterious, main character energy only πŸ˜­πŸ‘‘

So go forth, format your little heart out, and remember: the vibe is a draft, the notes are legendary. periodt. πŸ’…πŸ¦‹

πŸ“¦ where this page comes from