Short course of computer graphics, addendum: we treat according to the photo
A year ago I published a series of articles aimed at popularizing graphic programming. A lot of water has flowed under the bridge since then, an English version of the cycle appeared, which underwent some polishing compared to the original. This year several hundred people wrote to me, and many asked to help debug their code.
I suggest you play a game: I give only a picture on which the problem is visible, try to understand where in the code you need to look for a bug, what exactly is broken. I play this game every day, thoroughly watch hundreds of versions of the render, I have no way, so I, as a real psychic, fly through the photo. Often successful.
Absolutely all the pictures are not generated by me, I just collected the most typical bugs. The real human pain in front of your eyes, to me, of course, is addressed (especially by mail) only after they cannot find the bug themselves within a reasonable time.
')
Here is the first bug for the seed, on the left a broken render, on the right what was expected:
It is useful to know here that a person tried to make a shiny surface (specular map):
Ha, this picture is very similar to the previous one, but the bug is completely different (why?)
Here and below are pictures before and after debugging:
Attempt to apply normal map:
Incredibly, today I received exactly the same bug from a perfect other person, as we have already seen, with file parsing + a texturing bug!
Have fun!
I suggest you play a game: I give only a picture on which the problem is visible, try to understand where in the code you need to look for a bug, what exactly is broken. I play this game every day, thoroughly watch hundreds of versions of the render, I have no way, so I, as a real psychic, fly through the photo. Often successful.
Absolutely all the pictures are not generated by me, I just collected the most typical bugs. The real human pain in front of your eyes, to me, of course, is addressed (especially by mail) only after they cannot find the bug themselves within a reasonable time.
')
Here is the first bug for the seed, on the left a broken render, on the right what was expected:
Hidden text
The first hint: very round shape. Immediately he hints that instead of an array of vertices, a person has loaded an array of normal vectors, more precisely, he confused the lines “vxyz” and “vn xyz” from the .obj file
Hidden text
Triangles do not fit well with each other. In the wavefront .obj files, the array indices start with one, and not from zero, a person forgot to subtract one after reading the model file.
Hidden text
Note that all the triangles are in their geometric location, and the texture problem areas form full rings around one vertex, which hints that one vertex is periodically broken. So it was, there was a floating bug in reading textural indices.
Hidden text
In the picture, Guro's tinting, the filling of the triangle are clearly done using a scanning line, when the vertices are sorted according to their coordinates, and then the triangle is swept up with horizontal lines. The order of the peaks has changed, but the color of the peaks has been forgotten. Very frequent bug.
Hidden text
In the picture is a broken z-buffer. Almost the same as the previous bug, just forgot to change the z-coordinate of the vertices when sorting.
Hidden text
And again the same bug, but slightly in another place: when a triangle is swept up, for convenience it is divided into two parts, each horizontal line is drawn from left to right. Swapping the top of the line, they forgot about the texture coordinates.
Hidden text
Rounding errors, the scanning line game is explicitly calculated by interpolation, rather than directly making a sweeping cycle.
Hidden text
Again rounding errors, the screen vertices of the triangle were not rounded before rasterization.
It is useful to know here that a person tried to make a shiny surface (specular map):
Hidden text
It doesn't matter that a degree of zero gives a unit ...
Hidden text
Rasterization of the triangle is clearly done through the barycentric coordinates, and it would be nice to move them in a circle when calculating texture coordinates.
Hidden text
The texture clearly needs to be flipped vertically.
Ha, this picture is very similar to the previous one, but the bug is completely different (why?)
Hidden text
Instead of texture coordinates, the person simply used the xy of the current pixel to search for the color in the texture ...
Here and below are pictures before and after debugging:
Hidden text
The direction of the light was used to cut off the rear faces. But it would be necessary to look at the direction ...
Attempt to apply normal map:
Hidden text
Well, the color living in RGB [0,255] ^ 3 was converted to XYZ, living in [0,2] ^ 3, and not in [-1,1] ^ 3.
Hidden text
With flat shading, the light vector and / or the normal vector was not normalized, as a result, an attempt to draw colors with a value of more than 255, unsigned char overflow
Hidden text
Overflow is evident again, but this time negative values. Man forgot that the scalar product is negative. The picture on the right is fabs (intensity), the previous picture could be obtained if instead of fabs we used the usual clamp
Hidden text
Explicitly negative focus on the camera, the wrong sign was used in the formula (2)
Surprise
Incredibly, today I received exactly the same bug from a perfect other person, as we have already seen, with file parsing + a texturing bug!
Have fun!
Source: https://habr.com/ru/post/278309/
All Articles