Page 4 of 21

Posted: Thu Apr 26, 2007 7:17 pm
by CABAListic
No, it's not about reducing or removing features, it's about decoupling them. As it's now, the dynamic material is tied so much that you cannot decide not to use it even if you don't need it. That's not the case for an Entity ;) The more problematic part is that you can't change the material if you need to. That's exactly the problem you faced with wireframe rendering - you needed to change ETSM code for that.
Or, another example: For my own project I intend to use custom texture mapping which will require a custom material. In its current form ETSM does not have any capabilities to cope with custom terrain.

Even more so, a decoupled material manager could even be used with the standard terrain scene manager if you do not need deforming. It would also make transition from TSM to ETSM easier because you don't need to switch to splatting if all you need is deforming.

It just feels like you want to split up the ETSM into parts so everybody can do their own thing with it and not give back to the community.
Giving or not giving back to the community is not primarily a concern of how a piece of software is built. You could have kept your wireframe modifications to yourself even now (unless you were to release a project which makes use of this, because then LGPL would force you to ;) ). Equally you could post or not a modification or addon to a separated material manager.

Posted: Thu Apr 26, 2007 7:17 pm
by jjp

Sorry, I don't see how that approach is "not giving back to the community". It would be of use for more people when split up. And no matter how our software will be structured in the end, it is all gonna be LGPL. So it's all cool I hope :)

Posted: Thu Apr 26, 2007 7:32 pm
by KungFooMasta
So it's all cool I hope
Yep! :)


Posted: Thu Apr 26, 2007 8:05 pm
by jacmoe
asmo wrote:Look what happend to PLSM2, it tries to be everything. Do one thing, and do it damn well (:
I object to that! :!:
PLSM2 is an excellent project, the most succesful ogre addon, ever.
It does not try to be everything - it *is* everything! :twisted:

No, seriously. :)

But, I agree that de-coupling is a good thing, and CABAListic is doing excellent thinking.

Posted: Sat May 05, 2007 9:13 pm
by KungFooMasta
I'm using OgreOpcode in my game, and currently considering if I should try and use the OgreOpcode TerrainShape class for ground collisions, or if I should mesh together ray casts with OgreOpcode sliding on other objects.

Looking at the OgreOpcode demo, it adds itself as a TerrainPageSource listener, and constructs a shape/collision object whenever the pageConstructed method is called.

Does ETSM use the TerrainPageSource class? I see it listed in OgreTerrainPrerequisites, but nowhere else.

Here is the code from the OgreOpcode example:

Code: Select all

void OgreOpcodeTerrainExample::pageConstructed(TerrainSceneManager* pSceneMgr, size_t pagex, size_t pagez, Real* heightData) 
	LogManager::getSingleton().logMessage("PageConstructed called.");
	Vector3 Offset(0,0,0); // Set to something if required
	Vector3 iScale(0,0,0);
	int iPageSize(0);
	int iTileSize(0);
	iScale = static_cast<TerrainSceneManager*>(pSceneMgr)->getScale();
	iPageSize = static_cast<TerrainSceneManager*>(pSceneMgr)->getPageSize();
	iTileSize = static_cast<TerrainSceneManager*>(pSceneMgr)->getTileSize();
	int heightDataNum = iTileSize * iTileSize;
	int numIndexes = 0;
	int index_size = (iTileSize) * (iTileSize) * 6;
	int nameCounter = 0;
	//Create indices 
	int* indices = new int[index_size]; 
	for (int x=0;x<iTileSize-1;x++)
		for (int y=0; y<iTileSize-1;y++) 
			indices[(x+y*(iTileSize-1))*6] = (x+1)+(y+1)*iTileSize; 
			indices[(x+y*(iTileSize-1))*6+1] = (x+1)+y*iTileSize; 
			indices[(x+y*(iTileSize-1))*6+2] = x+y*iTileSize; 

			indices[(x+y*(iTileSize-1))*6+3] = (x+1)+(y+1)*iTileSize; 
			indices[(x+y*(iTileSize-1))*6+4] = x+y*iTileSize; 
			indices[(x+y*(iTileSize-1))*6+5] = x+(y+1)*iTileSize; 

	// Loop through all pages
	for ( int startz = 0; startz < iPageSize - 1; startz += ( iTileSize - 1 ) )
		for ( int startx = 0; startx < iPageSize - 1; startx += ( iTileSize - 1 ) )
			//int startx = 0;
			//int startz = 0;
			float* OOData;
			OOData = new float[heightDataNum*3];
			int OODataCounter = 0;
			// This should be a tile
			for(int j = startz;j < (startz + iTileSize); j++)
				for(int i = startx;i < (startx + iTileSize); i++)
					Real height = heightData[j * iPageSize + i];

					Vector3 Pt = Vector3((float) i * iScale.x, (float)height * iScale.y, (float)j * iScale.z);
					// copy it over
					OOData[OODataCounter + 0] = Pt.x;
					OOData[OODataCounter + 1] = Pt.y;
					OOData[OODataCounter + 2] = Pt.z;
					OODataCounter += 3;

			// create new shapes here!
			PtrCollisionShape* tempTerrainShape;
			CollisionObject* tempCollObject;
			String shapeName = "terrainShape" + StringConverter::toString(nameCounter);
			tempCollObject = mCollideContext->createObject(shapeName);
			tempTerrainShape = CollisionManager::getSingletonPtr()->createPtrCollisionShape(shapeName);
			tempTerrainShape->load(heightDataNum*3, index_size, OOData, indices);
			delete[] OOData;
			OOData = 0;
	delete[] indices;
	indices = 0;
