a tilebased terrain manager

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
User avatar
triton
Greenskin
Posts: 138
Joined: Thu Mar 13, 2008 10:25 pm
Location: Portugal

Post by triton »

Very, very nice! I'm really excited about this tiled terrain manager. :)
User avatar
Lokysan
Gnoblar
Posts: 3
Joined: Fri Apr 18, 2008 9:37 am

Post by Lokysan »

Thank you very much! I'm quite new to 3D and Ogre, but I think this could help me greatly for getting started with the graphics side of my project. I still need to figure out a way of supporting several levels of terrain (for my project it's very important to support caves, tunnels and other subterranean features) but apart from that this fits almost perfectly with what I had in mind. I can not wait for the final release (and future versions if you have further improvements in mind ;) ). Keep going with this great work!
User avatar
DasGurke
Halfling
Posts: 86
Joined: Wed May 24, 2006 11:15 am
Location: Hamburg, Germany
Contact:

Post by DasGurke »

Just to let you know, that there are still people interested in a Tile based scene managing solution ;)

I am currently trying to integrate your sample into another application, but I still have a few questions / feature requests:

1) Could you "automate" the heightmap loading, so that I just have to pass in a texture to load?
2) I guess the TBT::TileData::dir property has something to do with the texture being used for that tile? Or am I mistaken?
User avatar
DasGurke
Halfling
Posts: 86
Joined: Wed May 24, 2006 11:15 am
Location: Hamburg, Germany
Contact:

Post by DasGurke »

I am now loading heightmaps myself with the following code:

Code: Select all

		// Loading an setting the heightmap data
		Ogre::Image* heightmap = new Ogre::Image();
		heightmap->load("Heightmap.png", "Terrain");

		int width = heightmap->getWidth();
		int height = heightmap->getHeight();

		// [...]
               
		// Setting the height value independently for each tile
		for(int y = 0; y < width+1; ++y) 
		{
			for(int x = 0; x < height+1; ++x) 
			{
				// Retrieve the height from the heightmap
				Ogre::ColourValue color = heightmap->getColourAt(x, y, 0);
				heightData.at(y*(width+1)+x) = color.a;
			}
		}

      // [...]
		// Create the terrain manager and pass the data we have just loaded to it
		mTileManager = new TBT::TileManager("DemoTerrain", mSceneManager->getRootSceneNode()->createChildSceneNode("terrainBase", Ogre::Vector3(0,0,0)));
		mTileManager->setMapSize(width, height);
		mTileManager->loadHeightmap(heightData);
		mTileManager->loadTileData(tileData);

		// Generate normals, chunks and the interface
		mTileManager->generateAllNormals();
		mTileManager->createChunks();
		mTileInterface = new TBT::TileInterface( mTileManager, mCamera );

		// Load all chunks
		mTileInterface->controlChunks( 0.0, true );
The terrain hase a size of 256 * 256 Pixels, but somehow only 160 * 160 Pixels are displayed. At least thats the "farest" Pixel I can select. I tried digging a little through the source code, but wasn't quite able to find the root of this limitation.

Is that just something happening to me? Or can anybody confirm that? (I hope this project is still actively developed xD)
Trosan
Greenskin
Posts: 101
Joined: Sun Jun 10, 2007 4:57 pm
x 1

Post by Trosan »

DasGurke wrote:Is that just something happening to me? Or can anybody confirm that? (I hope this project is still actively developed xD)
Well, I am very sorry for promising the final version over and over again, while there is none. I am very busy atm (exactly one more month) and after that I'll get back into active development of the tileengine (so hang on!).

First of all, thanks for your wishlist. I can answer the 2nd question directly: The dir property is the direction of the tile. So if you don't want to rotate the textures on the tiles (clockwise 90° per value, so dir=2 is a rotation of 180°) you can set it to zero.

DasGurke wrote:The terrain hase a size of 256 * 256 Pixels, but somehow only 160 * 160 Pixels are displayed. At least thats the "farest" Pixel I can select. I tried digging a little through the source code, but wasn't quite able to find the root of this limitation.
Could please specify what you mean by Pixels in this context?
Anyway, if I understand you correctly, try setting the view distance to a higher value.. perhaps that might solve the issue..
User avatar
DasGurke
Halfling
Posts: 86
Joined: Wed May 24, 2006 11:15 am
Location: Hamburg, Germany
Contact:

Post by DasGurke »

Ah sorry, what I meant was:

I am loading my terrain from a heightmap, which has a dimension 256 * 256 pixels and looks like this:
Image
The alpha channel defines the height of the tile. So there should be a flat terrain with 4 obstacles sticking out of it at the corners.

But anything I can see is this:
Image
The white little thing at the lower right, is the currently selected tile, which is at 160|160. But I create the terrain from the heightmap, so there should be 256 * 256 tiles. (Whoops, sort of solved, see editedit)

Edit: Damn posted too early, few questions to come ...
1) Can I somehow specify a certain material for a tile? Everything I found according to the materials was a config setting:

Code: Select all

  /** Name of the terrain material. */
  const Ogre::String MATERIAL_NAME = "Land_HighDetails128";
2) How did you achieve those different textures in your screenshots? Did you use fringe tiles to soften the transistions? Or is that even a built in behaviour?
3) For me the selection somehow covers 4 tiles, even if only one is selected. Any idea what I am doing wrong? These picture illustrates the issue:
ImageImage
The blue part would be a single tile.
4) How do I apply a grid to my terrain?

Code: Select all

tiletexmgr->createGrid();
Creates a grid texture, but how do I use it? Shall I assign it as a second texture in the .material, or is there any automatic way to display it?

EditEdit: Aaaah, I figured out what you meant with view distance. You did not mean the cameras view distance, but the VIEW_DISTANCE setting in the tile_config.h . Alright, when I set that to a higher number, I can see the whole terrain. But shouldn't it load dynamically depending on the camera position?
Trosan
Greenskin
Posts: 101
Joined: Sun Jun 10, 2007 4:57 pm
x 1

Post by Trosan »

DasGurke wrote:1) Can I somehow specify a certain material for a tile? Everything I found according to the materials was a config setting:

Code: Select all

  /** Name of the terrain material. */
  const Ogre::String MATERIAL_NAME = "Land_HighDetails128";
Have you taken a look at the demo source (main.cpp in folder "demo")?
In line 34 you'd add more (different) textures and in line 57/58 you'd specify which texture to use for each tile.. but I see that it's not very intuitive this way.. Hum, I guess it would be better to have a number between zero and TextureCount-1 for that instead of the x / y values. Perhaps I AM going to make a little interface change. Will rethink that (you may share your opinion).
DasGurke wrote:2) How did you achieve those different textures in your screenshots? Did you use fringe tiles to soften the transistions? Or is that even a built in behaviour?
Actually, for the demo (which the screenshot is from), I use one texture only. There is no built-in texture-transition or something.

DasGurke wrote:3) For me the selection somehow covers 4 tiles, even if only one is selected. Any idea what I am doing wrong? These picture illustrates the issue:
ImageImage
The blue part would be a single tile.
Oh, you are right. At the moment, you can only raise "corners" of tiles. So actually the center of the selection is exactly the position which is raised/lowered. But it would be helpful to raise tiles, too, you are right (would mean that all 4 adjacent corners are raised), I will put it on my todo list.
DasGurke wrote:4) How do I apply a grid to my terrain?

Code: Select all

tiletexmgr->createGrid();
Creates a grid texture, but how do I use it? Shall I assign it as a second texture in the .material, or is there any automatic way to display it?
Sorry, that feature is unsupported yet. At least it is untested, I have taken it from the old source code but not adapted yet. It's very unlikely that this will work (also on the todo list now, but with lower priority).
DasGurke wrote: EditEdit: Aaaah, I figured out what you meant with view distance. You did not mean the cameras view distance, but the VIEW_DISTANCE setting in the tile_config.h . Alright, when I set that to a higher number, I can see the whole terrain. But shouldn't it load dynamically depending on the camera position?
Line 91 and 163 of main.cpp and line 168 of demo_framelistener.h will reveal the magic I hope! (speaking of the demo source code). The tilemanager needs to "know" when the camera position has changed (and to which value), so there is an event which needs to be called regularly.


Thanks for your feedback, it's highly valuable!
User avatar
DasGurke
Halfling
Posts: 86
Joined: Wed May 24, 2006 11:15 am
Location: Hamburg, Germany
Contact:

Post by DasGurke »

1) Aaah, these values specify the texture, and not some kind of texture offset. I thought I could shift the texture on the tile, but was not able to find out how to actually set a texture.

