[HN Gopher] The Geometry Behind Normal Maps
       ___________________________________________________________________
        
       The Geometry Behind Normal Maps
        
       Author : betamark
       Score  : 99 points
       Date   : 2025-11-12 13:50 UTC (9 hours ago)
        
 (HTM) web link (www.shlom.dev)
 (TXT) w3m dump (www.shlom.dev)
        
       | zduoduo wrote:
       | Great article on tangent spaces! Could you explain how UV
       | distortion affects tangent vector calculation in more detail?
        
       | gm678 wrote:
       | Another great reference on this:
       | https://3dreference.notion.site/Texture-Types-15aef4826bf04d...
       | 
       | Note that normal maps are still widely used in PBR workflows. The
       | article doesn't mention them, but older renderers tended to use
       | diffuse, specular, normal maps, and modern asset creation
       | typically involves albedo, roughness/smoothness, metalness, and
       | ambient occlusion maps in addition to normal maps for textures.
        
       | delta_p_delta_x wrote:
       | > If we could afford a polygon for every pixel we wouldn't need
       | textures at all.
       | 
       | Heh; with mesh shaders and Nanite, we sort of can now. Whether
       | older GPUs can render them is a different matter altogether
       | though.
        
         | jesse__ wrote:
         | On a 1080p display, there are ~2M pixels; this is a totally
         | tractable number of triangles to do at 60fps even on cards that
         | are like 10 years old. If I remember correctly, a buddy of mine
         | was recently doing 6 million triangles in realtime on
         | integrated, which is absolute bananacakes. The compute-based
         | software rasterizers people are writing now (Nanite) target
         | triangles that end up being 2-4px on-screen, so we're talking
         | something on the order of 500k-1M triangles. Modern GPUs fart a
         | million triangles.
         | 
         | We've been in 'kind of can' territory for a long time in terms
         | of hardware capabilities. We're just now writing the software
         | to actually do it.
        
       | senderista wrote:
       | There are a couple of equivalent but complementary definitions of
       | tangent space used in differential geometry. One is that a
       | tangent vector at a point p is a directional derivative operator,
       | i.e. a local map from functions defined in a neighborhood of p to
       | numbers that is linear and obeys the Leibniz (product) rule of
       | derivatives. It turns out that any such operator can be
       | identified with some equivalence class of curves through p, which
       | is the second definition of a tangent vector: a set of curves
       | which define "the same" directional derivative operator.
       | 
       | I find the second definition more intuitive and easier to
       | visualize, while the first is more formal and algebraic. For
       | example, using the second definition it's easy to visualize the
       | pushforward T(V) (given a smooth map T) of a tangent vector V at
       | p to another vector U at q = T(p): picture a curve through p
       | corresponding to V mapped via T to a curve through q. That curve
       | defines the pushforward U = T(V). This isn't a substitute for the
       | algebraic definition of a pushforward, of course, but I find it
       | helpful. (The same approach is easy to extend to the pullback of
       | a 1-form.)
        
       ___________________________________________________________________
       (page generated 2025-11-12 23:01 UTC)