This is the original SWR_MODEL_Section5 (Note the broken offsets - please fix):

struct SWR_MODEL_Section5       // struct_V19
{
    uint32_t unk0;              // 0
    uint16_t unk4;              // 4
    uint16_t unk6;              // 6
    uint16_t unk8[2];           // 8
    uint8_t  unk12[4];          // C
    uint16_t unk16;             // E  //FIXME: Offset is bad!!! this is 0x10
    uint16_t unk18;             // 10 //FIXME: Offset is bad!!! This is 0x12
    uint16_t unk20;             // 12 //FIXME: Offset is bad!!! This is 0x14
    uint16_t unk22;             // 14 //FIXME: Offset is bad!!! This is 0x16
    uint16_t unk24;             // 16 //FIXME: Offset is bad!!! This is 0x18
    uint32_t offset_Section5_b[5]; // 1C
    uint32_t unk48;             // 30
    uint32_t unk52;             // 34
    uint32_t textureMaskAndIndex;// 38  0xFF000000 for having the mask.
    uint32_t unk60;             // 3C
} PACKED;

I found that it's addressed relative in the texture loader:

typedef struct {
  uint8_t unk_pad0[3]; // +0
  uint8_t unk3; // +3
} A1Unk;
typedef struct {
  uint8_t unk_pad_neg56[12]; // -56 (-14*4) // 0x0
  uint8_t unk_neg44; // -44 (-14*4 + 12) // 0xC
  uint8_t unk_neg43; // -43 (-14*4 + 13) // 0xD
  uint8_t unk_pad_neg42[2]; // -42 // 0xE
  uint16_t unk_neg40; // -40 // 0x10
  uint16_t unk_neg38; // -38 // 0x12
  uint8_t unk_pad_neg36[8]; // -36 // 0x14
  A1Unk* unk_neg28; // -28 (-14*4 + 28) //  0x1C
  uint8_t unk_pad_neg24[24]; // -24 // 0x20
  void* texture_data; // 0 [a1 points here] // 0x38
  void* optional_texture_data; // 4 [a2 should point here] // 0x3C
} A1; // Probably part of the model structure

How it is used in the texture loader:

 uint16_t v4 = swap16(a1->unk_neg40);

  if (a1->unk_neg28) {
    uint16_t v3 = swap16(a1->unk_neg38);

    // Get width and height as POT
    int v6 = sub_445C90(v4);
    int v7 = sub_445C90(v3);

    // Process texture data
    sub_445EE0(
      a1->unk_neg44, // ?
      a1->unk_neg43, // ?
      v4, // NPOT Width
      v3, // NPOT Height
      v6, // POT Width
      v7, // POT Height
      _a1, // Texture data
      _a2, // Optional texture data
      1, // ?
      a1->unk_neg28->unk3); // ?
  }

The new research reveals the following

Section5.offset_Section5_b[0] = Must exist or texture data will not be parsed correctly(?)
Section5.offset_Section5_b[0]->unk3 = Flags of some sort, only 0x10 and 0x01 are used. They seem to double the resolution vertically and horizontally (maybe to mirror / unfold textures while loading?).
Section5.unk16 = NPOT Width
Section5.unk18 = NPOT Height
Section5.unk12[0] = Something to do with texture, seems to control pixel format
Section5.unk12[1] = Something to do with texture, seems to control pixel format
Section5.textureMaskAndIndex = Index to texture and pointer to pixel data (section a) at load-time (unsure: might be replaced with other data later)
Section5.unk60 = Pointer to pixel data (section b) at load-time, presumably garbage if b == 0 (unsure: might be replaced with other data later)

(Where section a and b refer to the first and second section in the out_textureblock table)

Olganix / Sw_Racer

Section 5 research and guesses #3

The new research reveals the following