So here comes the next question: If push back 10 textures, how would I set Texture #3 for a certain tile? And yes, an index based approach ranging from 0 to TextureCount - 1 would feel much more intuitive =)

2) Uh, I have seen quite a few pictures that illustrate the use of "fading" textures. Are they simply achieved by good tile graphics?
http://www.ogre3d.org/phpBB2/viewtopic. ... 175#102175
http://www.ogre3d.org/phpBB2/viewtopic. ... 062#129062

3) I am actually not intending to use the selected tiles for terrain manipulation. Instead I would like to "higlight" certain areas of the terrain. Hmm, seems to be more a feature request when I am thinking about it: Rectangular selection of a tile range. Its not too urgent though, just an idea.

But It would be nice, if I could only highlight a single tile, without anything around it. I would then implement the needed highlighting myself.

4) Okay, good to know. So there is no need to look into that any further atm.

5) Aaah, controlChunks sounded to me, as if the method would only needed to be called once, and then update itself. I should have read the description ...

And anyway, keep up the good work!
Trosan
Greenskin
Posts: 101
Joined: Sun Jun 10, 2007 4:57 pm
x 1

Post by Trosan »

DasGurke wrote:1) Aaah, these values specify the texture, and not some kind of texture offset. I thought I could shift the texture on the tile, but was not able to find out how to actually set a texture.

So here comes the next question: If push back 10 textures, how would I set Texture #3 for a certain tile? And yes, an index based approach ranging from 0 to TextureCount - 1 would feel much more intuitive =)
Will be the first thing I fix. At the moment, you would set x to 2 and y to 0. To give you a simple formula, it would be x = textureNum % TEXTURES_PER_ROW and y = textureNum / TEXTURES_PER_ROW (TEXTURES_PER_ROW is a const defined in the tile_Config.h).
DasGurke wrote:2) Uh, I have seen quite a few pictures that illustrate the use of "fading" textures. Are they simply achieved by good tile graphics?
http://www.ogre3d.org/phpBB2/viewtopic. ... 175#102175
http://www.ogre3d.org/phpBB2/viewtopic. ... 062#129062
Those screenshots are from the first version and I'm not quite sure how to achieve this. But to tell you my assumption: The first screenshot very much looks like mipmapping does the trick. I have no support for user-generated mipmaps yet (didn't guess that someone would like that). In the second screenshot, I think there was the grey base and someone "painted" the tiles in the center. But I wouldn't bet a $ on this. :)
DasGurke wrote:3) I am actually not intending to use the selected tiles for terrain manipulation. Instead I would like to "higlight" certain areas of the terrain. Hmm, seems to be more a feature request when I am thinking about it: Rectangular selection of a tile range. Its not too urgent though, just an idea.

But It would be nice, if I could only highlight a single tile, without anything around it. I would then implement the needed highlighting myself.
Recangular selection of a tile range should be no problem. Should be implemented fast I guess.
DasGurke wrote:And anyway, keep up the good work!
Thanks for your comments and ideas again. It's one more month untill I'll get back to coding (regarding TBT2), though. But, having a nice todo list to work off is a big plus for a fast development. :)
Trosan
Greenskin
Posts: 101
Joined: Sun Jun 10, 2007 4:57 pm
x 1

Post by Trosan »

Here comes the third release candidate!

Download: Changelog:
  • Changed the way one selects the texture of a certain tile. Instead of the old way, using the strange x/y values, you know refer to a texture by a single number where texture number x refers to the xth texture you passed to the texture atlas generator. (interface change!)
  • Changed the selection decals to a circle to better reflect that you actually select vertices rather than tiles. However, I've added a second "rectangle" selection type which uses the old decal and with which you can select single tiles only (set the brush size to 2x2 for that).

Note: On my todo list was also "support rectangular selection of a tile range" because DasGurke suggested it. What I had completely forgotten about: It's already possible! :) Check the API reference for the tile_Interface. All you need to do is to set a rectangular brush size.

As for grid support: I am not intending to add it at the moment. How important is this feature for you?

Aside from that, I remember a bug in the tileTextureManager which I can't recall. :/ (yes, I should have written it down, I know.) Has to do something with different config settings. Will try and reproduce it sometime. This is one reason for why it's named "RC" still.

