Editable Terrain Manager [v2.2 released]

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by CABAListic »

Just use the function TerrainManager::setHeights to override the region you want to smooth. Changing the TerrainInfo directly would indeed not do anything at all (actually, if you tried to modify the one you get via getTerrainInfo, you would receive an error because that one is const).

In future (ETM v3) though, all the editing functions will likely move to the Heightmap. Modifications will then be forwarded to the patches via listener interfaces.

Kerion
Goblin
Posts: 235
Joined: Wed Feb 05, 2003 5:49 am
Contact:

Post by Kerion »

Ahh, I see what your saying. Create the 2D smoothing array as a brush using the filter, then apply that brush to the terrain. The brush should basically contain the final height values then?

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by CABAListic »

Yes, exactly.

Kerion
Goblin
Posts: 235
Joined: Wed Feb 05, 2003 5:49 am
Contact:

Post by Kerion »

Okay, I got a pretty decent smoothing function working. Here's the code, it's in C#, sorry. Should be easy enough to translate to C++. It's very brute force, so there may be a more elegant way to do some of what I am doing, but this works.

Code: Select all

public enum SampleType {
    Small,
    Large
}

private float BuildFactor (MET.Brush heights, int x, int y, ref float factor) {
    if(x >= 0 && x < (int)heights.Width && y >= 0 && y < (int)heights.Height) {
        factor += 1.0f;
        return heights[(uint)x, (uint)y];
    }

    return 0.0f;
}

private MET.Brush BoxFilterPatch (int x, int z, int w, int h, SampleType type, MET.Brush intensity) {
    MET.Brush ret = new MET.Brush (new float[w * h], (uint)w, (uint)h);
    MET.Brush heights = new MET.Brush (new float[w * h], (uint)w, (uint)h);

    m_Manager.GetHeights (x, z, heights);
    for (uint ix = 0; ix < heights.Width; ix++ ) {
        for(uint iy = 0; iy < heights.Height; iy++) {
            int px1 = (int)ix - 1, px2 = (int)ix + 1;
            int py1 = (int)iy - 1, py2 = (int)iy + 1;

            float height = heights[ix, iy];

            float final = 0.0f;
            float factor = 0.0f;                   

            // Sample grid
            // 1 4 7
            // 2 5 8
            // 3 6 9

            if(type == SampleType.Large) {
                final += BuildFactor (heights, px1, py1, ref factor); // 1
                final += BuildFactor (heights, px1, py2, ref factor); // 3
                final += BuildFactor (heights, px2, py1, ref factor); // 7
                final += BuildFactor (heights, px2, py2, ref factor); // 9
            }

            final += BuildFactor (heights, (int)ix, (int)iy, ref factor); // 5

            final += BuildFactor (heights, px1, (int)iy, ref factor); // 2
            final += BuildFactor (heights, (int)ix, py1, ref factor); // 4
            final += BuildFactor (heights, (int)ix, py2, ref factor); // 6                    
            final += BuildFactor (heights, px2, (int)iy, ref factor); // 8

            final /= factor;
            float delta = height - final;
            float intens = intensity[ix, iy];
            if(intens > 0.0f) {
                delta *= intens;
            }

            final = height - delta;
            ret[ix, iy] = final;
        }
    }
    
    return ret;
}

// Usage
MET.Brush smooth = BoxFilterPatch (x, z, 16, 16, SampleType.Small, myRegularDrawingBrush);
myTerrainManager.SetHeights (x, z, smooth);
Basically, you pass it in the x, z of the mouse click point (just like deformation), the width and height of the brush you want it to return, the sample size (8 or 4 pixel samples) and the template brush you want to base the final smooth on. This would be your brush "shape".

It then does a brute force box filter using either the 4 adjacent or 8 adjacent pixels, depending on the sample size. It then multiplies the delta by the template brush height (I call this intensity in the code) and then figures out the final height using that delta. The returned brush is then applied to the terrain using SetHeights at the given x and z.

Small sample sizes seem to give the best results if you want a 16x16 or larger brush (which btw, is a very large smoothing area). If you use a smaller brush, 8x8 or 4x4, a large sample size gives nice results.

