Simple Paged Terrain [v2.00 Released! Page 21]

HexiDave · Post by **HexiDave** » Sat Sep 06, 2008 7:06 pm

Jabberwocky wrote:I'd love to see a "simple' version of SPT packaged up as an official plugin, but that's just my opinion.

Ya, but for large terrains there's really no way to make it work for everyone without some huge obstruction in the way it's designed. I kept making test projects for new features to try and build a way to get all the different functionality into a fairly simple setup, but each major system fouls up something else (usually simplicity and speed). Honestly, the biggest issue for me was making things people could turn off - the light-mapper and atmosphere systems working in conjunction with Ogre's material/shader system is damn difficult, especially for situations I can't predict. The weirdest issues would crop up because of different setups.

netskate wrote:what scene manager do you suggest to me?

You can still just use SPT as a library, but skip the Editor thing - that was a project that just fell apart due to .NET being a hellish mess.

I still work with a project that regularly uses SPT for 64km or so terrains, so it'll do what you want. I'd recommend learning shader programming (HLSL is the same as Cg, for the most part, so this would be a good reference:
http://http.developer.nvidia.com/CgTuto ... ter01.html - it's the full book online for free by NVIDIA) and then just tweaking shaders/materials to your needs. I'll be posting my newer shader tonight, but I'm mostly tailoring it to a project I'm working with (it's still got a lot of power in it, though). 18km x 18km should be no problem at all for SPT - just take a look at how SPT's demo project works with terrain loading and such.

Post by **Jabberwocky** » Sat Sep 06, 2008 8:20 pm

Well, that's sorta my point. A "simple" paged terrain manager wouldn't include lightmapping and atmosphere functionality at all - it's outside the original scope of SPT as far as I understood it. And different projects likely want to implement these aspects in different ways (if at all). But anyway, this is your project, and I shouldn't be making suggestions what you do with it.

Good luck with your game project.

netskate · Post by **netskate** » Sat Sep 06, 2008 8:21 pm

for editor I would use third party application such as earth sculptor or some like it (just for heightmap).

the problem is that spt have no documentation. only this thread and the demo application are available for help.

I can run the spt_demo, but I wanted integrate it with paged geometry and I red you says that is not a good solution because render of lightning...

would be fantastic if you can wrote four lines of basic tutorial, but I undestand that this cost a lot of your precious time.

I continue to see your demo.

ps: what do you think about plsm?

DanielSefton · Post by **DanielSefton** » Sat Sep 06, 2008 10:28 pm

I'm scrapping work on this project.

B-But... SPT is excellent.

I've worked with SPT for a couple of months, and I've already developed an editor with WXWidgets, I've got character control working with raycasting, I've got dotscene working with it, and I have a tile system.

What I think you should do is scrap the shaders altogether. It doesn't need an atmosphere. Anyone looking to use it wants a terrain system, not a sky - Caelum is for that. If you removed the shaders, and just concentrated on the terrain itself, it would make things a whole lot easier.

As far as I'm concerned, it's finished. BUT, it just needs to be made practical (no shaders), and bug-free (e.g. I'm stuck with the fact that you can't export the heightmap; which is essential for an editor)

ETM is a no-go for me - without a LOD system, it's only any good for small games and small maps (E.g. FPS). Whereas, SPT is perfect for RPGs and MMOs.

You've worked so hard on this - too hard. You're powering forwards all the time, adding new features. You should set a realistic target, aim for it, and say no more to the fancy stuff. It's starting to turn into another PLSM, which it not what you intended.

Obviously I'm hugely disappointed - SPT was the centre of my project. If you can pull through and continue, I'd be over the moon, but if not I respect that. However, I'm sticking with it no matter what.

HexiDave · Post by **HexiDave** » Sat Sep 06, 2008 11:09 pm

You were one of the primary people I had in mind when I'd say I'd happily help continue forward. I just can't continue making this an enormous contraption that does everything for everyone.

You're right, though - shaders/materials are the big point at which this whole thing comes unhinged. The atmosphere part wasn't so bad as it's just on/off (although, I can't figure out if there's any way to modify Cg compile_arguments in code, so handling them automatically is difficult at best), but there are any number of possible setups for terrain shaders, and each of them has to be setup in just such a way that it doesn't break everything else. I came pretty close with the new shader, but there's just no way to make it practical AND easy to use without being able to pass compile_arguments to the shaders. The light-mapper was what killed most of my time - it's so handy, but so incredibly flaky (mostly because of trying to support cards that don't handle non-power-of-two textures - totally screwed everything up).

I'm mostly abandoning this because I constantly feel like I'm forgetting something or somebody. A lot of the components I had promised worked in tests, but I'd pass it to someone else to test and I'd find some horribly obscure issue that I can't test on my own because I don't have the hardware. It's just not fun or interesting like it used to be - now it's just a major chore with no end in sight; it's also fallen out with what I wanted for it to be, so I can't easily make myself work on it.

As for exporting heightmaps, there should be a SPT::Terrain::saveHeightmap() function - I can't remember if I updated that on SVN or not, but I was compressing JPEG2000 heightmaps that way.

DanielSefton · Post by **DanielSefton** » Sat Sep 06, 2008 11:53 pm

Really though, you were creating this for yourself. None of us expect you to come out with a system that works flawlessly for everyone - that's simply not possible. What you should, or should have done, was develop it exactly how you wanted it to work in your game, and supply it as it is.

(mostly because of trying to support cards that don't handle non-power-of-two textures - totally screwed everything up).

I don't see that as a problem... You just have to use power-of-two textures; there's no need to support any other size.

now it's just a major chore with no end in sight

If you could just rewind; take out all the features that are not working, and make a stable version from that. Unless you really need it in your game, there's no point.

but there are any number of possible setups for terrain shaders, and each of them has to be setup in just such a way that it doesn't break everything else

I don't know much about shaders, and I don't know what else you are trying to implement. But a basic lightmap is all you need... It works, and that's all that matters. SPT looks pretty, but anything that involves a lot of work to get it to look nice is not worth it. Look at WoW's terrain system - it doesn't have any fancy shader setup AFAIK; neither do many other games. That should be bottom priority.

As for exporting heightmaps, there should be a SPT::Terrain::saveHeightmap() function - I can't remember if I updated that on SVN or not, but I was compressing JPEG2000 heightmaps that way.

Yeah - crashes for me.

2) When I try to save the heightmap (mTerrain->saveTerrain("abc.png")), it errors out with "OGRE EXCEPTION: Invalid image format in FreeImageCodec::encode at ..\src\OgreFreeImageCodec.cpp" -- PNG should work; I've tried other formats, and they all give that error.

2. This is because I'm a butthead and haven't cleaned that part up - it's just pulling the lightmap's heightmap texture, I think. It also doesn't handle the difference between floating point and integer (ushort) formats for memory heightmaps.

Is that something you've recently fixed? Or did I misunderstand something?

netskate · Post by **netskate** » Sun Sep 07, 2008 11:11 am

then some simple questions:

I download sptv2 from trunk directory in svn. Open the library/scripts folder and open sptv2_library.sln.

I want compile this solution in debug and in release mode, and i think that done that I can load this dll as plugin into my project. (that's right?)

first problem, i can compile sptv2_library.sln, changing the include directory for the sdk version of ogre that I use.

but I have some warning:

RELEASE:
BrushDisplacement.cpp
..\src\BrushDisplacement.cpp(252) : warning C4018: '<' : signed/unsigned mismatch
DEBUG:
BrushDisplacement.cpp
c:\documents and settings\valerio\desktop\simplepagedterrain\library\src\brushdisplacement.cpp(252) : warning C4018: '<' : signed/unsigned mismatch
HeightmapRules.obj : warning LNK4221: no public symbols found; archive member will be inaccessible
Performing Post-Build Event...

however, now I have a Sptv2.lib file, how I had to procede to import this into my minimal ogre projects? and what are the basic line of code to select sptv2 scene manager and load the heightmap?

ps: an anticipation of my next question. I had to split my heightmaps to make it work with spt? (such as something like mapsplitter for plsm?) how does it works?

sorry for my english, and for my noob questions.

Yacoby · Post by **Yacoby** » Sat Sep 13, 2008 7:42 pm

Heya

I am implementing a terrain system for a game with the dataset already defined (OpenMW)

The data splits everything into cells, or pages, 65x65 vertexes, with 128 GameUnits (GU) in between each vertex, there are 2500 - 3000+ cells.

Due to the limit of 4 texture passes on some gpus, the easiest way seems to be to split each cell into 4 sections with a material for each sections.

Distant Land (DL) with a distance of 20 cells is a requirement, although the DL data can, and probably should be, pre-generated.

I was wondering if you though it would take much, if any, hacking around with SPT to get it work with system.

Regards

Dredd · Post by **Dredd** » Fri Oct 03, 2008 6:55 pm

I've read through this entire thread and I'm curious if Either Daniel or HexiDave could respond.

Has anyone ever acted on Daniel's advice to refactor this library back down to its core?

In other words does this have a stable branch that acts as a lightweight landscape presentation with on demand paging?

It would seem a waste to have a lib that represents such a great chunk of work sit idle because of shader problems at project end.

ppClarity · Post by **ppClarity** » Fri Oct 10, 2008 9:14 pm

My terrain dataset is huge (100's of km in both directions) and would require several hundred Mb to contain entirely within memory. At any one time I only need a fraction of that data (worst case: 5-10km radius from the camera).

As far as I can tell, the Heightmap class seems to want to contain the entire area. What changes would be needed to let it manage the dataset in chunks? FWIW, I was already planning on subclassing HeightmapReader for my own project since my data is procedurally generated.

P51D_Ace · Post by **P51D_Ace** » Tue Nov 04, 2008 7:20 am

I think it is really nice to have a simple implementation of a multi-resolution terrain. I would like to get this to work in my application, but I am having trouble getting to work under Ogre 1.6. Has anyone gotten this to work under 1.6?

ppClarity · Post by **ppClarity** » Tue Nov 04, 2008 4:20 pm

Sort of, but I'm getting black terrain. I'm on Linux so I'm limited to Cg and GLSL for shaders and I do not know enough about either to debug the issue. I am currently exploring adding a paging manager on top of ETL.

P51D_Ace · Post by **P51D_Ace** » Tue Nov 04, 2008 4:45 pm

ppClarity wrote:Sort of, but I'm getting black terrain. I'm on Linux so I'm limited to Cg and GLSL for shaders and I do not know enough about either to debug the issue. I am currently exploring adding a paging manager on top of ETL.

I am also on linux, but it crashes if I do the following in SPT_Demo.h

Code: Select all

mCamera->getViewport()->setBackgroundColour(ColourValue(0.75,0.75,0.75));

If I comment that out it then hangs in TerrainMesh.h at setBinding:

Code: Select all

                        mMainBuffer = Ogre::HardwareBufferManager::getSingleton().createVertexBuffer(decl->getVertexSize(0),mVertexData->vertexCount,HardwareBuffer::HBU_STATIC_WRITE_ONLY);
                bind->setBinding(0,mMainBuffer);

I have code that does this in code elsewhere and it works fine, not exactly sure why it is doing this. The code looks good, maybe an initialization issue.

Are you getting a mesh without a texture? If so, what did you do to get it to work if anything?

ppClarity · Post by **ppClarity** » Wed Nov 05, 2008 1:35 am

Looks like I added an empty (yes naieve) visitRenderables() implementation to TerrainMesh.h because one of it's superclasses has that as a pure virtual function in 1.6. And I also remember having to wrestled with the material files. But that was at least a month ago, so my memory is a bit fuzzy.

P51D_Ace · Post by **P51D_Ace** » Wed Nov 05, 2008 2:50 am

Is it possible for you to post your version of the code or a patch file of your changes somewhere it could be downloaded?

ppClarity · Post by **ppClarity** » Wed Nov 05, 2008 3:07 pm

Unfortunately I'm on the hook for some non-graphics code for a different project, so until I get that over with my 3d work is on-hold.

Regardless, my changes were trivial and made by dealing with the compiler errors, looking at the crash backtraces and the errors reported in Ogre.log. Honestly, I think this needs somebody a bit less material and shader-ignorant than myself.

deepscratch · Post by **deepscratch** » Thu Nov 06, 2008 9:51 pm

hi all, I've been bashing my head a bit trying to get the demo to compile, specifically getting the "SPTv2.lib" to compile out.
problem is here:

1>QNode.cpp
1>..\src\QNode.cpp(235) : error C2259: 'SPT::TerrainMesh' : cannot instantiate abstract class
1> due to following members:
1> 'void Ogre::MovableObject::visitRenderables(Ogre::Renderable::Visitor *,bool)' : is abstract
1> c:\ogre_main\ogresdk\include\OgreMovableObject.h(484) : see declaration of 'Ogre::MovableObject::visitRenderables'

I'm using the new 1.6 release of ogre, anyone else getting this problem??

thanks

Post by **jacmoe** » Thu Nov 06, 2008 10:03 pm

Seems like this project needs its own Addon Forum.
Or, what do you think?

ppClarity · Post by **ppClarity** » Thu Nov 06, 2008 10:28 pm

jacmoe wrote:Seems like this project needs its own Addon Forum.
Or, what do you think?

The project is no longer in active development. The author has moved on and there currently is no maintainer.

Post by **jacmoe** » Thu Nov 06, 2008 11:00 pm

Right.

And no one is tending it?
That's bad.

aguru · Post by **aguru** » Sat Nov 08, 2008 6:09 pm

I have been looking into it, reading a lot of code and experimenting with the library as it is now, but I don't feel quite up to the task - yet. Is anyone else still working with spt2, maybe planning on using it in a project?

deepscratch · Post by **deepscratch** » Sat Nov 08, 2008 7:02 pm

yeah, I'm trying to use this. I have the need for vast paging terrain, (free flight) so for me its a must. if only could get past

"'void Ogre::MovableObject::visitRenderables(Ogre::Renderable::Visitor *,bool)' : is abstract"

P51D_Ace · Post by **P51D_Ace** » Sat Nov 08, 2008 7:28 pm

Put in TerrainMesh.h:

Code: Select all

void visitRenderables(Ogre::Renderable::Visitor* visitor, bool debugRenderables = false){}

This resolves the unimplemented method.

deepscratch · Post by **deepscratch** » Sat Nov 08, 2008 9:21 pm

thank you greatly, not only does it solve the problem, it also solves similar problems in other projects floating around. exellent! ta.

Crashy · Post by **Crashy** » Sun Nov 09, 2008 9:53 pm

jacmoe wrote:Right.
And no one is tending it?
That's bad.

Maybe me. I'm going to use it for my projects, so I might add some features, optimize & debug it.