Since OP seems mostly concerned on how to let TeX engines find font files. I'll put this at top. For TeX distributions that uses
kpathsea library, just look at
font/ directories in the paths listed by below command for tfm, vf, encoding files and font maps that are font files used by traditional TeX.
OSFONTDIR should be defined in
texmf.cnf or set as shell environment variable if you want to let XeTeX/LuaTeX/DVIPDFMx scan these locations to look for OTF/TTF files.
The "traditional" TeX uses only TFM file which contains only the dimensions of the font rather than the outline. These are listed in 4.3 Font information of the book TeX by Topic.
Then a DVI file is emitted and the respective driver (dvips for PostScript, or DVIPDFMx for PDF) picks up the PK (bitmap font generated by MetaFont), PostScript Type1 font, TrueType or OpenType according to the map file maintained by
updmap command in TeXLive distribution. The map file specifies the relationship between a TFM file, an encoding file, and the file actually contains outline like TTF or Type1. (Virtual font introduced more complexity to this process but the principle is the same, metrics, encoding, outline are associated together so the driver program can decide which glyph to use). An encoding file links the 256 different code positions of TFM file to the actual glyphs in the outline file, it is in a subset of PostScript and was designed for Type1 fonts, and each driver has slightly different method for interpretation to accommodate different font formats they support, e.g., pdfTeX has its own method to map names like
uniXXXX to unicode code points in TTF.
pdfTeX follows the similar procedures but it can handle Type1 and TTF on its own to produce PDF without the need of a external DVI driver program, and since OpenType is an extension of TrueType format pdfTeX can load OTF files that does not have many fancy tables.
pTeX lifts the restriction of the 256 code number limit in font and developed its own font metric format based on the fact that Kanji characters shares the same dimension to support Japanese typesetting and understands JIS encoding. upTeX enables automatically associate unicode to the code points in TTF/OTF fonts, so it can be used for CJK and certain Chinese users who prefer vertical typesetting would choose that.
dvips, DVIPDFMx, pdfTeX can share same set of font encoding files, but they all have their own quirks. dvips can only understand PostScript fonts (Type1 or Type3, which is also used to embed PK fonts). pdfTeX understands Type1 and TTF, but since it has limited support with TTF and have trouble with fonts in non-standard code schemes, sometime it is easier to convert the TTF file to Type1. DVIPDFMx understands many formats, and supports OTF, and in my opinion it is the best among them if you want to retain in the "traditional" font management method of TeX (mostly for taking advantages of virtual font) and it is the only choice if you are using upTeX.
XeTeX, LuaTeX are compatible with the TFM+Type1 method because the most widely used vectorized version of Computer Modern font is still in Type1 (in fact they incorporated most of pdfTeX features), but they also understand OTF (and hence TTF) and can directly load the font dimensions without the need of TFM, and they speak unicode so they also don't need encoding files to use modern fonts. They can utilize directly switch on and off OpenType features say, small caps. Their respective
\font commands are documented in their manuals and you can check them after having basic idea on how vanilla plainTeX deals with font (which can be checked in the TeXbook or TeX by Topic).