OP can simply take out all that code around the classical array and push all the vertex data to a vector and use the vector's size() (eventually * sizeof(vec3)) and data() method to obtain the needed info for the opengl apis. Same with index data. That would clear out many possible errors around the data handling.

And may even be, as others have pointed out in another thread, faster than a classical array.

14 minutes ago, Green_Baron said:

And may even be, as others have pointed out in another thread, faster than a classical array.

The underlying type of the vector is a contiguous classical array. How could it be faster?
Unless you reserve the size of the vector you also loose some performance in the reallocations (assuming it can't allocate the address space directly after the existing array).

I am heavily procrastinating ?

#include <iostream>
#include <vector>
#include <array>
#include <chrono>
#include <random>

int main(void) {
	std::minstd_rand ran;
	ran.seed(42);
	const size_t maxcount{10000000};

	auto start{ std::chrono::system_clock::now() };
	std::vector<long> victor(maxcount);
	for( size_t i{0}; i < maxcount; ++i )
		victor[i] = ran();
	auto end{ std::chrono::system_clock::now() };
	std::chrono::duration<double> diff{ end - start };
	std::cout << "Victor took: " << diff.count() << "sec" << std::endl;

	/* Stack overflow ! Array is on the stack i believe ...
	start = std::chrono::system_clock::now();
	std::array<long, maxcount> arny;
	for( size_t i{0}; i < maxcount; ++i )
		arny[i] = ran();
	end = std::chrono::system_clock::now();
	diff = end - start;
	std::cout << "Arny took: " << diff.count() << "sec" << std::endl;*/

	long *amy{ new long[maxcount] };
	start = std::chrono::system_clock::now();
	for( size_t i{0}; i < maxcount; ++i )
		amy[i] = ran();
	end = std::chrono::system_clock::now();
	diff = end - start;
	std::cout << "Amy took: " << diff.count() << "sec" << std::endl;
	delete [] amy;

    return EXIT_SUCCESS;
}

This is at least not decisively slower ?

But check out with your implementation of vec3, inline constructor, and all that ...

They're more or less equivalent, as you're pre-allocating the std::vector to the exact size you want it to be. Only issue is that you're not using pushback, which means you're indexing past the size of the vector. It's still valid memory so it won't crash though.
std::vectors main drawback is reallocation, that and potentially allocating more memory than it needs (since it doubles in size).
My other mesh generators pre-calculate the amount of verts they'll be generating and allocating that exact amount of memory. The tree generator was still in its infancy so just used a std::vector as a temporary fix. Plan is to add branches using a branching recursion algorithm. Not sure how that'll work out though.

12 minutes ago, Net-Ninja said:

... Only issue is that you're not using pushback, which means you're indexing past the size of the vector. It's still valid memory so it won't crash though....

I don't understand ...

template <typename T>
struct Vector
{
	T* data;
  	size_t size;
  	size_t capacity;
  	void PushBack(T val)
  	{
  		if(size == capacity)
  			// double the data allocation
  		data[size++] = val;
  	}
}

If you don't use pushback the vector will thing you've used less than you have. The capacity is reserved up to maxcount so the allocation is of that size (at least) so when indexing into it you're still indexing into valid memory. But if you change the for loop to use the Size() method I think it will thing the size is 0.

Ah, sorry. Seems like std::vector doesn't work like that. Our in house implementation does which is why I got turned around. We just reserve an allocation of count elements, and then do the insertions after.