I'm reading a book on computer graphics, and at some point, it shows a 3D model, created from a .dat file.
Here are a few rules for the .dat file creation:
I want to know if this is the standard, and if not, what is the standard way of defining a 3D object.
Also, if there is a specification, who defined it and where to find it?
When talking about file formats, we are talking about persisting some data related to a 3D model/geometry. There is no universal standard on file formats for persisting 3D geometry. There are only a few formats more dominant than others.
Just as it is with image file formats, the PNGs and JPEGs are the most common formats out there today, but there is no universal agreement between applications on using one or the other. Each app uses the best fit for its purposes.
The same happens with file formats storing 3D data. Each 3D modeling software will generally have one or a set of preferred formats. Most actually define custom formats that only work with the specific version of the tool. This can happen for many reasons, from simplifying the inner workings of the application, or making loading of files faster, to binding the user to a given tool on purpose.
This .dat format you describe is a custom format created by the authors of the book, which was probably designed with simplicity in mind. It seems to be a text file similar to the Wavefront OBJ format, which in turn is a very popular format for storing static geometry, though a bit outdated by now. One could say that the .OBJ format is the .BMP of 3D model formats.
Other popular 3D model formats include:
And many others. More general explanation here.
Also note that I said at the beginning that these are formats for storing/persisting a 3D model or geometry on an offline storage. It doesn't mean (and it usually isn't the case) that the applications that use them will store the data internally in memory using the same layout as the file. Normally, this kind of data will undergo a lot of processing after being loaded from a file until it is, for instance, displayed on the screen.
There is not a single standard that defines the storage of 3D models. The graphics API only cares about triangles, which are defined by vertices and indices indicating which vertices form a triangle.
Many companies have created their own model formats with different features and goals. One of the simplest is the .obj (Wavefront Object) format. Which contains lists of vertex positions, normals and texture coordinates and a list of indices that make up the triangles. It also contains materials, with some basic properties as textures, diffuse and specular colors.
More advanced model formats, such as .fbx (FilmBox) used by Autodesk contain additional information required by the modeling software. These might include bones, hierarchies and even more vertex properties used for skinning etc. So there are "standards", but they are not really unified as every program might require different information. But wavefront is a very good choice, because many modelling applications can export to it and it is easy to write (find) an importer for.
There is no standard format for 3D models. Some common ones are listed in glampert's answer, more can be found in this SE answer.
If you are designing your own format for your own purposes, (a fairly common thing to do, actually) it's a good first step to look at how you are using your model data. For example, if you are focused on rendering, you can use the format that the graphics library expects. If you want to reduce the load time of your software as much as possible then reducing the amount of parsing and processing you have to do can help. A simple utility that can output a file in the format that your engine expects will mean you can simply map the file into memory and then pass a pointer into your graphics library.
On the other hand, if rendering is not your main concern and editing is more important to you, you might consider a format more amenable to editing, such as winged edge. Using a general purpose model format may suit your purposes at the beginning of a project, but ultimately there are many things you can do with 3D models and each format has its own benefits and drawbacks, so you can choose the one that works best for you.
As other answers have mentioned, there are multiple competing formats for storing 3D data.
However, one specific format has appeared since this question was asked, that has many characteristics you'd expect from a "standard": the glTF format.
glTF is a 3D standard published by the Khronos Group (the organization behind OpenGL and Vulkan), that aims to make up for the flaws in Collada.
Its main advantages are:
It's JSON-based, which makes it very easy to parse, serialize, read, and send over network.
There is very little ambiguity or redundancy in the standard (though there is some*). The units, handedness, texture coordinates signs, etc are all standardized; everything is always index-based, which means there is no data redundancy. This makes it really easy to write an importer.
The documentation is very clean and exhaustive.
The layout of the data is based on the OpenGL/WebGL workflows, which means that imported models can be used as in-engine data with little plumbing.
The standard is Open Source, and the specification is hosted on Github. That means the standard will always be available, usable for free, and the development process is visible to everyone. By opposition, the future of closed-source standards is decided by private interests, which is inherently dangerous.
glTF is supported by many industry giants through Khronos (Adobe, Google, Microsoft, Mozilla, Unity); it can be exported by Blender (exporting from Maya is still officially unsupported), and imported by Unreal, Unity and Godot.
See also:
* I'm pretty sure the variable-handedness tangents are pointless.
To add to other answers, there are actually two kinds of formats, intermediate and runtime. Intermediate formats (example: COLLADA) are more verbose/slower and are converted between tools ultimately to the custom runtime format that is optimized for a specific application/hardware. Simple applications that do not care much about performance can directly use intermediate formats.