The other reason for why I call it "release candidate" is that the "final version" will be for Shoggoth and no Shoggoth RC is out yet. That shouldn't matter, though, TBT2 should be up and running. If not, tell me, please!
boballic
Gnoblar
Posts: 3
Joined: Tue Apr 21, 2009 6:29 am

Re: a tilebased terrain manager

Post by boballic »

Is this project still active?
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: a tilebased terrain manager

Post by jacmoe »

Your best bet is Daimonin - take a peek there.
This project seems to be picked up by whoever needs it.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
boballic
Gnoblar
Posts: 3
Joined: Tue Apr 21, 2009 6:29 am

Re: a tilebased terrain manager

Post by boballic »

I took a look at the project you linked and it is not really what I am looking for.

I managed to build the dlls and compile the demo except that it does not work (it crashes right away). Did anyone else have any of these issues? I'm not that familiar with building dll's so maybe I did it wrong. Would anyone be kind enough to build the debug and release dlls and supply them for me?

Thanks
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: a tilebased terrain manager

Post by jacmoe »

boballic wrote:I took a look at the project you linked and it is not really what I am looking for.
Trosan built upon the work of Filopher and Polyveg:
polyveg wrote:
(...) and LGPL'd (in contrast to one of the later version of the terrain manager found in the daimonin sources [which I did not use of course]).
@Trosan:
Filopher and me decided (ages ago - it seems) that the tileengine-part of our projects is lgpl. If you need sourcecode of the tileengine for your work - i have no problem with 2 licenses for 1 chunk of code.
The code in the daimonin svn stays gpl3 (means if there is somebody in need of code for the lgpl version - just drop me a line, i will support it).
AFAIK, what Trosan uploaded in spring 2008 is the latest you can get from him.
If you are fine with GPL, look into Iris.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
boballic
Gnoblar
Posts: 3
Joined: Tue Apr 21, 2009 6:29 am

Re: a tilebased terrain manager

Post by boballic »

Thanks jacmoe for your help. I'm just awe struck that I cannot seem to get rc3 to function. Everything compiles and builds fine except it either crashes before loading or after the application is closed.
balajeerc
Gnoblar
Posts: 14
Joined: Sun Oct 12, 2008 7:12 am

Re: a tilebased terrain manager

Post by balajeerc »

Firstly I can't imagine why this project would go unattended to... the features already implemented are stunning and would be indispensable for several projects that come to mind immediately.

Now from a personal point of view, I downloaded TBT RC3 and fiddled around it to get it building fine on Linux. However, I am stuck with a SIGSEGV that I am sure will take an eon for me to weed out. Am at it, but if someone could lend a hand, it would be much appreciated.

Here is the GDB bt :

Code: Select all

#0 0xb7c95d27	mspace_free(msp=0x0, mem=0xb32ac008) (../../OgreMain/src/nedmalloc/malloc.c.h:5170)
#1 0xb7c97459	nedalloc::nedfree(mem=0xb32ac008) (../../OgreMain/src/nedmalloc/nedmalloc.c:155)
#2 0xb7c2a0e8	~Image(this=0xa904280) (../../OgreMain/include/OgreMemoryNedAlloc.h:69)
#3 0xb7ab346c	std::_Destroy<Ogre::Image>(__pointer=0xa904280) (/usr/include/c++/4.3/bits/stl_construct.h:88)
#4 0xb7ab3481	std::_Destroy<Ogre::Image*>(__first=0xa904280, __last=0xa904330) (/usr/include/c++/4.3/bits/stl_construct.h:103)
#5 0xb7ab34a7	std::_Destroy<Ogre::Image*, Ogre::Image>(__first=0xa904280, __last=0xa904330) (/usr/include/c++/4.3/bits/stl_construct.h:128)
#6 0xb7ab3b52	~vector(this=0xbfa51808) (/usr/include/c++/4.3/bits/stl_vector.h:300)
#7 0xb7ab249d	TBT::TileTextureManager::createTextureAtlas(this=0x9fe18e8, terrain_type=@0xbfa5192c, deleteTextures=true) (/home/balajee/ogre/ogreaddons/TiledSceneManager RC3/source/tile_Texture_Manager.cpp:164)
#8 0x8054ba4	TutorialApplication::loadTextures(this=0xbfa51b24) (/home/balajee/ogre/ogreaddons/TiledSceneManager RC3/demo/main.cpp:49)
#9 0x805b635	TutorialApplication::createScene(this=0xbfa51b24) (/home/balajee/ogre/ogreaddons/TiledSceneManager RC3/demo/main.cpp:153)
#10 0x805c8b0	ExampleApplication::setup(this=0xbfa51b24) (/home/balajee/ogre/Samples/Common/include/ExampleApplication.h:138)
#11 0x805cbdc	ExampleApplication::go(this=0xbfa51b24) (/home/balajee/ogre/Samples/Common/include/ExampleApplication.h:89)
#12 0x804f267	main() (/home/balajee/ogre/ogreaddons/TiledSceneManager RC3/demo/main.cpp:190)
And as you can see the problem must be somewhere, here:

