Ogre Forums

sinbad wrote: The reason I went for raw floats for the heights is that I didn't want to limit the core to a set precision (like 8- or 16-bit). This way, the min/max of the terrain is unbounded (well, within reason), meaning it's a lot more flexible - it can accurately represent terrains that would be impossible to store in even a 16-bit PNG without data loss. I allowed for importing from lower-precision sources but when saving, the full float data is the only lossless way - even exporting to 16-bit PNG will lose some precision. If people want to process the data in external tools then you can provide export functions in your editor, but you'd have to accept that precision loss unless you use a float format. I didn't include an export to PNG or similar because I didn't really want to encourage this, preferring to advocate a 1-way conversion from these 'lesser' formats.

KungFooMasta wrote:I was looking more at the Terrain interface, how its used, and I saw this:

Code: Select all

		/// Save terrain data in native form
		void save(StreamSerialiser& stream);

I'm trying to figure out what the data looks like in "native" form, but I haven't made use of Ogre's Stream classes before. The Constructor for a StreamSerialiser takes a DataStreamPtr... how can I simply write this data to a text file?

Also, what exactly is a Layer? Its like a material pass, that can support up to X number of Textures? What does the "WorldSize" of the Layer mean?

You remember problems during using ETM? Each layer had a fixed repeat count which you couldnt change, in Ogre::Terrain you can define the repeat count (by using WorldSize) so each layer can repeat at different scales...

CABAListic wrote: Technically you could, since this is just a shader property. My example shaders used single repeat parameters for all layers, but you could just as easily have defined multiple But if the new Terrain components makes it easier, all the better - only reassures me that it was a good idea to retire ETL in favour of the new Terrain component.

avalanche_raptor wrote:Jus wanted to know.... When will we be able to get our hands on this..... I mean is the svn head stable enough to use right now? or would you reccomend waiting for a stable version??

KungFooMasta wrote:I'm trying to figure out what the data looks like in "native" form, but I haven't made use of Ogre's Stream classes before. The Constructor for a StreamSerialiser takes a DataStreamPtr... how can I simply write this data to a text file?

stealth977 wrote:in current implementation (DefaultMaterialGenerator) a layer has a DIFFUSE and a NORMAL texture, and there can be 6 Layers total in a MATERIAL PASS.

KungFooMasta wrote: Last question, is there a process for creating mutliple terrain pages? I've looked at the Terrain class and haven't seen anything that would allow me to create paged terrain. It actually looks like the Terrain class can be created several times. I doubt creating multiple Terrain instances would be the way to go, right? (There is no enforcement of size)

KungFooMasta wrote:

Code: Select all

			/// List of texture names to import; must match with TerrainLayerDeclaration
			StringVector textureNames;

This kind of suggests a layer can have more than 1 texture assigned to it. By 2 sampler units, does this mean we can have 2 textures per layer? Or am I totally confused?

Also, it seems like the binary file will be the most used format? As stealth mentioned, png's have limits in their values, 8bit or 16bit, but the inputScale field allows you to stretch png data out vertically to make the terrain match any 3d world height. In an editor application users would be able to deform terrain to exceed the limits of 8/16 bit png, in which case the data can only be stored/reloaded properly if its in binary format. Is this right?

Is anybody familiar with data streams and can throw out some reference code? I'm familiar with the Mesh/MaterialSerializer, but those have APIs that make everything super simple, ie:

      DataStreamPtr stream;
      // set up stream
      StreamSerialiser ss(stream);
      mTerrain->save(ss);

stream = myArchive->create(filename);

stream = ResourceGroupManager::getSingleton().createResource(filename);
// (check out the optional parameters to be more specific about where the file is created)

std::fstream fstr(filename, std::ios::out|std::ios::binary);
stream = DataStreamPtr(OGRE_NEW FileStreamDataStream(&fstr, false));

FILE* fp = fopen(filename, "wb");
stream = DataStreamPtr(OGRE_NEW FileHandleDataStream(fp));

