17
0
mirror of https://github.com/MaSzyna-EU07/maszyna.git synced 2026-10-31 21:39:03 +01:00

fix(editor): a track dragged around no longer piles copies of its geometry up in the graphics memory

The geometry of a track made anew, ten times a second while it's
dragged, only forgot the chunks it had: the bank kept them all, so the
buffer of the section grew by the whole track and its neighbours each
time and was sent to the gpu in full again. Ten rebuilds of a test
scenery took the bank from 2 to 29 MB; a long session would run the
card out of memory. The old chunks are erased from the bank now, but
for those of a moving nose, laid again in place, and a moved traction
wire drops its old one too.

A chunk swapped for one without the extra vertex data kept the flag of
having it and the upload read from an empty array; the buffer is made
again when that changes.
This commit is contained in:
maj00r
2026-10-21 08:41:50 +02:00
parent 33892c1936
commit 8903d15b94
10 changed files with 55 additions and 1 deletions

View File

@@ -33,7 +33,8 @@ opengl33_vaogeometrybank::replace_( gfx::geometry_handle const &Geometry ) {
auto &chunkrecord = m_chunkrecords[ Geometry.chunk - 1 ];
chunkrecord.is_good = false;
// if the overall length of the chunk didn't change we can get away with reusing the old buffer...
if( geometry_bank::chunk( Geometry ).vertices.size() != chunkrecord.vertex_count ) {
if( ( geometry_bank::chunk( Geometry ).vertices.size() != chunkrecord.vertex_count )
|| ( geometry_bank::chunk( Geometry ).userdata.empty() == chunkrecord.has_userdata ) ) {
// ...but otherwise we'll need to allocate a new one
// TBD: we could keep and reuse the old buffer also if the new chunk is smaller than the old one,
// but it'd require some extra tracking and work to keep all chunks up to date; also wasting vram; may be not worth it?