Yeah, a few of the exporters which we didn't write will need updating, I was hoping people would pick up on them from the new snapshot. I'm trying to resolve a D3D7 problem and write a tutorial on the VBO changes (which should hopefully help with your confusion).
Once you understand the VBO structures I'm sure you won't find it hard to update the exporter. In many ways they're easier to use than the old GeometryData because they're more explicit about vertex formats (wheras these were implied previously by pointers and stride values). If you look at the existing code you'll find the same pattern everywhere. To help get you started before I finish the tute, here's a potted sequence:
Create a VertexData structure either on the Mesh or on the SubMesh depending on whether the SubMesh uses shared geometry (this option has the same effect as before)
Update the vertex declaration on VertexData to reflect the elements of the vertex. This is done by calling 'addElement' once per vertex element (e.g. positions, normals etc).
Each element has 5 important attributes.
1. The 'source' is the buffer the data comes from (as an index, not a pointer, because you can re-bind vertex buffers without changing the element)
2. The 'offset' is the byte offset from the start of a vertex at which this element starts. This is only > 0 if a single buffer contains multiple elements.
3. The 'type' is the data format. For example positions are normally VET_FLOAT3. This is used for sizing and to allow different dimensions of data to be used than just x,y,z. It is separate from the semantic (see below) because this is important for future shader support - some shaders might accept 4D vertex positions, for example.
4. The 'semantic' is the meaning of the data, ie is it a position, a normal, a texture coordinate etc. The use of enumerated semantics rather than predefined named pointers allows for significantly more flexibility now and for the future (cards are already starting to accept new semantics like patch data)
5. The 'index' is optional and applies if you're supplying more than one element of the same semantic, e.g. multiple texture coords or indeed multiple positions (for vertex shader interpolation).
Once you've defined the vertex declaration, you need to create the vertex buffers, you do this using HardwareBufferManager. Notice that you only need to supply the number of vertices and the size, not the vertex format; this is because the buffer is independent of the format, again for flexibility since you can use the same buffer to supply data to multiple declarations if you so wished. Buffers are reference counted so they delete themselves when all users have finished with them. The docs explain the 'usage' parameter, but for an exporter you don't need to worry about it because you'll be using the base buffer manager (DefaultHardwareBufferManager - you should create this in your exporter) which creates buffers in software with no restrictions.
You then need to 'bind' the buffer(s) to the indexes referred to in the 'source' values of the vertex element using the setBinding method on VertexData's vertexBufferBinding member.
Now set the vertexStart and vertexCount members of VertexData which describes the subset of the buffers you're planning to use. In a simple case this is just 0 and the vertex count of your model.
Now set up the IndexData on the SubMesh (no need to create, all SubMeshes create their own). This is simpler, just an indexStart and indexCount, and an indexBuffer which you should create through HardwareBufferManager again. The only real choice here is whether you need 32-bit indexes or not, best to use 16-bit if you can since they're more efficient.
Populate your buffers by either using their writeData methods to copy data from system memory buffers, or write data into them directly by using their 'lock' methods. Check the way it's done elsewhere, and note useful utility functions like VertexElement::baseVertexPointerToElement which take a pointer to the start of a vertex and give you back a pointer to the start of that element. There are in fact lots of useful utility methods on VertexDeclaration and VertexElement to help you, in many ways this is much easier than it was before because you don't have to just organise the memory yourself.
Well, that ended up sounding long and complex, but having done a lot of these I can tell you it's actually very easy once you adjust your thinking!
HTH
Weird, Sinbad could you check if the LOD's are there or not?