In the Draw Event, load 1 chunk each frame.
So the code gets executed every step.
In fact the main cause of lag was NOT the d3d_model definitions at all, which only took 0.3 seconds.
The d3d_model definitions take 0.3 seconds. (so far, in total when the game finished loading? or per frame? not clear)
because the extra loop only takes up 0.3 seconds of computation time.
apparently the d3d_model definitions are in the second loop. ok.
not per step, 0.3 seconds period.
so its 0.3 seconds in total? now we need to know how over how many frames this test was done. the 0.3 second metric is far from useful.
granted, it would still be a small portion of the 11 seconds. However 0.3 seconds per frame would have explained the awefull 1fps.
Please hammer about vertex buffers again, so I can shave off 0.3 seconds of computation time.
Actually, vertex buffers are not just a faster version of d3d_models
they allow you to do tricks when using normal buffers, greatly reducing the overhead when defining the heightmap.
If using a image heightmap, for example, you can convert the image straight into a buffer with all the height information you may need. (see
).
You can save and load buffers quickly (usefull if working with infinite terrain. see
)
You can even save and load asynchronously. making loading assets at load time far easier on your fps.
however, as with anything, buffers will only get you so far. Optimizing your algorithm is far more important. (unless you have image based heightmaps. check the first youtube link).
With procedural generation, most of the performance is probably lost there. however, you havent supplied us with much with regards to that.
Maybe if you could supply us with more information we can point you to the right direction.