1
\$\begingroup\$

I was just contemplating about why I improve performance by baking additional details into the object rather than just rendering the more detailed model. How does the GPU get to take a shortcut to render potentially the same amount of detail on screen, just because the detail is represented in a different way?

\$\endgroup\$
2
  • \$\begingroup\$ You may be confusing normal mapping with displacement mapping. Normal mapping does not define additional geometry information, it just alters the surface normals used for lighting.This is still expensive, but way cheaper than using that many triangles. \$\endgroup\$
    – LukeG
    Jan 20 '18 at 14:56
  • \$\begingroup\$ @LukeG Yeah I originally was going to say "bump mapping" but the wiki said "normal mapping" is the most common term for bump mapping. \$\endgroup\$
    – J.Todd
    Jan 20 '18 at 17:49
2
\$\begingroup\$

Reading the comments I think I've understood what @Viziionary was asking, and that's my answer:

First one of your assumption is wrong: normal mapping gives us just an approximation which is clearly visible on edges for examples, like @Sidar said, and like any other approximation is easy to compute.

Second the real point of the answer: 4M vertices will always be 4M vertices (which are more than the pixel on a 1080p screen) and each of them needs to be computed every frame, in the vertex shader. Instead the amount of pixel being drawn may vary a lot (they're generated in the rasterizer stage given the size of the triangles, which change with the distance, on the screen) but to reach the order of milions you need to draw you're model on the whole screen, thing that, in games, nether happens... So with normal maps you're computing only the information (level of detail) you need (the light on the visible pixels) based on the resolution of you're screen/distance of objects/visibility..., while with a detailed mesh you're always computing all the vertices, even if two of them are so close they will be rendered in the same pixel.

Not to mentions that if you move the work on you're pixel shader you can take advantage of things such early-Z (don't remember if this is its name) and other gpu/programming optimisations.

Sorry for the bad english. Hope I've been clear enough.

\$\endgroup\$
1
  • \$\begingroup\$ It all makes sense now \$\endgroup\$
    – J.Todd
    Jan 20 '18 at 17:46
3
\$\begingroup\$

The problem is that the density of your mesh needs to be higher. Which requires more computational power and memory ( also think of lower end targets/devices ). Additional not ideal for rigged meshes. Normal maps contain surface direction per pixels, the perpendicular direction of the position on the surface ( hence the name normal maps ). Each pixel represents a unit vector, not a color ( it makes a color but that isn't the intend ). With this information it's possible to fake light shading and give the illusion of depth/height similar to a dense mesh while keeping the mesh low poly.

It's fairly cheap to calculate the math in the shaders to get the final result affected by a normal map. Add on top that your mesh is actually pretty low poly in comparison it's a win win for your GPU.

To get a nice effect from your normal map your mesh still needs to have enough density. Normal maps don't curve well on hard edges and completely destroys the illusion.

Edit: I'm assuming you are using a lower poly version of your mesh. If not, that ain't right. Pretty much defeats the purpose otherwise.

Edit2:

https://en.wikipedia.org/wiki/Normal_mapping

enter image description here

4 million triangles vs 500 triangles. That's 0.0125% of the original.

\$\endgroup\$
7
  • \$\begingroup\$ Clear proof of OP's lack of research. \$\endgroup\$
    – Ocelot
    Jan 20 '18 at 9:17
  • 1
    \$\begingroup\$ Yeah I guess. But Im a generous god. \$\endgroup\$
    – Sidar
    Jan 20 '18 at 10:23
  • \$\begingroup\$ @Ocelot It wasn't my lack of research, thanks for being rude though. I was asking, since the GPU still needs to read the information in some way to render the correct topology, why a bitmap basis of topology information serves to be more efficient than the same information stored in a simply different format (vector). I was trying to understand down on the actual GPU processing level. \$\endgroup\$
    – J.Todd
    Jan 20 '18 at 10:57
  • 1
    \$\begingroup\$ @Sidar, but yes, more specifically, I'm thinking "Yeah, the system no longer needs to consider 4 million tris, but the topology information represented by those 4 million tris has to be represented in some way (as a bitmap, in this case), so now it seems to me you just have millions of pixels to processes for topology data rather than millions of tris.That's my curiosity, why the millions of pixels in a bitmap are easier for the system to read topology from than the millions of tris. \$\endgroup\$
    – J.Todd
    Jan 20 '18 at 11:03
  • \$\begingroup\$ @Ocelot Well I told you exactly why tho. More triangles means more work for the GPU. While with Normal maps interpolation and approximation of uv mapping ( and mip-mapping) are very forgiving and give convincing results. You're not always processing every texel in a map but you are definitely always processing the whole mesh even if parts are frustum culled or backface culled. And again memory concern is something you have to consider as well. If you can cut rastarization to a fraction, handle the effects with relative cheap calculations on a parallel processor you're gaining more actually. \$\endgroup\$
    – Sidar
    Jan 20 '18 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.