How to: Plugging in tiles

I'm using an engine as a dll that runs a game world within, it has no graphics at all, ergo, using Ogre to build on top of it. Ogre works perfectly with it thus far, and now I am needing terrain. The view distances are always quite short (they do not need to be long for this play style, rather above view).

This is how it handles terrain:
When you first load it, you specify the detail of the terrain you want, for example, it can return a point every meter, or every millimeter (although the source may not be anywhere that accurate, some may). You can change the resolution at any time, or even for specific batches, such as points further away could be more corse and points closer could be more detailed. When first loaded, where you are in the world it gives the float's around that area, out to the distance that you specify, sending multiple steps if needbe (gives out a set of floats, closer together and more detailed when close, further apart when further from player). It expects the graphic engine to cache the values, it does not expect it to cache values that are too far away as it will just resend them, possibly modified. The terrain can be modified at any time, and it will send an update when that occurs. Internally (and through the interfaces), all positions are represented using doubles in the x and z, and floats in the y. It is a theoretically infinite world and as the player moves around, it sends the near terrain to the graphic engine. So I am basically asking, would PLSM2 be good to pull this off, and if so I assume I would implement it as follows:
Set the distance far enough to encompass a couple tiles. Call up a set of terrain so far enough away it will be a constant amount, say 1 point per every 5 meters or so, the closer tiles would be updated using 1 point per half meter, maybe less. I do not know how to plug tiles into PLSM2 in real-time though, details?

Also, when you ask for a set of information on the terrain, it doesn't just give the point location, but it gives a variety of information, something along the lines of (I think I am remembering it all, probably forgetting a bit) in pseudo-code:

struct
{
double pos_x;
float pos_y;
double pos_z;
float norm_x;
float norm_y;
float norm_z;
float water_level;
float water_norm_x;
float water_norm_y;
float water_norm_z;
float water_move_x;
float water_move_z;
unsigned int material_id;
unsigned int flags;
}

