I only found this out because of peculiarities in the Nightfire BSP format I'm attempting to load. I'm not sure whether it occurs with Half Life BSPs (at least, I haven't been able to reproduce it yet), but nonetheless it should probably be fixed. I'll create a pull request today when I'm not in a rush.
Currently, vbotexture_t::len is used to accumulate the number of vertices from polygons that use this VBO. The length of thevbotexture_t::indexarray is then calculated as sizeof( unsigned short ) * 6 * len. However, when indices are added to the index array, there are 3(n-2) indices added for a face with n vertices (see R_AddSurfToVBO()).
Occasionally R_AddSurfToVBO() has overflowed the array for me. It would be better to keep a more accurate count when incrementing len - I have tested this locally and it seems to solve the overflow problem for me.
I only found this out because of peculiarities in the Nightfire BSP format I'm attempting to load. I'm not sure whether it occurs with Half Life BSPs (at least, I haven't been able to reproduce it yet), but nonetheless it should probably be fixed. I'll create a pull request today when I'm not in a rush.
Currently,
vbotexture_t::len
is used to accumulate the number of vertices from polygons that use this VBO. The length of thevbotexture_t::indexarray
is then calculated assizeof( unsigned short ) * 6 * len
. However, when indices are added to the index array, there are3(n-2)
indices added for a face withn
vertices (seeR_AddSurfToVBO()
).Occasionally
R_AddSurfToVBO()
has overflowed the array for me. It would be better to keep a more accurate count when incrementinglen
- I have tested this locally and it seems to solve the overflow problem for me.