I believe the tileSize in the code would be the same as ETOptions::tileSize, but what is the equivalent for PageSize?

:?: Does the function above look like it can be modified to work with ETSM?

:?: If I register a class as a TerrainPageSource listeneter:
Will the class be called for every page that is created?

Thanks for any information/help.


Posted: Sat May 05, 2007 9:26 pm
by CABAListic
I'm not using a TerrainPageSource class and no listener, either. But from a quick glance over the code it doesn't seem as if it uses anything internal to the terrain scene manager, rather it's using the heightmap data. So I should think that it is portable to ETSM.

I'm currently working on the next version of ETSM. Basically I'm in the process of decoupling the components as mentioned. I've taken it as far as making the ETSM not even a scene manager any longer, so it'll just be ETM from then on ;) You can use it on top of the Octree scene manager and you'll get a much more comfortable interface than the getOption/setOption stuff.
The code below will get everything it needs from the then publically exposed struct ET::TerrainInfo. But you'll need to call it manually when you've loaded your terrain because there will still be no concept of listeners or anything like. Shouldn't pose a problem.
I believe the tileSize in the code would be the same as ETOptions::tileSize, but what is the equivalent for PageSize?
The equivalent would be the heightmap width and height. The standard TSM only allows for quadratic terrains, and it has (unused) hooks present for paging, that's why it's called PageSize and why there are things like a PageSource listener.

Posted: Sat May 05, 2007 10:14 pm
by KungFooMasta
Great to hear the next version is in the works! :D
But you'll need to call it manually when you've loaded your terrain because there will still be no concept of listeners or anything like.
That works even better for me, actually. :)

Also, in the next version, will there be an easy way to change the terrain dimensions at run time? This might seem odd, but in my Scene Creator application it would be helpful to change the terrain and view it in real time, even if that requires destroying and recreating the terrain. Currently I open up the cfg file and edit it in notepad, then reload it in the app. Also, this would be most useful with a way to write the scale back out to the cfg. Overall, I don't think any of this would be hard to implement, I'm just hoping it can tie into your exposable parts.

Keep us updated on your progress, I'm ready to switch as soon as its available! :twisted:

[Edit] Also, I noticed that you only work with Raw for heightmap data. Is there a reason you didn't include png? My heightmaps only worked when I set them to greyscale 8 bit and saved them as .raw. 16 bit raw had weird results, and png doesn't work at all. 8 bit raw is acceptible to me, in any case.[\Edit]