For ease of translation, anywhere I am indexing in to an object like brush[x,y] or heights[x,y], that's basically like calling the at() function on those objects in C++. That's the only part of the C# code I think most people would find sticky.

User avatar
tdev
Silver Sponsor
Silver Sponsor
Posts: 244
Joined: Thu Apr 12, 2007 9:21 pm
Location: Germany
x 14

Post by tdev »

Kerion wrote:Okay, I got a pretty decent smoothing function working. Here's the code, it's in C#, sorry. Should be easy enough to translate to C++. It's very brute force, so there may be a more elegant way to do some of what I am doing, but this works.
big thanks for sharing, working great! :)

i converted it into c++ :

Code: Select all

enum SmoothSampleType {SST_Small, SST_Large};
ET::Brush boxFilterPatch(int x, int z, int w, int h, enum SmoothSampleType type, ET::Brush intensity);
float buildFactor(ET::Brush heights, int x, int y, float &factor);



float buildFactor (Brush heights, int x, int y, float &factor)
{
	if(x >= 0 && x < (int)heights.getWidth() && y >= 0 && y < (int)heights.getHeight())
	{
		factor += 1.0;
		return heights.at(x, y);
	}

	return 0.0f;
}

Brush boxFilterPatch(int x, int z, int w, int h, enum SmoothSampleType type, Brush intensity)
{
	std::vector<float> retBuf;
	retBuf.resize(w*h);
	std::vector<float> heightsBuf;
	heightsBuf.resize(w*h);
	Brush ret = Brush(retBuf, w, h);
	Brush heights = Brush(heightsBuf, w, h);
	
	mTerrainMgr->getHeights(x, z, heights);
	for (uint ix = 0; ix < heights.getWidth(); ix++ )
	{
		for(uint iy = 0; iy < heights.getHeight(); iy++)
		{
			int px1 = (int)ix - 1, px2 = (int)ix + 1;
			int py1 = (int)iy - 1, py2 = (int)iy + 1;

			float height = heights.at(ix, iy);

			float final = 0.0f;
			float factor = 0.0f;                   

			// Sample grid
			// 1 4 7
			// 2 5 8
			// 3 6 9

			if(type == SST_Large) {
				final += buildFactor (heights, px1, py1, factor); // 1
				final += buildFactor (heights, px1, py2, factor); // 3
				final += buildFactor (heights, px2, py1, factor); // 7
				final += buildFactor (heights, px2, py2, factor); // 9
			}

			final += buildFactor (heights, (int)ix, (int)iy, factor); // 5

			final += buildFactor (heights, px1, (int)iy, factor); // 2
			final += buildFactor (heights, (int)ix, py1, factor); // 4
			final += buildFactor (heights, (int)ix, py2, factor); // 6                   
			final += buildFactor (heights, px2, (int)iy, factor); // 8

			final /= factor;
			float delta = height - final;
			float intens = intensity.at(ix, iy);
			if(intens > 0.0f) {
				delta *= intens;
			}

			final = height - delta;
			ret.at(ix, iy) = final;
		}
	}
   
	return ret;
}
how you could use it:

Code: Select all

void smooth(Ogre::Vector3 pos, SmoothSampleType type)
{
	int x = terrainInfo->posToVertexX(pos.x);
	int z = terrainInfo->posToVertexZ(pos.z);
	Brush smooth = boxFilterPatch(x, z, 16, 16, type, mEditBrush);
	mTerrainMgr->setHeights(x, z, smooth);
}

Kerion
Goblin
Posts: 235
Joined: Wed Feb 05, 2003 5:49 am
Contact:

Post by Kerion »

Awesome, thanks for translating the code to C++ :)

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

Following the rule, "Only post about questions you cant find the answer to somewhere already," this is my first post on these forums, heh.

I'm having an odd problem while using the ETM. I don't -think- the problem is an ETM issue really, but I'm not sure where to start looking. Hopefully someone else has run into this.

Precondition:
ETM had been performing without issue using a hardcoded set of splatting textures.

What I changed:
I built a little CEGUI palette to allow the user to graphically pick which texture they were painting, complete with little preview thumbnails of the textures. For each splatting texture I created a CEGUI::Texture (in code) and a CEGUI::Imageset, put the texture in the imageset and defined it as an image. Then displayed them in the "texture selection list" palette.

