Test allow larger vertex mesh

[adfriz]

Just a PR test for how capable current parser handling large mesh especially if in one meshbuilder contains the entire mesh.

Mainly tested in object viewer.

curently can load 250K triangle mesh, without texture, only single Color command.

But the memory usage when i try in release builds mode almost 1GB... idk why task manager report that... feels like memory leak or something allocated too much

Test file:
testA.zip

[leezer3]

There shouldn't be anything per-se stopping it with larger meshes IIRC, although the rest of things may not be so happy.

The X parser and MSTS shape parser definitely support larger.

FWIW, the new parser is slightly higher at ~1.3gb for your file, but I don't see anything immediately wrong per-se.

Most of our memory allocations come in the CreateVAO method:
https://github.com/leezer3/OpenBVE/blob/master/source/LibRender2/openGL/VertexArrayObject.cs#L190

[leezer3]

This is a finger in the air wondering at the minute:
https://stackoverflow.com/a/4973190/722627

No idea how that would perform, but it likely wouldn't have some of the internal list optimisations...
Being limited to .Net 4.7 is a little problematic for 'clever' solutions, but the WinForms menu is the big issue with moving onto something later.

[leezer3]

Interesting. Using that approach has basically no difference- shows that the people writing the CLR have probably thought of that.

Approximately 600mb of memory is being used by the normals generation though.
I suppose you could disable it for oversize models (pretty pointless unless you're hand-writing), but at the minute I suspect it's just a fact of life..

[adfriz]

i noticed it that early, accidentally pressed N to show the normals and the FPS drops below 10. so i suspect that maybe the cause.

already done some fixing locally about normals generation and memory usage, but im pretty sure there more to it...

[adfriz]

now the fps stable enough, and i have trim the vertex normals visual length a bit.
still get fps drop to 45 when too close to the mesh.

needs to sync with master...

[leezer3]

Yeah, I think that's just a case of too many total vertices though, probably pretty normal.

---

I've found one very minor memory leak in the fonts as a result of this, which master now fixes, but that's I think a GDI+ bug rather than us (returning the default typographic size should really use a shared object...)

The font subsystem itself is horrifically slow though, as it's doing some nasty concating to build the rendered strings. Replacing it is something I've looked at:
#1162

That works OK and is considerably faster (although would want rebasing to the current master, and probably some fixing), but it's somewhat limited as you can't easily choose the font, and you've realistically got to ship the font file with the build.
Not sure exactly how many people actually use custom fonts, but it was asked for at some point....

---

Anything else in terms of leaking appears to just be par for the course (first load of any object allocates a bunch of new strings for errors and stuff, which are then held by WinForms), and the GC sometimes takes a little while to get rid of the other bits.

[adfriz]

@leezer3 you can cherry pick the commit, my code is not the greatest anyway.

a note: i haven't fully test to the route viewer, but im pretty sure the code should works

[leezer3]

Done, although I've found a slight timing issue when creating on the main thread.

I'm considering at the minute whether it's worth adding a color dropdown for the normals. Issue with that is that you've gotta hack a combo-box to do it...