The model for coins in Super Mario Odyssey is simpler than in Super Mario Galaxy

That said... how is this news, exactly? Bump/normal mapping was a novel, new fangled technique back in the late 1990's... In its original form, it actually predates programmable GPUs.

The most "pure" way to do a "no mesh" render would probably be to use geometry shaders to emit your geometric primitives. (You do need to give it at least one "starting" primitive to make the draw call, but you're free to entirely ignore that primitive). It'd be trivial to embed some mesh data into a "texture", for example, just by reading vertex xyz positions into the rgb channels of a 1D texture that's `number_of_triangles*3` elements wide, and your geometry shader could walk along that texture and output those vertices and triangles and have them get rendered, without ever accessing a vertex buffer object.

That way you only need point positions in the mesh, and no UV or normals.

However, I think (at least in games: in VFX we go the other way and have many many "primvars" as vertex/point data) most real-time setups for hero objects end up having points and UVs, and then normals are normally done as a texture.

Technically you could distort the UV map if you need variable resolution across a model.

I thought octrees solved this?

The normal map probably takes up slightly more memory than all the geometry that is in the more complex model, but the more complex model causes the gpu to render a lot more triangles which is a lot more work. Looking up values in the normal map is something the gpu is very good at.

Not to imply people don’t read the articles here. I would never imply that…

This is interesting to consider, as it never occurred to me that anyone would think otherwise.

I wonder if it's generational. Those who grew up with games whose triangle (or quad, in the case of a certain Sega system) budgets were constrained to the point of clearly distinct mesh faces probably have a different mental model from those for whom baked normals and LOD meshes have always been a continuum.

Maybe take the rest of the day off? Work through the anger?

The "hardware stuff" is automatic and hard coded. Modern pipelines added more steps / complications (Geometry shaders, Tesselators, etc. etc.), but the Vertex Shader / Pixel Shader steps have remained key to modern graphics since the early 00s.

-------------

"Vertex Shader" is a program run on every vertex at the start of the pipeline. This is commonly used to implement wind-effects (ex: moving your vertex left-and-right randomly to simulate wind), among other kinds of effects. You literally move the vertex from its original position to a new one, in a fully customizable way.

"Pixel Shader" is a program run on every pixel after the vertexes were figured out (and redundant ones removed). Its one of the last steps as the GPU is calculating the final color of that particular pixel. Normal mapping is just one example of the many kinds of techniques implemented in the Pixel Shading step.

-------------

So "Pixel Shaders" are the kinds of programs that "compute a hologram on a flat surface". And its the job of a video game programmer to write pixel shaders to create the many effects you see in video games.

Similarly, Vertex Shaders are the many kinds of programs (wind and other effects) that move vertices around at the start of the pipeline.

Wikipedia has a little video showing the effect of parallax mapping in action: https://en.wikipedia.org/wiki/Parallax_mapping

Another good example: https://doc.babylonjs.com/features/featuresDeepDive/material...

And there's a decent explanation here: https://learnopengl.com/Advanced-Lighting/Parallax-Mapping

Some game examples: http://wiki.polycount.com/wiki/Parallax_Map

Some nice game examples, specifically with looking into windows: http://simonschreibt.de/gat/windows-ac-row-ininite/

Basically, in terms of levels of realism via maps, the progression goes

1. Bump mapping: the shader reads a heightfield and estimates the gradients to compute an adjustment to the normals. Provides some bumpiness, but tends looks a little flat.

2. Normal mapping: basically a variant of bump mapping -- the shader reads the adjustment to the normals directly from a two- or three-channel texture.

3. Parallax mapping: the shader offsets the lookups in the texture map by a combination of the heightmap height and the view direction. Small bumps will appear to shift correctly as the camera moves around, but the polygon edges and silhouettes usually give the illusion away.

4. Parallax occlusion mapping: like parallax mapping, but done in a loop where the shader steps across the heightfield looking for where a ray going under the surface would intersect that heightfield. Handles much deeper bumps, but polygon edges and silhouettes still tend to be a giveaway.

4. Displacement mapping: the heightfield map (or vector displacement map) gets turned into actual geometry that gets rendered somewhere further on in the pipeline. Pretty much perfect, but very expensive. Ubiquitous in film (feature animation and VFX) rendering.

------

IMO, its important to understand the limitations of pixel shading, because its an important step in the modern graphics pipeline.

It's hard to say without realistic benchmarks on Wii and Switch hardware.

Unarguably it's also more processing power than its predecessor which appeared to be untextured. Far more FLOPs are executed at the fragment level than at the vertex level, and that will vary with how much the model takes up on the screen. But more bang for buck than geometry alone? Can't disagree with that.

Don't disagree with that, just the claim that the model is simpler.

> Depth pass, culling, transforming between coordination systems, all care about the poly count

At a guess a dynamic asset like this would be frustum or occlusion culled by bounding box, which doesn't scale with geometry count. Depth pass happens at draw time. But yes, there would be more vertices to transform. Moving geometric details to shaders is a trade-off between either being fill-rate or vertex bound.

- max area: ~2600 fps

- fan: ~860 fps

So it still holds true.

https://www.nintendoworldreport.com/guide/1786/gamecube-faq-...

Quite often it’s not even a question of the GPU itself but the development pipeline and the tooling used. As well as ofc does the engine itself supports it.

Also at the end of the day your GPU has finite amount of compute resources many of them are shared across various stages of the rendering pipeline even back at the 6th and 7th gen of consoles where fixed function units were far more common.

In fact in many cases even back then if you used more traditional “fixed function pipelines” the driver would still convert things into shaders e.g. hardware T&L even on the Wii was probably done by a vertex shader.

Many teams especially in companies that focus far more on gameplay than visuals opted out for simpler pipelines that have fewer variables to manage.

It’s much easier to manage the frame budget if you only need to care about how many polygons and textures you use, as if the performance is too low you can reduce the complexity of models or number/size of textures.

Shaders and more advanced techniques require far more fine grain optimization especially once you get into deferred or multi pass rendering.

So this isn’t hardware, it’s that the team behind it either didn’t want or didn’t need to leverage the use of normal mapping to achieve their design goals.

Some exec from Nintendo is on record as saying something along the lines that texture mapping looks bad and should be avoided. My conspiracy theory is that it was a conscious decision at Nintendo to limit the ability of its consoles to do stuff with textures. The N64 was even worse, a lot worse: it only had 4kB of texture cache.

The bumpmapping hardware most wikis mention as "supporting normal mapping" is pretty much irrelevant.

The G400 was generally lackluster at 3d performance, so the feature didn't really get used by games.

If you were coming to it from the PS2 (like I was), it was super-freeing and amazing and so much more flexible and powerful than anything you were used to. But if you were coming to it from the Xbox (like many of my co-workers were) it was more like suddenly being handcuffed.

That hasn't been true for many years.

> as you'd use more vram when using textures

For the equivalent amount of detail, not really. Vertices are expensive, normal maps are encoded very compactly.

First, modern GPUs are capable of handling millions of triangles with ease. Games are almost never vertex bound. They are usually pixel bound or bound by locking. In other words, too many or too costly of pixel operations are in use or there is some poor coordination between the CPU and GPU where the CPU gets stuck waiting for the GPU or the GPU is underutilized at certain times and then over burdened other times.

Adding two maps adds two texture fetches and possibly some blending calculations. It's very hard to weigh the comparable impact because different situations have a huge impact on which code gets executed.

For a model with many triangles, the word case scenario is seeing the side of the model with the most faces. This will cause the most triangles to pass the winding test, occlusion tests, frustum tests, etc. This will be relatively the same regardless of how close the coin is to the camera.

For the normal mapped test, the worst case scenario is when the coin fills the view regardless of its orientation. This is because the triangles will then be rasterizied across the entire screen resulting in a coin material calculation and therefore the additional fetches for every pixel of the screen.

Also, when it comes to quality, normal maps have a tendency to break down at views of high angular incidence. This is because though the lighting behaves as expected, it becomes clear that parts of the model aren't sticking up and occluding the coin. This means such maps are a poor solution for things like walls on long hallways where the view is expected to be almost perpendicular to the wall surfaces most of the time.

There is a solution called Parallax Occlusion Mapping. Though it is expensive and I don't see it in a lot of games.

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

https://www.youtube.com/watch?v=0k5IatsFXHk

You'd have a bad time including all of that in the actual model.

True for the CPU, but quite unfair to the Wii's ArtX GPU, which was substantially faster and more featureful than the ATI r128 in the PB G3.