Postcondition:
The textures on the terrain now look funny.

They look "grainy" at a distance and as you move the camera toward or away from them you see "pixel jitter." It looks to me like texture LoD was disabled, as previously textures on the terrain had appeared smooth at all distances. Textures now appear properly if you look at them closely, but if you move the camera away they exhibit the "bad minification" described above.

-----

So, what I'm wondering is... how did loading the splatting texture images with CEGUI cause this? Or is there another cause that I'm overlooking?


Edit: Edited for grammar

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

Well, I've confirmed that no matter how illogical it seems, loading the images with CEGUI as described above is causing the problem.

I commented out the call to the method that loads the textures into a CEGUI consumable form and the terrain appears properly (as it always had before.)

Here are some screenshots to demonstrate my problem. It is a little hard to see in the screenshots but I assure you, it looks horrendous when the camera is moving.

-----

The only thing that is different between the two detail shots is that I commented out the call to the method that loads the texture images into the texture palette (as seen in the Overview shot.)


Overview (w/bad textures, but it is hard to tell since the image size is reduced):
Image

Detail - good textures:
Image

Detail - bad textures:
Image

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

CABAListic wrote:Actually, that whole listener stuff got me thinking a bit about the overall ETM design. And I got some ideas for ETM 3.0 (i. e. future work, nothing I'll immediately get to):

At the moment, we have a TerrainManager which essentially manages a complete terrain. Internally, it divides the terrain into tiles which are the actual renderables. This is nice enough, but actually prevents people from using the "lower" level parts to assemble their terrains differently or even implement paging.
So, my proposed change is to make the Tile class publically acessible (actually, I think I'd rather call it a Patch in the future, since Tile tends to be highly confusing) with an interface similar to the current TerrainManager and with the added option to connect Patches to each other. A patch would be a MovableObject you'd need to attach to a SceneNode as requested by KungFooMasta. The TerrainInfo class would need an overhaul to allow to pass subareas to create the Patches. All in all, the Patches would form the "lower level" core of the library. (Only thing I need to figure out is where to put the ray and height queries.)
On top of that, I would offer a Page class which essentially mirrors the Patches' functionality, but for a larger, rectangular terrain layout. And this could then be used as the fundament for a paging solution complete with listener architecture and floating origin (but I will not implement this myself unless I should need it for future projects).

In a similar manner, the splatting manager could use a redesign. Basically, the current one would more or less become the "lower level" functionality, with more advanced managers on top of it to allow for optimised splatting. (With optimised splatting I mean that often, you may have a large number of different textures for the whole terrain, but single patches actually only use a limited number of those. With a modified, higher level splatting manager you could take advantage of that so that each patch only splats the textures it actually needs thus making it more GPU-friendly.)

What do you think? As I said, just some ideas for the moment. I'll probably not get to them anytime soon.
While I'm lurking, I think this sounds awesome. Especially the "optimised splatting" and accessible patches which would make it a lot more physics friendly (rather than having the whole terrain as a physics object or splitting up the terrain info as multiple physics objects, as was touched on when the subject was brought up earlier.) The first option being a performance sink and the second being a little obtuse (at least from where I'm sitting.)

Cabalistic - You mentioned that making these changes is on your todo list in the near future, any thoughts of LGPL-ing the ETM? I'm working on a closed source project, but I would be more than happy to make available any work I do on the ETM itself, however with the current liscence (GPL w/runtime exception) I can't modify the ETM for use in my project.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by CABAListic »

Unfortunately, I can't comment on your problem with CEGUI. Almost sounds as if loading the textures via CEGUI disables filtering of the textures? Maybe you could make copies of the textures (for example load them with Ogre::Image, resize them to something smaller and save that in a cache, then load those miniature versions with CEGUI). Anyway, your editor looks nice :)
Cabalistic - You mentioned that making these changes is on your todo list in the near future, any thoughts of LGPL-ing the ETM? I'm working on a closed source project, but I would be more than happy to make available any work I do on the ETM itself, however with the current liscence (GPL w/runtime exception) I can't modify the ETM for use in my project.
Yes, you can. With the runtime exception, the GPL is actually more flexible than LGPL, that's why I switched away from LGPL to it. You are totally free to use ETM however you need it, you can statically link against without revealing your source code. The only requirement I impose on my users is that the moment you make changes to ETM itself, you must give back those changes (i. e. open them, but only them).

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

CABAListic wrote:Unfortunately, I can't comment on your problem with CEGUI. Almost sounds as if loading the textures via CEGUI disables filtering of the textures? Maybe you could make copies of the textures (for example load them with Ogre::Image, resize them to something smaller and save that in a cache, then load those miniature versions with CEGUI). Anyway, your editor looks nice :)
That is what it looks like... I just have no idea how CEGUI is reaching that, since all it gets is the name of the image file, I'm not passing it materials or TextureUnitStates or anything. Though I suppose it might be doing something funky since it interfaces with the Ogre resource manager stuff.

Heh, it was just making my mind boggle since CEGUI (afaik) shouldn't even be aware that Ogre::Material or Ogre::TextureUnitState exist. I'll post the answer when I figure it out in case anyone else is wondering.
CABAListic wrote:Yes, you can. With the runtime exception, the GPL is actually more flexible than LGPL, that's why I switched away from LGPL to it. You are totally free to use ETM however you need it, you can statically link against without revealing your source code. The only requirement I impose on my users is that the moment you make changes to ETM itself, you must give back those changes (i. e. open them, but only them).
Lovely!

----------

Edit: Well, the material itself seems to be unmodified by CEGUI.

/me Goes off to post (more appropriately) on the CEGUI forums.

Image

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

CABAListic's suggestion to clone the texture fixed the problem but here's why (in other words, how CEGUI was able to cause this issue in the first place.)

OgreCEGUIRenderer.h, OgreCEGUIResourceProvider.h and OgreCEGUITexture.h

provide an interface for CEGUI to use and manipulate Ogre resources (which is why you can load a texture into CEGUI via the (string name, string group) method. A CEGUI texture is just a wrapper to an Ogre::TexturePtr.

From OgreCEGUITexture.h:

Code: Select all

Ogre::TexturePtr		d_ogre_texture;		//!< The 'real' texture.
So that explains why CEGUI was able to modify something like filtering. Here's the snippet I added to load the image into an Ogre::Image and create a new texture resource (I also resized it because I did not need the image to be large for the GUI's purposes, the resizing is not necessary to fix the issue.)

Code: Select all

Ogre::Image imgSwatch;
imgSwatch.load((*vecTextureNames)[i], "SplatTextures");
imgSwatch.resize(64, 64);

	// Create a resource from the above image appending "_Swatch" so as not to conflict with the
	// original resource (and so I can delete it when the GUI no longer needs it.)
Ogre::TextureManager::getSingleton().loadImage((*vecTextureNames)[i] + "_Swatch", "GUI", imgSwatch);
			
	// Load the copied texture rather than the original
CEGUI::Texture* texSwatch = m_renderer->createTexture((*vecTextureNames)[i] + "_Swatch", "GUI");
From here you go about creating and adding the CEGUI::Texture to a CEGUI::Imageset as usual (see the rtt stuff in the GUI demo for how to do it if you're wondering.)

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 47

Post by syedhs »

Yeah it looks like texture filtering setting which is done automatically on CEGUI renderer part. I take a time to look into OgreCEGUIRenderer and found this:-

Code: Select all

d_render_sys->_setTextureUnitFiltering(0, FO_LINEAR, FO_LINEAR, FO_POINT);
in the initRenderStates(). Maybe you can try recompile OgreCEGUIRenderer without the line and see the result?

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

Kerion wrote:It's very brute force, so there may be a more elegant way to do some of what I am doing, but this works.
KISS smoothing function:

Code: Select all

ET::Brush Area::averageFilter(int x, int z, ET::Brush shape, float fIntensity)
{
		// When you're doing a loop possibly thousands of times, it's worth setting these
		// aside rather than calling a function every iteration.
	size_t iWidth = shape.getWidth();
	size_t iHeight = shape.getHeight();

		// Faster to presize than resize
	std::vector<float> vecReturnBuffer(iWidth * iHeight);
	std::vector<float> vecHeightBuffer(iWidth * iHeight);
	ET::Brush brushReturn = ET::Brush(vecReturnBuffer, iWidth, iHeight);
	ET::Brush brushHeights = ET::Brush(vecHeightBuffer, iWidth, iHeight);

	m_terrainMgr->getHeights(x, z, brushHeights);

	float fSumHeights = 0.0f;
	size_t iNumHeights = iWidth * iHeight;

		// Find the sum of all the heights within the sample
	for (Ogre::uint i = 0; i < iWidth; i++)
	{
		for(Ogre::uint j = 0; j < iHeight; j++)
		{
			fSumHeights += brushHeights.at(i, j);
		}
	}

		// Find the average height within the sample
	float fAvgHeight = fSumHeights / iNumHeights;

	for (Ogre::uint i = 0; i < iWidth; i++)
	{
		for(Ogre::uint j = 0; j < iHeight; j++)
		{
			float fHeight = brushHeights.at(i, j);
			float fDelta = fHeight - fAvgHeight;
			float fShapeMask = shape.at(i, j);

			fDelta = (fDelta * fShapeMask * fIntensity);

			brushReturn.at(i, j) = fHeight - fDelta;
		}
	}

	return brushReturn;
}
Stupid, fast.

It's simply checking the average height of the sample and applying it, modified by brush intensity and a passed intensity (to allow you to give the user a slider or somesuch to adjust intensity.)

This algorithm behaves similarly to the one in the NWN2 toolset that you mentioned previously and smooths well until brush size reaches around 60ish (debug build), then it struggles. YMMV as far as performance though.

------
Edit: Forgot this bit...

I suggest generating your intensity to pass to the averageFilter similar to the intensity calculations in CABAListic's ETM demo:

Code: Select all

float brushIntensity = (m_fFrameTime / 1000) * 2.0 * (m_lMouseDown? 1 : -1);
brushIntensity *= m_fVarIntensity;

	// translate our cursor position to vertex indexes
Ogre::Vector3 smoothPos = m_cursor->getPosition();
int x = info->posToVertexX(smoothPos.x);
int z = info->posToVertexZ(smoothPos.z);

m_currentArea->smooth(x, z, m_editBrush, brushIntensity);
Where:
- m_fFrameTime is the time it took to render the last frame in milliseconds
- m_fVarIntensity is the value of that slider provided to the user that I mentioned earlier.
- m_lMouseDown is a bool storing whether the left mouse button is pressed
- m_editBrush is the brush currently being used for editing.
- and where m_currentArea->smooth is the following function:

Code: Select all

void Area::smooth(int x, int y, const ET::Brush& brush, float fIntensity)
{
	ET::Brush smooth = averageFilter(x, y, brush, fIntensity);
	m_terrainMgr->setHeights(x, y, smooth);
}
A few notes:
  • - Letting the RMB make the intensity negative results in a cool "Expansion" effect, where stuff that was far from the average height gets farther, as opposed to the positive "compression" effect where stuff that is far from average height gets closer.
    - Okay, so it was only one note... but if I think of something later, I'll add it here!

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

syedhs wrote:Yeah it looks like texture filtering setting which is done automatically on CEGUI renderer part. I take a time to look into OgreCEGUIRenderer and found this:-

Code: Select all

d_render_sys->_setTextureUnitFiltering(0, FO_LINEAR, FO_LINEAR, FO_POINT);
in the initRenderStates(). Maybe you can try recompile OgreCEGUIRenderer without the line and see the result?
Ah, that would probably be it.

The resource cloning solution suits my purposes just fine and I don't really want to be performing anisotropic filtering on all of the overlay images in my GUI anyway (which is why that line exist in the CEGUIRenderer.)

User avatar
Nauk
Gnoll
Posts: 647
Joined: Thu May 11, 2006 9:12 pm
Location: Bavaria
x 25
Contact:

Post by Nauk »

Hi, I am using ETM too and I love it. Recently I have been trying to add an extra pass to the terrain material to apply bump mapping or normal mapping. I never got anything to show up at all. Actually whatever pass I added on top of the splatting passes never showed any great effect at all or very buggy. So how would i go with this?

If anyone got a working example or a pointer into the right direction I really would appreciate it :).

BSer
Halfling
Posts: 93
Joined: Fri Dec 23, 2005 8:46 pm
Location: Niskayuna, NY
Contact:

Post by BSer »

One thing that any self-respecting terrain class should have is a function like:
float getHeightAt( float x, float y )

...similar to the Ogre terrain. Using a ray query is just far too slow by comparison.

I'll try to add this functionality and make it available as I bring ETM into my project, but if a version 3.0 is coming, I think a function of this nature should really make it in.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by CABAListic »

?? What is wrong with TerrainInfo::getHeightAt? ;)

