4 ms·

There are some cases where you can't share vertices. For example, flat shading with face normals. So now you need to put that normal data into every vertex and

by hrjet 12y ago

There are some cases where you can't share vertices. For example, flat shading with face normals. So now you need to put that normal data into every vertex and you have to duplicate vertices as well, which is 9x data for a very common use-case.

flohofwoe 12y ago
True, but I don't know any 3D API which allows this except for the OpenGL 1.x style glBegin/glEnd which doesn't map to an efficient hardware implementation. This specific problem can be solved by not fetching per-vertex normals at all, and compute the face normals on the fly in the geometry shader, not sure whether this is worth it though, geometry shaders have a reputation for being nearly useless.
exDM69 12y ago
> For example, flat shading with face normals I see your point, having interlaced vs. non-interlaced data arrays. Many 3d model interchange formats use the latter because it saves some bytes. All 3D APIs use the former. But this example works exactly the same way on every 3d API out there. Having a single index per vertex (rather than separate indices into position, normal, texcoord arrays) simplifies the vertex pipeline a little bit. Using a single index will also make more efficient caching of vertex data and post-transform caching (ie. output of vertex shaders are cached if possible). Separate indices would need more complicated cache addressing. Of course, with modern OpenGL, you can do more complicated addressing of data in the vertex shader. This isn't likely going to increase performance, though. However, this is largely a non-issue. Modern 3d graphics simply isn't limited by the number of vertices or triangles. Having to duplicate some data isn't going to make a significant difference in practice. Also, you can toggle the interpolation mode for varying variables (ie. fragment shader inputs) so you can use per-vertex normals and make them flat shaded if your whole model is going to be flat shaded.

by hrjet 12y ago

flohofwoe 12y ago

True, but I don't know any 3D API which allows this except for the OpenGL 1.x style glBegin/glEnd which doesn't map to an efficient hardware implementation. This specific problem can be solved by not fetching per-vertex normals at all, and compute the face normals on the fly in the geometry shader, not sure whether this is worth it though, geometry shaders have a reputation for being nearly useless.

exDM69 12y ago

> For example, flat shading with face normals I see your point, having interlaced vs. non-interlaced data arrays. Many 3d model interchange formats use the latter because it saves some bytes. All 3D APIs use the former. But this example works exactly the same way on every 3d API out there. Having a single index per vertex (rather than separate indices into position, normal, texcoord arrays) simplifies the vertex pipeline a little bit. Using a single index will also make more efficient caching of vertex data and post-transform caching (ie. output of vertex shaders are cached if possible). Separate indices would need more complicated cache addressing. Of course, with modern OpenGL, you can do more complicated addressing of data in the vertex shader. This isn't likely going to increase performance, though. However, this is largely a non-issue. Modern 3d graphics simply isn't limited by the number of vertices or triangles. Having to duplicate some data isn't going to make a significant difference in practice. Also, you can toggle the interpolation mode for varying variables (ie. fragment shader inputs) so you can use per-vertex normals and make them flat shaded if your whole model is going to be flat shaded.