Posted: Sat May 05, 2007 10:21 pm
by CABAListic
Well, I will most likely not directly implement any resizing functionality. But you will no longer need config files to setup the terrain, you just need to fill a TerrainInfo struct any way you like. Then you can reload the terrain passing such a structure.
It would basically work like this:
You create an ET::TerrainManager passing the scene manager you wish to use. Then you fill an ET::TerrainInfo any way you like and call TerrainManager::createTerrain(info). The TerrainInfo contains all relevant data like the heightmap, terrain dimensions etc.. Then, whenever you feel like it, you can create a new TerrainInfo from the old with a larger heightmap. Then call destroyTerrain and recall createTerrain. That should do your job.

[Edit]You are mistaken, image heightmaps work just fine, but you must change DataSource to Image.[/Edit]

Posted: Sat May 05, 2007 10:24 pm
by KungFooMasta
Wow, that's a brilliant idea! So really all we need is serialization of the TerrainInfo class. Although that might not be in the scope of ETM anymore. That works for me also, since I use TinyXML to save all my other data to disk.

This is exciting, sorry about doubting you earlier, this makes things a lot easier to implement and use!

[Edit] Any Scene Managers? How does that work? Should we be using Octree SM or TSM? [\Edit]


Posted: Sat May 05, 2007 10:32 pm
by CABAListic
Well, all that the TSM and ETSM really do is create a bunch of renderables (the terrain tiles) which are then managed by the Octree scene manager, anyway (both TSM and ETSM currently inherit from the Octree SM). So I figured I could do without inheriting and just make a standalone terrain manager that can work on top of a standard Octree SM instance. Theoretically you could use any other scene manager, too, but depending on their individual strategies to manage renderables this may or may not work well or work at all, I don't know :) You can of course use TSM, since it is an extended Octree SM, but that wouldn't make too much sense, would it? ;)

Posted: Sat May 05, 2007 10:48 pm
by asmo
jacmoe wrote:
asmo wrote:Look what happend to PLSM2, it tries to be everything. Do one thing, and do it damn well (:
I object to that! :!:
PLSM2 is an excellent project, the most succesful ogre addon, ever.
It does not try to be everything - it *is* everything! :twisted:

No, seriously. :)

But, I agree that de-coupling is a good thing, and CABAListic is doing excellent thinking.
Sorry if I'm hijacking the thread, I just have to say that I do not agree on this. PLSM2 is broken. The core could have worked quite well without the functions around it (like setHeight, for example) which are broke.
Jacmoe, have you used the current version PLSM2? :/

Posted: Sat May 05, 2007 11:00 pm
by KungFooMasta

My game is set to be done in *scenes*, similar to console stype RPGs. You run to the top of the map, the screen goes black, then you find yourself in the next scene. Essentially I'm destroying everything and recreating a new scene from file. Is there any way to load multiple terrains? This would add quite a bit more work for me (LOD, what to show in neighbor scene, etc.), but it would be one step further to having a somewhat seemless world, while being easy to manage.



Posted: Sat May 05, 2007 11:05 pm
by CABAListic
That would a job for paging. I'm afraid I can't offer you that, you'll have to hope for PLSM3 there...
Well, technically you WILL be able to create and use more than one ET::TerrainManager and you can place their terrain wherever you like. But they are not aware of each other, so due to LOD management they will have cracks at their crossing even if you place them beside each other. And you'd have to implement your own paging mechanism for them.

Posted: Sun May 06, 2007 12:01 am
by KungFooMasta
I guess I can experiment with it when I get to that stage. If I turned off LOD then there would be no problems, and as long as I can deform/texture in real time, it would be pretty easy to match up one scene to another. (There is a way to disable all LOD for ETM terrain, right?)

Noob question - Can 2 scene managers exist in the same world space? (no experience with this) So that I can make 2 terrains next to each other? I could just have the root scene node make a base node for each scene?


Posted: Sun May 06, 2007 10:27 am
by CABAListic
I don't know, but you won't need two scene managers. You can just create two (or more) ET::TerrainManagers for the same SceneManager.
And yes, you can disable LOD altogether (just set the MaxMipMapLevel to 1), but it will hurt your performance :)

Posted: Sun May 06, 2007 7:37 pm
by KungFooMasta
Back on the OgreOpcode useage, I just remembered that as a listener, I get notified for every page that is created, and make a collision object for every page. You said I will have to manually make calls myself, which is fine, but I am unfamiliar with how terrain works internally. Are pages created and destroyed multiple times? Will the ETMInfo provide access to all pages? I'm hoping pages don't get destroyed/created frequently, since I don't have any way to know which pages were destroyed/created, I would have to re-create collision objects for every page.


