-
Notifications
You must be signed in to change notification settings - Fork 2k
Visual troubleshooting
This page is not meant to be a FAQ section; instead I show here several examples of bugs me and my students were able to fix without looking into the source code, solely by observing things in the images. No made up situations, real student pain is shown. The description of bugs is kept to a bare minimum, these images speak for themselves.
Frequent bug: while sorting by y-coordinate, the vertices are sorted, but the data coming with the vertices is not.
Bad y interpolation while sweeping the line:
The vertices were not casted to int prior to filling:
Forgot to decrement indices of vertices (remember in wavefront obj indices are starting from 1, not 0)
Few broken reads of texture coordinates, notice that all the fan of triangles incident to a vertex is messy, thus the vertex is broken:
All "v", "vt" and "vn" lines are read in the same array, thus effectively killing any sense in the model. Very roundish shape of the rendering gives the idea about "vn" confused with "v". Prior to the bugfix and after:
Frequent bug, anything elevated to the zero power equals to one:
This one needs a circular permutation of barycentric coordinates in the uv-interpolation:
The texture needs to be vertically flipped:
While visually ressembling to the above one, this one is completely different (why?). Here the student used xy pixel coordinates (instead of uv) to fetch a color from the texture :
Light direction (instead of view direction) was used for backface culling. Prior to and after bugfix.
Broken normal map reading, before and after. [0,255]^3 RGB were brought to XYZ living in [0,2]^3 and not [-1,1]^3.
Light and/or normal vectors were not normalized in computation of flat shading, resulting in overflowing unsigned char. Before/after images.
Same bug with textured model:
A bug correlated to above: trying to assign negative colors overflows unsigned chars. Dot product of two normalized vectors varies between -1 and 1. Here on the right fabs() of the intensity is shown, simple clamp at zero would produce right image of the above pair.
Negative focal length, clearly a bad camera coefficient c was used in formula (2)
Quote from here:
The code to render triangles to the screen takes a lot of computation time. While I was experimenting with more efficient methods, I commented out the code that calculates the barycentric coordinates, basically it finds out where to plot pixels of the triangle in the bounding box. It was replaced with a literal vector as a dummy output. As a result, all the pixels of the box are rendered, producing the voxel look. Given that it's a 3D renderer they are all still depth sorted and texture-colored. The last two pictures show the model with a SSAO post-effect using the depth buffer as a reference.