It has a position for placing it. It has normal's for lighting it (there are day/night cycles). There is technically another water plane as well as the land plane, the water_level specifies the water's height, if the water's height is <= pos_y, then it cannot be seen (possible caves later on though), if water_level > pos_y, then you can see the water at that point and it should be connected with the surrounding water points to make the water surface. The water_normal is obvious. The water_move is what direction the water is moving in, specifying direction and speed. A turbulent water param will probably be added later to specify how turbulent the water should be. The material_id is to a material. A material can be looked up by it's id, in which a material specifies everything from what texture should be used at this point (the graphic engine is expected to blend the graphics of terrain's together), to how much damage and what type is inflicted just by standing/flying/burrowed/etc... on this point, to how fast you can move for varying movement types, and so on, even though the graphics engine will mostly only deal with the graphic, except maybe drawn debugging info for damage area's and such. The flags just hold some other misc info.

Would PLSM2 be good for this, and how would I pull it off?

Not sure that I got everything there, I'll try to answer what I can.

Page are pluggables dynamically (update plsm2 widht or height and give page source using a customized data2D classe or heightmap files).
Tile is not.

Lod is based on roughness and distance, but perhaps you can change plsm2 to make it use distance only. (disabling roughness computation of fixing it.)

Water is not handled by plsm2, you're on your own.

Pages are pluggable dynamically (update plsm2 width or height and give page source using a customized data2D class or heightmap files).
I can request data from it as well so plugging in the full quality data into PLSM2 for the area around the user is quite doable and actually a bit easier, don't suppose there are already examples around for doing this?

The big thing though is that the library pages internally. Basically, going in a PLSM2 style context, it gives pages around the user and continuously gives new ones as the user moves around. It may tell you to cache some that are at an arbitrary location for when you transport a far distance it will not have to parse a ton right then. The distances well exceed float's internally (uses doubles right now, but things outside the library aren't supposed to care), but everything that will be shown on screen at once lies well within 1024 units (probably well within 256 in reality), and it gives either absolute positions (using doubles), or relative positions of everything (basic on the main character's position). Right now, so I don't have to deal with doubles inside OGRE, I am having it relative, and the user's scenenode is basically the root node of everything else, kinda like this:
rootnode
- user's scenenode
- user's effects on person and other such things
- terrain scenenode (although this is blank right now since I am not pulling data across from this)
- other objects

Using PLSM2, the terrain is static, and static does not move, so I would assume this setup would not be possible, so I would have to deal with double size distances, with terrain to match (unless PLSM2 can fully unload pages if I tell it to, to clear memory).

Would I just be better off using relative positions and create and manage the terrain myself? Problem is, I have no clue how to apply and blend the textures the library will send over for the materials...

Water is not handled by plsm2, you're on your own.
Yea knew that, not a big deal.

don't suppose there are already examples around for doing this?
no, but some bits on that may lies in the forums.
The distances well exceed float's internally
use Ogre and plsm2 with double (pslm2 need a few casts patching, easy to fix), it would be simpler than a "double wrapper"
(unless PLSM2 can fully unload pages if I tell it to, to clear memory
it may be very easy to patch PSLM2 to do that.

Would I just be better off using relative positions and create and manage the terrain myself?
patching plsm2 should really be easier

I guess I finally have enough reason to recompile Ogre using doubles then. I'll have it use absolute position's instead of relative, won't be a hard change to account for that. I'll have it get the terrain in chunks of a fine resolution (does PLSM2 take the finest resolution of a page and break it apart itself, or does it take each lod, would be very simple to ask for which resolution of a page I want). Since I've been meaning to add double support to PLSM2 anyways, this gives me the excuse. As for having PLSM2 unload pages from memory, that I have not clue how to patch, although with enough digging I could figure it out, or are you planning to do that?

The big problem that remains, no matter the way I decide to do it, how do I deal with each point on the terrain having a texture type? The library can either export graphics in chunks that fit on the square between four point in whatever resolution is specified, or it can export an image of a section arbitrarely large (although the graphic options internally are generated in real-time and it recommends not to use them due to speed issues, it does generate them in another thread, but they will not be available instantly, so if they are used they should be asked for well before they are needed), but rather use your own system based upon the material settings it gives back. Thoughts about handling this with PLSM2? Or is there a better method, the library actually supports quite a few different methods, so if you know of a good way to handle this with PLSM2 I could try to find a way to use it with that library.

does PLSM2 take the finest resolution of a page and break it apart itself, or does it take each lod, would be very simple to ask for which resolution of a page I want)
sorry, didn't understood that ?
Since I've been meaning to add double support to PLSM2 anyways, this gives me the excuse
done, soon in cvs.
s for having PLSM2 unload pages from memory
I'll do that since it's easy for me and may be harder for you.
how do I deal with each point on the terrain having a texture type?
what is a texture type exactly ?

Note that you can get material per page, and update texture the fly pixel per pixel if you wish.

Actually, let me explain how that other library actually works, you all may find this interesting.

The other library is a fully self contained little rpg game, minus a graphics engine. It is designed to be played isometrically from an above'ish view. It can be setup so it would drive a little web html game, to being able to handle a 3d engine and doing everything in real time. It is not yet completed, but it sets up and handles a world right now. It is designed so you feed it a set of probabilities about the world (water amount, mountains, rivers, roads, erosion, etc... plus a seed number) and it uses libnoise to generate everything. When I say it uses libnoise to generate everything, it uses it to generate near everything, from the land, roads, placement of cities/towns, it even uses it to draw the world textures if you decide not to use your own. The world it gives as points. It also generates a normal map for use in the day night cycle if the plugged in graphics engine supports it and works better using a normal map. You can ask it for a large amount of points, or just a single one (for example, the height on the terrain). During play, you feed it inputs from the player, it handles networking, moving, collisions, etc... and feeds back to whatever the graphics layer is what to draw and where (when a new object is created, the graphics engine is told about it so it can cache everything, when and object is destroyed, or just gets too far away, it recieves a callback that such n' such object is destroyed and it can forget about it). It does some caching, such as if you use a transport of some sort to instantly go to another place in the world, it attempts to create that portion of the world as you move near to the transport, just enough of it so that it will be drawn if they use it. Honestly, the thing could be played in a text prompt using ascii characters if such a thing was made to be the graphic layer, minus the 3d aspect.

As it generates the terrain though, and sends the points to the graphics layer, it also sends normal information, material information, etc... The material information contains what type of terrain that point is (which corresponds to a certain texture to draw, such as grass, mud, snow, rock, a combonation, etc...).

After Reading (please use line-breaks!), I confirm the 'Note that you can get material per page, and update texture the fly pixel per pixel if you wish.'

Yea, sorry about that, was in a rush at work.

Thing is, little clue how to do that, will have I have to instantiate my own resource data class to push in textures, or is there some better way I can plug them in. I get the texture data as an array of RGBA for note.

@OvermindDL1: Wow, this sounds incredible!
Be sure to visit the Ogre ShowCase Forum once it's ready!
I am certain a lot of people will want to hear about it.

It's not really that special, it is a rather plain thing so far. About the only thing unique with it is that just about everything is procedurally generated...

Once I get the graphics terrain working with it I'll be posting something up in the plsm2 section at least. Once I get the model's drawing with a gui and such, then I'd consider it Ogre ShowCase worthy. As stated, it is isometric, the purpose is that it supports 3d model's or billboards (many artist's just love drawing flat textures, not to mention they can look far more detailed then 3d model's while remaining fast). The isometric view allows the billboard object's to look best.