Exercise 2: Diagnosing an "Inside-Out" Loaded 3D Model — Possible Solution
====================================================================

THE MOST LIKELY CAUSE
------------------------------
This chapter established that cross-product order determines which
direction a computed surface normal faces - edge1 x edge2 and
edge2 x edge1 point in exactly opposite directions. A model where
every surface's visibility is inverted (visible surfaces culled,
normally-hidden back surfaces shown) is the classic symptom of the
model-loading code computing each triangle's edges in the opposite
order from what the file format actually intends - for example,
computing edge1 = C-A and edge2 = B-A when the format's own vertex
winding order expects edge1 = B-A and edge2 = C-A (or vice versa).
Every single triangle's normal ends up pointing the wrong way, which
is exactly what would make an entire model appear inside-out rather
than just one or two surfaces looking wrong.

HOW TO CONFIRM THIS DIAGNOSIS
------------------------------
Take one specific triangle from the model whose correct, real-world
orientation is already known (for example, a triangle that should
face directly toward the camera in a simple test scene) and manually
compute its normal using this chapter's own cross-product formula,
edge1 x edge2, using the exact edge order the loading code uses.
Compare the sign/direction of that computed normal against the
triangle's known correct facing direction. If the computed normal
points directly opposite to the expected direction, that confirms the
edge order used during loading is reversed relative to what the
rendering pipeline (and the file format's own winding convention)
expects.

WHY THIS IS A BETTER DIAGNOSTIC THAN GUESSING AT A FIX
------------------------------
Simply trying "swap the edge order and see if it looks right" might
appear to fix the symptom, but manually computing and checking one
known-orientation triangle's normal directly - the same way this
chapter's own worked example verified its normal was perpendicular to
both edges via a dot-product check - confirms the specific root cause
(reversed edge order in the cross product) rather than masking it
with a compensating change elsewhere in the pipeline that could
reintroduce the bug or interact badly with a differently-wound model
loaded later.

WHY THIS WORKS AS AN ANSWER
------------------------------
The explanation identifies the specific, verified mechanism from this
chapter (cross-product anticommutativity flipping normal direction)
as the most likely cause of a whole-model inside-out symptom, and
proposes a concrete, chapter-consistent verification method (manually
computing one known triangle's normal and comparing it to the
expected direction) rather than a trial-and-error fix.