Code: Select all

void TileTextureManager::createTextureAtlas(const std::string &terrain_type, bool deleteTextures)
{
  /////////////////////////////////////////////////////////////////////////
  /// Create texture atlas and mipmaps
  /////////////////////////////////////////////////////////////////////////
  std::cout << "Creating texture atlas" << std::endl;
  int x=0, y = 0;

  int levels = 0;
  for( int pix = mTileTextureSize; pix >= MIN_TEXTURE_PIXELS; pix /= 2 )
    ++levels;

  std::vector< Ogre::Image > textureAtlas (levels);

  //reserve memory for the texture atlas (and its mipmaps)
  for( int level = 0, pix = mTileTextureSize; pix >= MIN_TEXTURE_PIXELS; pix /= 2, ++level ) {
    uchar* textureAtlas_data = new uchar[pix*TEXTURES_PER_ROW_ROUNDED * pix*TEXTURES_PER_ROW_ROUNDED * 4];
    textureAtlas[level].loadDynamicImage(textureAtlas_data, pix*TEXTURES_PER_ROW_ROUNDED, pix*TEXTURES_PER_ROW_ROUNDED, 1, PF_A8B8G8R8, true);
  }

  x=0, y = 0;
  for (int i = 0; i < mTextureCount; ++i ) {
    Image *pTexture;
    pTexture = mTextures[i];
    pTexture->resize( mTileTextureSize, mTileTextureSize );

    for( int pix = mTileTextureSize, level = 0 ; pix >= MIN_TEXTURE_PIXELS; pix /= 2, ++level ) {
      if ( level > 0 ) {
        //std::cout << "Scaling down texture.." << std::endl;
        PixelBox src = pTexture->getPixelBox();
        PixelBox dst( src.getWidth()/2, src.getHeight()/2, src.getDepth(), src.format, src.data );
        Image::scale( src, dst, Image::FILTER_BILINEAR );
      }

      //std::cout << "Adding texture to group texture..." << std::endl;
      uchar* textureAtlas_data = textureAtlas[level].getData();
      addToTextureAtlas(textureAtlas_data, pTexture->getData(), pix, x, y);
    }
    if(deleteTextures)
      delete mTextures[i];
    mTextures[i] = 0;
    pTexture = 0;

    if (++x == TEXTURES_PER_ROW) {
      if (++y == TEXTURES_PER_ROW) {
        break;
      }
      x = 0;
    }
  }

  /* //remove comments if you want the textures to be saved
  std::cout << "Saving textures..." << std::endl;
  for ( int k = 0; k < textureAtlas.size(); ++k )
    textureAtlas[k].save(PATH_TILE_TEXTURES+terrain_type+"_texture_"+ StringConverter::toString(textureAtlas[k].getWidth(), 4, '0') + ".png");
  */

  TexturePtr TileTexture;
  int pixTerrain = mTerrainTextureSize;

  //Create material and assign texture to use for it
  TileTexture = TextureManager::getSingleton().createManual(terrain_type+"_texture_high",
                 "General",TEX_TYPE_2D, pixTerrain, pixTerrain, textureAtlas.size()-1, PF_R8G8B8A8, TU_STATIC_WRITE_ONLY);


  for ( int i = 0, pixTile = mTileTextureSize; pixTile >= MIN_TEXTURE_PIXELS; pixTile /= 2, ++i )
    TileTexture->getBuffer(0,i)->blitFromMemory(textureAtlas[i].getPixelBox());
}
I guess no one is maintaining this anymore, but hate to see such good work go waste.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: a tilebased terrain manager

Post by jacmoe »

