Hm, I'll refactor the methods to work inside the interleaved array with an offset and a stride then. That ought to get rid of most of the redundant data. Otherwise I'll try to use TWL's PNG decoder instead of BufferedImages if it works better.
I'm not too worried about the code but the whole idea of (for example) using 2Gb of ram while loading assets only to keep half of that or less once the GC kicks in.
For now I get the heights of the map by working inside the interleaved array. There is a DataMeshTerrain class that has a "getHeightAt" method that does the work around the array indices of the mesh (among other things). I don't know if its the most "elegant" way but it works for now.
Anyway, I'll still have to refactor everything again if I decide to implement a half edge structure someday
EDIT: Talking about the array. Turns up that working directly with it (interleaved or not) is kinda a mess for calculating normals. I have to write lots of boilerplate code since each corner of the map is a special case and each side of the map is a special case. Ends up beign 4 loops, one for each side, 4 directly calculated normals, one for each corner, and a single loop for the rest of the interior vertices. Its pretty fast but its like 150 or 200 lines long.
For doing it in a more "elegant" way I need to store some kind of adjacency data per vertex right? (so it ends up in a more simple "for each adjacent vertex do this")