Abstracting the height files....almost there....

Hey guys,

I would like to try to find a way to change PLSM2 so that I can have it call my program with the height file(or even better, the page coordinates) it wants to open and then call my program when it wants to read that heightfile so that I can populate the stream from other sources.

Making a generic listener to intercept PLSM2 calls wouldn't be all that difficult, but PLSM2 is alot of source to filter through, can someone give me some tips on either:
1. Where the height map files are opened and read.
2. A good place to start in disecting the code.

I will get there one way or the other, but the less painful, the better.

I have no experience of it myself, but I read something similar in this thread a couple of days ago: http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=1797

Thanks, that had exactly what I needed. Sorry I missed it in my search.

I was thinking that if I were to do this, it might be good to do it in a way that would benifit others trying to do the same thing. My first thought was to try to basically take the Data2D class and make it use a callback mechanism to get at the data.

I am going to begin working it in that direction for my own project. Tuan are you interested in those changes? Obviously it would add a little more overhead to implementing PLSM2 in any application, but it wouldn't be that difficult to provide the current implementation already constructed to load files for those who want the default action...

Perhaps I can get it so that if you don't specify a new listener it uses the default implementation anyway. I will keep you up to date...

Ok its starting to take a bit of shape. It looks like I need to create a new class based on PagingLandscapeData2D. I can have it use a listener interface class to call back into the main program so that the modifications to PLSM2 can be generic. I can pass the pointer of the listening load functions and friends through SetOption...so these changes could very well go through without breaking any API.

It also looks like I will have to add an extra option to SetOption in order to turn off config files per map. I haven't gotten that much into the options yet, but it appears that it may need a passthrough for setting map specific options programatically...it may exist, I need to look harder.

@Tuan: I would really like your thoughts on this, because I have a project to complete and although I will submit as much code as I can, I need to try to either stay mainstream with my SDK's or make sure that the modifications I make get pushed back into them. I don't expect to be done this version of anything and I would hate the thought of reworking all of my SDK's. I currently already have a big enough problem with CEGUI. I made a bunch of mods to it, but RC-1 for the next version is already out and I don't see my changes getting in until the one after.

If I can make these changes to where they don't break the API and are generic enough to benifit all, is there any way I can convince you to merge them in ?

This is actually not as tough as I thought it might be. Looks like Tuan already accouted for quick additions of data sources.

Now anyone have any idea about the config heirarchy. I see the main set options are set in PagingLandScapeSceneManager, but each map and page appears to also get its own set of options.

Ok, the options weren't as hard as I thought...Looks like calling setWorldGeometry with a NULL datastream would be enough to stop the loading, probably want a string type for callbacks though...

Now on to see how I can prompt it to load callback data even though it has no map to do it with.

Is Base,Coverage, and Shadow supposed to be 1 value per page or did the parameters just get named that way ?

Well, the demo app for testing it will have to wait until tomorrow. The test will be trying to use libnoise real time to gen the terrain... Of course, my hopes are pretty low about granularity of noise I will be able to use to get fast enough output..but I guess we will just have to see...

I haven't been able to write the test app yet as I need to get home from work before I can do it, but how are width and height options going to affect me? I noticed that most map.cfg files include number of pages wide and high, but I really want to make this one infinite. I realize that the renderables and camera will eventually get to a point where they will not function..I actually plan to dig into the infinitizer next, but should I just set width and height == to upper bounds of an unsigned int ??

Does anyone recall offhand what the upper bounds of a an unsigned int are? I know its up there, but the actual number eludes me...

This is going to take alot more changes than I originally anticipated. Currently the load options setup the map and running without a map config leaves you without a data2D manager. There is not currently a way to set one in setoption. Although taking a single option is not much of a problem, it seems that it needs to be reworked so that when a mapfile is read it calls setoption to set each option...That way there will only be 1 implementation of each setting which will make the code cleaner and make sure there is never ambiguity in the way the options are processed.

I moved the mOption=new line to the ctor since you will always need a clean set of options once the plugin starts, in order to be able to set options at all from that point, InitScene() had to be copied just under it.

As hard core as I seem to be getting into these changes in order to make this work, I probably should look at getting the CVS head so that I am making a patch that will actually be used...

Still would like to hear from one of the PLSM2 devs about what I am doing... I really hate the thought of going down a path that either has an unforseen deadend somewhere down the line or that is not in the direction the project lead wishes this to move.

For the time being, I am gonna have to shelf the demo of the new Data2DCallback, break out the CVS version of PLSM2 (pray that I can get it to compile) and try to reimplement my changes there before I waste anymore time.

I know you guys think its funny that I keep writing on a thread that only I am answering. I am hoping to keep my status on this known well enough that eventually someone will let me know if my direction is ok or whether I need to rethink this.

I'm reading it with interest--if only to learn a bit more about the way PLSM2 works. My current project doesn't really require what youre doing. But I think it's a very cool idea.

Steve

Very interested in that.
Will surely go into main trunk when completed.
So yes, a patch + a demo would be indeed nice.

- Adding a new Data2d that can send delegates seems a good way to me indeed.

- you should be able to load an empty map, with any width and height you need, you even can set it at incredibly high numbers unless it leads to errors. (width and height can even be modified afterwards.) you can get limits using STL : std::numeric_limits<unsigned int>::max ()