stormfornever wrote:Why parralax map when you can you use ConeStepMap ?
ConeStepMap did not work better and more MORE MOOOORE FASTER ?

lickstab wrote:awesome, thanks. i used getHeightAtPoint().

i managed to build an OgreNewt::TreeCollision based on the terrain, and it matches the shape perfectly, however the polys are shaped oddly.
instead of forming a grid like i'd expected, they make little "stripes", and mostly don't block things from falling through.
admittedly i'm no expert and just experimenting.
is there any "obvious"/common mistake that would result in the polys looking this way?

float DeltaPos = (WorldSize / 2.0f);
float Scale = WorldSize / (float)(MapSize - 1);
Ogre::Vector3((Scale * X) - DeltaPos, mapptr[(MapSize * Z) + X], (Scale * -Z) + DeltaPos);

Xplodwild wrote:Is it possible to load maps created with ETM in Terrain Manager ? Because there's a lot of work already done and my artists won't mind recreating everything ^^ . I read the whole topic and didn't saw that Terrain is editable, maybe I missed something ? Thanks anyway for the news.

Xplodwild wrote:@lickstab : Can you share your code ? I think it will be very appreciated by all OgreNewt users (like me) :)

// build an OgreNewt collision mesh based on a "new ogre terrain" terrain
void joey::UpdateTerrainBody()
{
	if(TerrainBody != NULL)
		delete TerrainBody;

	// credits to stealth977 @ http://www.ogre3d.org/forums/ for pointing me in the right direction

	// get height data, world size, map size
	float *mapptr = myTerrain->getHeightData();
	float WorldSize = myTerrain->getWorldSize();
	int MapSize = myTerrain->getSize();
	// calculate where we need to move/place our vertices
	float DeltaPos = (WorldSize / 2.0f);
	float Scale = WorldSize / (float)(MapSize - 1);

	// build vertices
	float* vertices = new float[(MapSize*MapSize) * 3];

	int i = 0;
	int max = MapSize; // i think i needed this for something before but now it's obviously redundant
	int z = 0;
	for(int x = 0;; ++x)
	{
		// if we've reached the right edge, start over on the next line
		if(x == max)
		{
			x = 0;
			++z;
		}
		// if we reached the bottom/end, we're done
		if(z == max)
			break;
	
		// insert vertex
		vertices[i] = (Scale*x) - DeltaPos;
		vertices[i+1] = mapptr[(MapSize*z)+x] - 0.5f; // i put the collision shape slightly lower, because before objects would appear to be floating just above the terrain instead
		vertices[i+2] = (Scale * -z) + DeltaPos;

		i += 3;
	}

	// i think this is right, seems to be
	int size = ((MapSize*MapSize)-(MapSize*2)) * 6;
	int* indices = new int[size];

	// i will point to the 'indices' index to insert at, x points to the vertex # to use
	i = 0;
	for(int x = 0;;++x)
	{
		// skip rightmost vertices
		if((x+1)%MapSize == 0)
		{
			++x;
		}
		
		// make a square of 2 triangles
		indices[i] = x;
		indices[i+1] = x + 1;
		indices[i+2] = x + MapSize; 

		indices[i+3] = x + 1;
		indices[i+4] = x + 1 + MapSize;
		indices[i+5] = x + MapSize;

		// if we just did the final square, we're done
		if(x+1+MapSize == (MapSize*MapSize)-1)
			break;

		i += 6;
	}

	// build our collision shape
	OgreNewt::Collision* TerrainShape = new OgreNewt::CollisionPrimitives::TreeCollision(nWorld, MapSize*MapSize, size, vertices, indices, false);
	// .. and our body
	TerrainBody = new OgreNewt::Body(nWorld, TerrainShape);

	// cleanup
	delete TerrainShape;
	delete [] vertices;
	//delete [] indices; // my program crashes on this line and i'm not sure why, i thought i wouldn't need 'indices' anymore
}