Getting CVS PLSM to work

Hi all -

I've been trying to get PLSM to work for over a week. I found out there were some kinks in getting it working with different versions of VC++ so I've settld with Eihort + PLSM 2 from CVS which in the end compiled in VS 2003 after some patching. I'm wondering if anyone else is having or has had this same problem.

I got the demo to run but unlike the binary demo there are problems in my my build. The alpes map loads just like in the binary demo and I can move around. As soon as I move close to the terrain though a large chunk of terrain disappears, usually the parts nearest the viewer. Descend to ground level and the entire terrain disappears. (I made sure all the vertex/morphing features are disabled beforehand).

Am I doing something wrong? Is there a known working version of PLSM that works with another version of Ogre that is known to compile well under VS2003? (Or alternatively, has anyone integrated the Ogre SDK source code with PLSM's who could possibly zip it up and upload it so others can compile - I know i'm asking a lot here, just wondering).

Any responses or suggestions will be appreciated.

Possibly you have shadows enabled?

I would recommend you use OGRE Dagon 1.2.5 i think with sdk plsm2 for starters, then move to cvs plsm2 when you are familiar with it. As of now PLSM2 is a bit tricky to setup with Eihort, it's all been discussed here on the forums loads so if you want to know about it just search for eihort or whatever.

Thanks, it seems it's best if I just get the 1.2.5 prebuilt install and see if that will work, then work from there.

I did have to jump through a lot of hoops to get it working with Eihort so probably something got messed up along the way. Out of curiosity, has anyone gotten PLSM to play nice with Eihort, without any issues?

For what it's worth, it sounds like an issue with your camera's near clipping plane?

I've noticed similar issues when building CVS using 2003. (I have a newer version of the compiler, but haven't taken the time to install it, there is really no reason atm). I have everything built, but decided this afternoon to redo the install in a second tree and take notes.

I'll be happy to update the project file and the instructions once I figure out the "proper" way rather than what works for me.

* For OgreMain (not PLSM I know), I changed the output directory to use $(ConfigurationName).

* I noticed that the PLSM project refers to OgreMain being three levels above (../../../OgreMain), and since the current directory is paginglandscape/Plugins/PagingLandscape2 this suggests that paginglandscape is intended to be a peer to OgreMain.

The "problem" with this is that CVS users get an ogreaddons folder with paginglandscape inside -- and it is sure tempting to put ogreaddons as a peer to OgreMain. OK, no real problem, just checkout the code and move the tree. But then the include path doesn't have OgreMain.h.

While I was able to fix things up, I would like to mention that I first looked at Ogre because the engine I was working with couldn't be built with 10x the messing around which PLSM needs. This isn't a complaint, rather I'm just pointing out that some of the newer users may give up before they get things working.

Again I'll be happy to improve this experience when I get some idea where things are intended to go.

* Where should the built plugin go?
** Samples/Common/Bin/$(ConfigurationName) seems the best choice, since it has all of the DLLs.

* mapsplitter has some hard-coded paths [MapUtil::init()]


0:41:56: Added resource location '../../../../../ogreaddons/paginglandscape/Samples/Media/paginglandscape2/terrains' of type 'FileSystem' to resource group 'PLSM2'


We cannot have an ogreaddons folder and simulataneously not have one.

Frankly at this point I miss the environment variables which were used in the past

Maybe it would be easiest for me to look at a "dir/s" of a proper build tree to see where everything needs to go. It sure seems that CVS builds are going to require some mucking around, and I don't know that this is desirable in the long term.