While I haven't any specific advice to give you, I'll just mention that you need to define *no one*.
AFAIK, there's three projects using this terrain manager: Daimonin, CodeBlack and Trosan's project.
It seems like Trosan dropped off the radar, which is unfortunate.
Maybe compare his version to what's in the Daimonin source tree? :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Redwolf
Kobold
Posts: 35
Joined: Sun Feb 24, 2008 12:12 am

Re: a tilebased terrain manager

Post by Redwolf »

I have built this with a few adaptions on Linux/Ogre-1.6.4.

But starting it results in it hanging with 100% CPU after printing

Code: Select all

Creating texture atlas
There are no system calls, just some kind of CPU loop.

Does that look familiar to anyone?

Code: Select all

Finished parsing scripts for resource group Internal
Texture: morning.jpg: Loading 6 faces(PF_R8G8B8,512x512x1) with 5 generated mipmaps from multiple Images. Internal format is PF_X8R8G8B8,512x512x1.
Texture: waves2.dds: Loading 1 faces(PF_A8R8G8B8,256x256x1) with 5 generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x256x1.
Creating texture atlas
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7fa3ebe936f0 (LWP 960)]
Ogre::Resource::load (this=0x1baf340, background=false) at ../../OgreMain/include/OgreAtomicWrappers.h:318
318                 return mField;
(gdb) bt
#0  Ogre::Resource::load (this=0x1baf340, background=false) at ../../OgreMain/include/OgreAtomicWrappers.h:318
#1  0x0000000000417119 in TBT::TileChunk::loadMesh (this=0xcd3fb0, quality=0) at tile_Chunk.cpp:151
#2  0x0000000000417306 in TBT::TileChunk::loadResource (this=0xcd3fb0, aRes=0x1baf340) at tile_Chunk.cpp:324
#3  0x00007fa3eb7b9b63 in Ogre::Resource::load (this=0x1baf340, background=<value optimized out>) at OgreResource.cpp:207
#4  0x00007fa3eb733148 in Ogre::MeshManager::load (this=<value optimized out>, filename=<value optimized out>, groupName=<value optimized out>, 
    vertexBufferUsage=<value optimized out>, indexBufferUsage=<value optimized out>, vertexBufferShadowed=<value optimized out>, 
    indexBufferShadowed=<value optimized out>) at OgreMeshManager.cpp:126
#5  0x00007fa3eb6916a4 in Ogre::EntityFactory::createInstanceImpl (this=<value optimized out>, name=@0x7ffff3fe5fb0, 
    params=<value optimized out>) at OgreEntity.cpp:2092
#6  0x00007fa3eb746851 in Ogre::MovableObjectFactory::createInstance (this=0x1baf340, name=@0x0, manager=0xcc7970, params=0x3)
    at OgreMovableObject.cpp:429
#7  0x00007fa3eb7f2454 in Ogre::SceneManager::createMovableObject (this=0xcc7970, name=@0x7ffff3fe5fb0, typeName=@0x7fa3ebbb4ee8, 
    params=0x7ffff3fe5ee0) at OgreSceneManager.cpp:6139
#8  0x00007fa3eb7f8153 in Ogre::SceneManager::createEntity (this=0xcc7970, entityName=@0x7ffff3fe5fb0, meshName=@0x1baf360)
    at OgreSceneManager.cpp:502
#9  0x0000000000415651 in TBT::TileChunk::load (this=0xcd3fb0) at tile_Chunk.cpp:333
#10 0x000000000041c74e in TBT::TileManager::updateLoadingQueue (this=0x1aa88c0, camPos=@0x7ffff3fe60a0, loadInstantly=true)
    at tile_Manager.cpp:125
#11 0x0000000000418e59 in TBT::TileInterface::controlChunks (this=0x1fe4bc0, timeSinceLastFrame=0, loadImmediately=true)
    at tile_Interface.cpp:237
#12 0x000000000040d3c9 in TutorialApplication::createSampleMap (this=0x7ffff3fe64e0, width=256, height=256) at main.cpp:93
#13 0x0000000000413b3d in TutorialApplication::createScene (this=0x7ffff3fe64e0) at main.cpp:154
#14 0x0000000000414e44 in ExampleApplication::setup (this=0x7ffff3fe64e0)
    at /home/cracauer/work/ogre-stable-work/ogre//Samples/Common/include/ExampleApplication.h:138
