Using ETM with wxWidgets

Progger

28-12-2008 22:06:51

Hi,
I'm using ETM with the GUI library wxWidgets but I have some problems to link these both libraries together.

I'm using almost the same code like in the demo.
The are two issues however:

1. The LOD construct works strange since the terrain is build of only few triangles. The camera should be moved very close to the terrain so that I can realize simple details (i.e. it works not in the same way like in the demo)
2. Deforming of the terrain works pretty slowly. I don't even see how it is deformed until I release the button that should deform the terrain.

Here a little bit of code:
void MyWindow::OnMouseMotion(wxMouseEvent& wxEvent)
{
// determine the relative position of the mouse cursor
wxPoint vNewMousePos = wxEvent.GetPosition();
Ogre::Vector2 vMouseRelPos;
vMouseRelPos.x = static_cast<Ogre::Real>(vNewMousePos.x - m_vOldMousePos.x);
vMouseRelPos.y = static_cast<Ogre::Real>(vNewMousePos.y - m_vOldMousePos.y);
m_vOldMousePos = vNewMousePos;

// deform the terrain with the pressed left mouse button
if(wxEvent.m_leftDown && wxEvent.Dragging())
{
float fBrushIntensity = vMouseRelPos.y * 0.001f;
Ogre::Vector3 vDeformPos = m_pTerrainCursor->getPosition();
m_pTerrainMgr->deform(m_pTerrainInfo->posToVertexX(vDeformPos.x),
m_pTerrainInfo->posToVertexZ(vDeformPos.z),
m_EditBrush,
fBrushIntensity);
}
}

This method is called after the mouse was moved and should deform the terrain. Not like in the demo with the both buttons but with relative mouse position. This works like mentioned above very slowly however :(

I hope you have already worked with wxWidgets and ETM successfully and can give me some tips ;)

cu

Progger

04-01-2009 18:03:07

Hi, does nobody have an idea how to solve this?
Are there any special functions that control the LOD construct apart from TerrainManager::setUseLODMorphing ?

CABAListic

04-01-2009 18:35:06

Yes, there is setLODErrorMargin, in particular you need to use that function to set the pixel height of your Ogre window (and possibly update it if the size of the window changes).

Using ETM inside wxWidgets doesn't differ from using it anywhere else. If deformations are not visible until after you stop doing it, then obviously you are not updating the terrain, or you are not calling Ogre's renderOneFrame function during the updates.

Progger

05-01-2009 19:17:39

Hi, thanks for reply!
Of course, using ETM is not actually a problem where you use it. I was only asking for some tips how to accomplish this ;)
But I could finally solve these problems :D

For those who plan to work with wxWidgets:
1. setLODErrorMargin was indeed the right function. In my application this function is called when the terrain manager was created and then every time the window was resized. But here the issue: The terrain manager is created once the window that contain the drawing stuff has been created. This window is actually a child of a top level window and since it is not clear what size it would get an arbitrary viewport height (in my case 20) is set to the setLODErrorMargin function.
Yet, the callback function - that is called when the window was resized - is involved after the window gets its right size inside the top level window and it involves setLODErrorMargin respectively. Although the terrain manager gets now the correct vieport height (in my case 627) the terrain is being drawn so like with the former obtained viewport height (i.e. 20).
I could solve this by creating the terrain manager after all windows have been created and correctly positioned and resized.

2. I could solve this issue by creating a timer. So it works like the "frameStarted" construct. The terrain is now deformed at right time ;)

cu