Hi,
I'm trying to modify my ISceneTerrainNode on the fly and it's not working. Can someone explain to why it isn't working? My code is attempt to just modify the height and turn it white but it's showing up black and flat. Thanks. Is there still that limit on terrain sizes of 129x129?
It doesn't work because you are getting a copy of the mesh data. Modifying a copy of something does not affect the original. If you want to modify the original, you should probably use the getMesh() method.
Where is the tutorial for this ???
the tutorial 12. terrain rendering does not go into any detail what or how anything is to be loaded. The above code by pwierz documented is the only hint of whats going.
Or am I going in the wrong direction and should be looking for scene editing tutorials ???
Grumpy wrote:Where is the tutorial for this ???
the tutorial 12. terrain rendering does not go into any detail what or how anything is to be loaded. The above code by pwierz documented is the only hint of whats going.
Or am I going in the wrong direction and should be looking for scene editing tutorials ???
Tim
There really isn't a tutorial for what I am trying to do beyond tut 12. I just sort of put it together by playing with the system. In the meantime, does anyone out there have any info on why the colors of the vertices aren't changing?
right here is some code that generates a texture based upon height in irrlicht, you would just regenerate the texture every time the height has been modified (works out not that expensive as in-game editing would be less likely to occur and over a much reduced time-span)
ITexture *generateTerrainTexture(IVideoDriver *driver, ITerrainSceneNode *terrain)
{
// Create the texture we'll use on the terrain
// NOTE: The texture is 128 by 128 while the terrain is 129 by 129. There are a couple of reasons
// for this. First it's better for texture sizes to be a power of 2. Second this size lets us work
// with the texture and terrain together as if each pair of triangles on the terrain is one pixel on
// the texture. It also gives us a bit of room when calculating slopes.
ITexture *texture = driver->addTexture(dimension2d<s32>(128,128), "texture", ECF_A8R8G8B8);
// Check if the colour format is what we expect. IVideoDriver::addTexture() does not have to
// use the colour format you specify so it must be checked. Obviously it would be better to
// generate a texture for all the colour formats but for this example I wanted to keep the whole
// process simple.
if (texture->getColorFormat() != ECF_A8R8G8B8)
return NULL;
// Lock the texture we created earlier so we can work on the data
u32 *texData = static_cast<u32 *>(texture->lock());
// Base color of black
u32 color = 0xff000000;
// For each point on the texture
for (int x = 0; x < 128; x++)
{
for (int y = 0; y < 128; y++)
{
// NOTE: X and Y for the texture are X and Z respectively for the terrain. I've tried to
// keep my variable naming consistant based on whether the variable is referring more to the
// terrain scene node or the texture. But most things refer to both so Y and Z are used
// somewhat interchangably.
// Grab the scale of the terrain
f32 xScale = terrain->getScale().X;
f32 yScale = terrain->getScale().Y;
f32 zScale = terrain->getScale().Z;
// Calculate the slopes in the x and y directions
// Another option would be to find the normal vector for the area being worked on
// and using the y component as the slope. This would also let you skip the next step
// as the y component of the normal would always be positive.
f32 xSlope = terrain->getHeight(x*xScale, y*zScale) - terrain->getHeight(x*xScale + 1.0f, y*zScale);
f32 ySlope = terrain->getHeight(x*xScale, y*zScale) - terrain->getHeight(x*xScale, y*zScale + 1.0f);
// Calculate the absolute values of the slopes
xSlope = abs_<f32>(xSlope);
ySlope = abs_<f32>(ySlope);
// Calculate the red color based on slope
// Steeper = more red
s16 red = static_cast<s16>((xSlope > ySlope ? xSlope : ySlope) * 128);
// Calculate the green value based on height
// Lower = more green
s16 green = 255 - static_cast<u8>(terrain->getHeight(x*xScale, y*zScale) / yScale);
// Just set the blue
s16 blue = 0x00;
// NOTE: You can change the way the colours are calculated to adjust the results
// but you should make sure to leave in the clamping I have applied so the colour
// compilation below will work.
clampColours(red, green, blue);
// Build the colour and set it in the correct place
texData[x+128*y] = color + (red << 16) + (green << 8) + blue;
}
}
// Unlock the texture so it can be used
texture->unlock();
// Return our pointer to the newely created texture.
return texture;
}
this may need to be slightly modified but it works and works from the heightmap the terrain is generated from so could easily be modified to work with verticies
Remember all information is contextual and if I do not understand the context I cannot gras the information
am I wrong again hybrid, maths seems to say I am lol, but what about outputting the generated textures and checking for their existence first eh this would then allow for dynamic texture creation with a cache to speed things up.
Can you set sub-mesh textures (as in set texture on a collection of verticies) because if so you could make this algorithm take the count of verticies, the partial mesh and generate terrain only for different parts, like chunks.
Alternatively you could work with much smaller textures and chunks say 32x32 heightmap data needing a 128x128 texture (much smaller than 1024x1024) and works out more efficient to re-texture.
just some random thoughts on the subject
Remember all information is contextual and if I do not understand the context I cannot gras the information
this would then allow for dynamic texture creation with a cache to speed things up.