#15 0x00000000004151d2 in ExampleApplication::go (this=0x7ffff3fe64e0)
    at /home/cracauer/work/ogre-stable-work/ogre//Samples/Common/include/ExampleApplication.h:89
#16 0x0000000000406033 in main (argc=1, argv=0x7ffff3fe6618) at main.cpp:188
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: a tilebased terrain manager

Post by jacmoe »

Redwolf wrote:Does that look familiar to anyone?
Yes, it does.
You posted the *exact* same thing in an Iris2 topic yesterday..
Are you really *sure* you're building the tilebased terrain manager, and not something else?

<edit>
Right: you are in the right topic now. Just read your message in the Iris2 topic - thanks for clearing that up.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: a tilebased terrain manager

Post by xavier »

#0 Ogre::Resource::load (this=0x1baf340, background=false) at ../../OgreMain/include/OgreAtomicWrappers.h:318
What's the code listing there?
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
Redwolf
Kobold
Posts: 35
Joined: Sun Feb 24, 2008 12:12 am

Re: a tilebased terrain manager

Post by Redwolf »

xavier wrote:
#0 Ogre::Resource::load (this=0x1baf340, background=false) at ../../OgreMain/include/OgreAtomicWrappers.h:318
What's the code listing there?

Code: Select all

namespace Ogre {

    template <class T> class AtomicScalar {

        public:
[...]
        T get (void) const
        {
            // no lock required here
            // since get will not interfere with set or cas
            // we may get a stale value, but this is ok
            return mField; // <== this is line 318
        }
I apologize for the screwup with Iris. I followed a link from my previous tread where people pointed me to both this thread and the Iris thread and ended up in the wrong one.
User avatar
hairymunky
Gnoblar
Posts: 5
Joined: Sat Jul 03, 2004 9:18 pm
Location: Scotland

Re: a tilebased terrain manager

Post by hairymunky »

Came accross this the other day, and thought I'd take it for a test-drive. Like a few people before this post,
I get a run-time error (Win32), and have been going cross-eyed trying to figure out what was causing it...

In the function: (tile_Texture_Manager.cpp)

Code: Select all

createTextureAtlas(const std::string &terrain_type, bool deleteTextures)
The very last command is pushing the texture data to the GPU (I think Ive got it right):

Code: Select all

  for ( int i = 0, pixTile = mTileTextureSize; pixTile >= MIN_TEXTURE_PIXELS; pixTile /= 2, ++i )
    TileTexture->getBuffer(0,i)->blitFromMemory(textureAtlas[i].getPixelBox());
As far as I can figure out, the error is thrown by the std::vector 'textureAtlas' going out of scope and being cleaned up??
Anyone else got this working, or am I looking in the wrong place..??

HM
Trosan
Greenskin
Posts: 101
Joined: Sun Jun 10, 2007 4:57 pm
x 1

Re: a tilebased terrain manager

Post by Trosan »

It seems like Trosan dropped off the radar, which is unfortunate.
That's not completely true, though the work on the project is being halted at the moment. :/ (will be continued, hopefully next year, but can't promise).


I guess that the issues you run into arise from the fact that the latest version of TBT was written for 1.5. So there is no support for the (now required) custom memory allocators. You should be able to comment out the line

Code: Select all

createTextureAtlas(..)
and run your code. You won't see any textures then, but it should work nonetheless. Perhaps you can also find the line where memory is not allocated correctly using the OGRE allocators.
swuth
Bronze Sponsor
Bronze Sponsor
Posts: 53
Joined: Wed Mar 25, 2015 10:01 pm

Re: a tilebased terrain manager

Post by swuth »

I would be VERY interested in downloading this tile map based terrain system. The link is however dead. Anyone have an up to date link for this? It seems to be exactly what I am looking for.

Thanks
User avatar
shadowfeign
Goblin
Posts: 213
Joined: Mon Jan 26, 2009 11:51 pm
x 15

Re: a tilebased terrain manager

Post by shadowfeign »

try the link a few posts up. http://www.ogre3d.org/forums/viewtopic. ... 10#p300910

Edit* It should also be noted that this is really old, you'll probably have to make a few minor modifications to get it to work. Also if you read through the thread, there is I think 2 or 3 versions customized for this or that specific game that all loosely started with the same code.
Post Reply