I probably didnt' explain it enough. I know, how I have to store Vertices and Indices(I know a basic principles about storing data inside binary format).
I mean using strings(saved binary) to indicate which texture want mesh to use, or which effect I can apply on this mesh(or something like that).
Ohh yeah, well that's a place where I'm still thinking what to do. I (and probably you) have several options:
Serializing the objects directly (with material/mesh data). Bethesda Game Studios games (TES, Fallout) for example serialize .nif files, which are entire scene graph nodes, I'm guessing that at load time they just load the .nif file and plug the data directly in their scene graph.
Storing the mesh data as binary and the material data as an additional file (text, other binary, with markup language, etc).
Storing everything in a single YAML/XML file, maybe compressed with zip/gzip.
You can also index the materials so the files only store mesh data + material indices instead of storing the string name of the material (this one would need to be maintained but its probably the fastest to load).
You could also hash the texture file names and store the hash along the mesh data, that way when you load the mesh you could pass the hash to a texture/asset loader, and it will work out which texture path the hash relates to.
There are many options and tradeoffs between ease of use and faster processing.