BSer
Halfling
Posts: 93
Joined: Fri Dec 23, 2005 8:46 pm
Location: Niskayuna, NY
Contact:

Post by BSer »

CABAListic wrote:?? What is wrong with TerrainInfo::getHeightAt? ;)
Uhhh I guess the only thing wrong with it is that it apparently isn't obvious enough for tunnel-vision programmers like myself :).

But I guess it will just have to do :). Thanks.

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by CABAListic »

I finally asked for a dedicated ETM forum, and it's open now: ETM forum
Please reroute any questions, problems and suggestions for ETM to the dedicated forum. This thread is just getting too long and chaotic to keep track of things :)

Kerion
Goblin
Posts: 235
Joined: Wed Feb 05, 2003 5:49 am
Contact:

Post by Kerion »

SongOfTheWeave,

Can I ask how you drew your circular cursor on the terrain like that? I've been trying to figure that out, how to make a cursor deform to the terrain like that (NWN2's toolset does this as well), but I couldn't figure it out.

User avatar
SongOfTheWeave
Halfling
Posts: 49
Joined: Sat Dec 22, 2007 3:49 am
x 2

Post by SongOfTheWeave »

Kerion wrote:SongOfTheWeave,

Can I ask how you drew your circular cursor on the terrain like that? I've been trying to figure that out, how to make a cursor deform to the terrain like that (NWN2's toolset does this as well), but I couldn't figure it out.
Using a projected decal.