Posted: Sun May 06, 2007 9:33 pm
by CABAListic
The ETM does not have a concept of paging ;) It's only internally dividing the terrain into tiles, but they are always loaded as long as your terrain is loaded. You could do a sort of paging with multiple terrain manager instances, but then you'd need to implement the paging behaviour yourself, so YOU would decide when a "page" is destroyed/reloaded.

Posted: Sun May 06, 2007 9:51 pm
by KungFooMasta
The Page Listener class comes from TSM. I don't need paging or anything, the current terrain works great for me. All I'm wondering is how I can use the ETMInfo to create a OgreOpcode collision object which was done for TSM terrain. I guess I will have to wait for the release.. maybe then I'll have some concrete questions. :wink:

Not pushing or anything, but how goes progress?

Thanks for answering all my questions!


Posted: Sun May 06, 2007 9:59 pm
by CABAListic
Progress, well. I have changed the terrain tiles and the terrain manager to my new concept and in the process removed all those annoying signed/unsigned compiler warnings by changing a couple variables to unsigned data types. That probably means I now have a bunch of code which compiles cleanly but no longer works :D I don't know, I'm not yet far enough to actually test my changes, hehe. I'm currently writing the splatting manager which manages the splatting coverage textures. And when that's done, I'll bring all the convenience functions that are not technically necessary but will ease the use of ETM. I think I'll need at least this week to get the job done properly, but we'll see.

Posted: Thu May 10, 2007 3:36 pm
by Ayrik
I have to say that I like the idea of turning ETSM into ETM, and I really hope it works out. Do you have an ETA on a source release?

Posted: Thu May 10, 2007 4:00 pm
by CABAListic
I'm making progress, though not as quickly as I'd hoped. Maybe this weekend, but it could easily take till next weekend.

Posted: Thu May 10, 2007 9:57 pm
by KungFooMasta
CABAListic, is it possible to send me ETM in its current state this Sunday? Even if it's not finished, or even if it doesn't work, the new interface will allow me to work on other things that depend on use of ETM. Even if the interface isn't 100% concrete it will be helpful to me :)


Posted: Thu May 10, 2007 10:30 pm
by CABAListic
Err, well, if you want it so eagerly, I suggest you download the bzr version control system from and then do

Code: Select all

bzr checkout
That's the code base I'm working on ;)
But it's in no usable state. Part of the files are from ETSM, others for ETM, because it's right in the transition. You won't be able to compile it or use it, and since the interface is not final, I'd rather spend working on it than explaining it ;)

Posted: Thu May 10, 2007 10:44 pm
by KungFooMasta
Thanks CABAListic!

I have some other things to work on until Sunday, but I'm very anxious to get back on my game. :)

I tried to do a checkout at my work, but I'm not sure if it's being blocked, or I'm not using bzr correctly:

Code: Select all

D:\non-work>bzr checkout
bzr: ERROR: Connection error: curl connection error (Could not resolve host: (Domain name not found)) on

Code: Select all

D:\non-work>bzr help
Bazaar -- a free distributed version-control tool

Basic commands:
  bzr init           makes this directory a versioned branch
  bzr branch         make a copy of another branch

  bzr add            make files or directories versioned
  bzr ignore         ignore a file or pattern
  bzr mv             move or rename a versioned file

  bzr status         summarize changes in working copy
  bzr diff           show detailed diffs

  bzr merge          pull in changes from another branch
  bzr commit         save some or all changes

  bzr log            show history of changes
  bzr check          validate storage

  bzr help init      more help on e.g. init command
  bzr help commands  list all commands
  bzr help topics    list all help topics

I don't even see "checkout" in the list of available commands! :lol:

[Edit]I see the checkout command now, under "bzr help commands"[/Edit]

I'm running this on a vista machine, but at home will be on WinXP, if that matters or not.

If its too much trouble I'll just wait it out.


Posted: Thu May 10, 2007 10:49 pm
by CABAListic
It can't resolve the hostname which is definitely valid. So I guess your work's internet connection is filtering it ;)