I spent a few minutes googling, and all I've learned so far is that:
- there isn't "baking", there's "texture baking", "light baking", and many other "<insert noun here> baking"
- it seems to mean any kind of precomputing stuff
- apparently the term was coined by Pixar in some paper
Correct. In this context it means turning the geometry into frame by frame mesh data so that your animation isn't dependent on anything like bones, cloth simulation, muscle/skin simulation, soft or rigid body dynamics, inverse kinematics in the rig, expressions on the bones of the rig etc.
Not only does it break dependencies, but it is also easier to get that geometry into another part of the pipeline like effects, lighting and even compositing.
The overall description of the scene, where the desk is, the lights and materials etc, could be stored in a USD scene.
Some tool would read this and generate an intermediate file in RIB format. This would be what a RenderMan renderer actually reads.
For the fluid sim itself, the generated RIB file might contain a reference to a plugin which points to the baked Alembic data, which would be a directory with one alembic file per-frame of mesh data representing the fluid surface.
RenderMan uses RIB files for its scene description and RIB files contain geometry. This means that one RIB file would typically contain a frame of data and source the shaders and textures from separate file paths.
If geometry wasn't baked in, then you would have a separate description of geometry (and everything else) as well as keyframes which are left to the client to interpolate.
Think of it as a HTML versus a screenshot. Both carry the same information, but for screenshot you don't need anything else apart from image viewer. For HTML you need parser, layout, render, whatever.. poor analogy, but hey.
USD is a next generation RIB, like OSL (done at sony) is next gen RSL. Both RIB and RSL stem from RISpec https://en.wikipedia.org/wiki/RenderMan_Interface_Specificat... which is a good intro to see what's being talked about here.
It means that the code/configuration used to produce a particular result (e.g. an animation sequence) isn't accessible anymore, but the result is.
For example, Houdini (http://www.sidefx.com) lets you procedurally animate 3D geometry, using a collection of nodes, scripts, etc. This is very useful for authoring, but is extremely heavy when all you want to do is render the resulting animation.
So, you "bake" the animation to a file (Alembic is a popular option today, which Houdini supports) and then you use the baked file during your rendering. None of the code and computation that produced the animation need to be available to the renderer.
Put another way: "baking" is the CG term for "memoizing" the result of a computational process.
It is often convenient, sometimes necessary to store point data into an off-line file for each frame of the animation. That point data is called a bake.or a point cache.
For instance if you do a simulation that takes 4 hours to solve you would absolutely want to bake out each frame of the point geometry. Then you can load that data into ram and play back the simulation inside of a modeling/animation program in real time.
There are many other uses for geometry baking.
Yes, it's a fancy word for that.
But when hearing that word (rather than 'precompute' or 'compile') it implies a few things.
Usually it means precomputing to a file rather than memory.
Mostly, but not always, baking implies generating a large amount of data from a smaller amount.
Typically the source description is for a whole sequence or animation, but the baked data will be a distinct set of data for each frame.