Vertex Array: Store or calculate?

[CombatWombat]

I'm partially just thinking out loud here, but definitely interested in suggestions...

Background
I have a game which is roughly tile-based.  More specifically, the *objects* of my game are made up of tiles, and can do the usual moving around the world that is expected of objects. 

So, I have defined my maximum object size to be 512x512 tiles.  In the future I would like to expand this to include some depth, but I'm keeping it simple for now.  Then I store tiles in "chunks" which are effectively just arrays of 16x16 tiles.  The chunks are then stored in a tree structure.  I currently have been able to render a single fixed chunk using vertex arrays, and it works good and fast, but I think my implementation will not work when expanded to full game size.

Question
How can I best handle my vertex arrays to render this type of "world". 

Option A:
Each chunk stores his own vertex array to describe his own geometry. 
Advantages:
The vertex array(s) need only be updated when something occurs which changes the chunk (tiles are added or removed).  Otherwise they carry over to the next frame.
Disadvantages
Enormous memory footprint.  Each tile needs (4)sf::Vertex, which works out to be 80 bytes(?)  When a tile's own footprint is only 2 bytes, and a world can have thousands or hundreds of thousands of tiles, this does not seem workable.  A 512x512 tree that is fully filled with tiles will be 20+MB or verticies, and only 524kB of tile data.  Seems redundant anyways, since every tile has the same geometry, just in a different position.

Option B:
Vertex array to describe all of the geometry is recreated each frame.
Advantages
Memory footprint problem is alleviated, since only geometry that is needed for drawing a given frame is created.
Disadvantages
The geometry needs to be recreated every frame.  Is this a heavyweight operation, or negligible? 

Option C:
As in Option B, except geometry from previous frame is cached for use next frame.
Advantages
Memory footprint as above.
Most frames, the geometry probably wouldn't change much, so this cuts down on recreating verticies that exist already.
Disadvantages
Detecting when recreation or editing of the vertex data is required sounds complicated and error prone. 
As the frustrum clips different geometry, the vertex data may change more often than anticipated.

Thoughts?  Am I reinventing square wheels again?

[eXpl0it3r]

Option B:
Vertex array to describe all of the geometry is recreated each frame.
Advantages
Memory footprint problem is alleviated, since only geometry that is needed for drawing a given frame is created.
Disadvantages
The geometry needs to be recreated every frame.  Is this a heavyweight operation, or negligible? 

I'm not quite sure why you'd need to recreate the geometry...

You usually have one sf::VertexArray that holds all the tiles, then you se sf::Sprite or your own entity class for players/enemies/moving things and if you want to scroll the screen you change the sf::View of the render target.
Or did I understand your game objects (i.e. 'tiles') wrong?

[Laurent]

This is the usual "memory vs performances" battle. You can't have both, saving one will usually result in a bigger usage of the other one. The right balance totally depends on your application and your needs. Only tests with real data will give you a relevant answer, there's no universal solution.

[CombatWombat]

You usually have one sf::VertexArray that holds all the tiles, then you se sf::Sprite or your own entity class for players/enemies/moving things and if you want to scroll the screen you change the sf::View of the render target.

Problem is that "all the tiles" could be hundreds of megabytes just in *verticies*, let alone actual object data.  Scrolling around with View is no problem, but that doesn't avoid the fact that either I have to save all of the geometry, or procedurally generate it as needed depending on what is inside the scene.

This is the usual "memory vs performances" battle.

At least it sounds like the methods I have presented are reasonable, and not completely out of left field.  I'm kinda new at this, so I was trying to make sure I was not missing some obvious solution.

Onward with the "procedural" vertex array, I think.