The nwn2 toolset uses a mesh thinggy that loosely glides over the terrain (mapping to the heightmap values most likely.)

There is a DecalCursor class somewhere back in this thread that someone provided that I took and modified a bit. I looked through a little but this thread is really big and I couldn't locate it.

If you find it, others might appreciate if you would repost it in the new ETM forum category. :)

User avatar
luis
Greenskin
Posts: 121
Joined: Tue Mar 02, 2004 3:33 pm
Location: Spain / Argentina
x 6
Contact:

Post by luis »

I'm beginnig to use ETM and it works perfect! thanks for sharing CABAListic :)

Well, i'm posting here because i had a memory leak (OgreMemoryManager log):

Code: Select all

64 memory leaks found:

Alloc.   Addr       Size       Addr       Size                        BreakOn BreakOn              
Number Reported   Reported    Actual     Actual     Unused    Method  Dealloc Realloc Allocated by 
------ ---------- ---------- ---------- ---------- ---------- -------- ------- ------- --------------------------------------------------- 
013697 0x01496DA0 0x00000034 0x01496D90 0x00000054 0x00000000 new         N       N    ettile.cpp(147) ET::Impl::Tile::createVertexData
013509 0x276934D8 0x00000034 0x276934C8 0x00000054 0x00000000 new         N       N    ettile.cpp(147) ET::Impl::Tile::createVertexData
..........
..........
I added this line in Tile's dtor:

Code: Select all

    Tile::~Tile()
    {
        delete mTerrain; // <---- this one
    }
And problem solved (I didnt protect the 'delete' call since mTerrain is initialized in Tile's ctor to zero).

CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 57
Contact:

Post by CABAListic »

Classical oversight, thanks. :)

Dalon
Gnoblar
Posts: 11
Joined: Fri Jan 11, 2008 11:55 pm

Post by Dalon »

I have 1 question: How do you render that ... ehm ... texture? The ETM Sample application just render the ogrehead "under" the cursor... :?:

Post Reply