Editing Terrain in Irrlicht.

[Mireneye]

I hope that explains my problem correctly. Let me get what i have stright. Im loading a Hightmap from a Bmp file, and i was bothered by some things beeing wrong, and also i was bothered beacuse whenever i need to change something I would need to redo it on the hightmap load it up etc.

So, here i was thinking of editors like Morrowinds TESCS and similar which can edit terrain by raising or lowering terrain with a certain falloff in the actual editor, and i was thinking on how to archive that in Irrlicht.

A few things came to mind. Each mesh is buidlt up from Vertices/polygons etc. First i need my hightmap to beacome a solid mesh, right. So, my intent is to first get it exported to a meshfile. Or even loading it as a meshfile at first "By creating the landscape in a external app". Keep in mind that it is in fact a rather big terrain im talking about, more or less, a seamless world.

So, editing the terrain would require a format which you can actively write to. And access and output vertex position data and move the vertices and then save it back to the *final file* loaded by the game itself. The thing is, I dont have the slightest idea on how to even begin my approach.

Thanks for any help.

[Guest]

you dont have to think so complicated. if you load the heightmap into irrlicht, its converted to a mesh, so you _theoretically_ could manipulate this (vertex data blablabla) but i dont know if such irrlicht functions do exist (would be great since i actually want to make something like a scene editor too for my rts-maps)

[Guest]

I have a tendency to think complicated as long as i dont know the terms. I think you probably need to write a new header file with some mathematical functions for it. Then call those upon the mesh you got from the hightmap, whenever and wherever you want to. You'd need a pointer with kind of a radius to make things more interesting aswell. Tell me if you find anything solid.

[Guest]

but as far as i know you cannot directly "touch" the mesh of the terrain, or did i miss something? :shocked:

[Thulsa Doom]

Hello,

I think there's a way.
May be some code may help.
In my App, I load a terrain like this:

Code: Select all

video::IImage* 
		img = drvr->createImageFromFile("Resource/greyscale_64_64.bmp");

scene::IAnimatedMesh* 
	amesh = smgr->addTerrainMesh (	"greyscale_64_64.msh",	
											img,  
											img,  
											core::dimension2d< f32 >(1.0f, 1.0f),			 
											255.0f,											  
											core::dimension2d< s32 >(16, 16)				
										); 

Later on I have a function to access the vertices:

Code: Select all

// The following code is placed in a loop with index is mshcnt.
	irr::scene::IMeshBuffer* 
		pMeshBuffer = amesh->getMesh[0]->getMeshBuffer(mshcnt); 

		uint vtxcnt = pMeshBuffer->getVertexCount();

		irr::video::S3DVertex* 
			currentVertex = (irr::video::S3DVertex*) pMeshBuffer->getVertices();

		for (uint vtx = 0; vtx < vtxcnt; vtx++)
		{
			currentVertex[vtx].Pos.X;
			currentVertex[vtx].Pos.Y;
			currentVertex[vtx].Pos.Z;
		}

At last I create the scene node:

Code: Select all

scene::ISceneNode* 
	node = smgr->addMeshSceneNode(	amesh->getMesh(0), 
										smgr->getRootSceneNode(), 
										0 );

I believe the only problem is to correctly adress the desired vertices.
Maybe one of u guys can mod that code for our purpose?

GreetZ

T.D.

[Guest]

GFXstyLER ???

[Spintz]

You could also use the getMesh() function for the CTerrainSceneNode class to get the Mesh data for the terrain. You can modify that mesh buffer any way you'd like, and it should effect the terrain. Never done this, but it should work. If there's any problems, let me know.

[Mireneye]

Guess I have to read up on my coding alot more then. Personally i have insufficient knowlage of Irrlicht to code it "I just started actually" and so far, the tutorials have gone... so - so... Ive had classes in programming before, altho in ASP and Java, so I guess its far from enough to really get a good grip however, if i get a better grip on how object-handling is performed and read up on the documentation and continue with the tutorials, I think i might have a chance to improve, rather ill definietly will.

Well, ill check up on the command you purposed, ill see what I can find out.
Thanks.

[Mireneye]

I was wondering. To adress vertices, woul'nt it be easiest to get the point where the pointer is, locate the vertices closest to it and by dragging the pointer up or down the vertices inherties a set value on the up/down axiz "Positive its the Z Axis" which tones off "gets gradually smaller" from the middle and out, with a radius.

To elaborate some from the last I understood by getting the vertex data from the huge terrain mesh you should be able to compare values of the ones of the pointer and the values of the vertices close to it to see which vertices to move.

To sum up Vertices in Radius close to pointer will move up or down, depending on how far away the pointer is, and knowing that they are selected by beeing enough close.

Cheers

[Thulsa Doom]

Spintz,
your definitely correct, useing
ITerrainSceneNode* smgr->addTerrainSceneNode()
make things much easier. I sould also read the Api closer.

I believe that the mesh has to be parsed in any case to search for vertices that are inside a region of interest. The only question is to find an effective algorithm to perform it. Atm I don't know how the memory buffer containing the vertices is organized. (Does anybody have some more details ) So the backfall is always a brute force approach. The easiest way is defining a rectangle and test in a loop if a particular vertex is in the roi.

Mireneye,
what you suggest might work, but I personally think it would be more flexible to have a lookup table for that rect to lower or raise the vertices corresponding to the lut, like the height map of the terrain itself.

[Guest]

Parsing it sounds like a good approach, otherwise loading the whole terrain just to find a few vertices would be overkill. Your idea sounds alot more possible and faster as a solution.

Dont know how the memoy buffer for the vertices work myself thou.Anybody who could fill us in on this would be great.

[Thulsa Doom]

Hi,

I experienced some problems last days.
Wrote a function to transform a mesh in another memory organization.
The problem is,

ITerrainSceneNode->getMesh()->getMeshBuffer(0)->getIndexCount() returns 0,

while

ITerrainSceneNode->getMesh()->getMeshBuffer(0)->getVertexCount() returns amount of points.

So I used

Code: Select all

SMeshBufferLightMap mb;
ITerrainSceneNode->getMeshBufferForLOD(mb, 0);

The returned Meshbuffer mb provides points and indices, but the memory organization differs from the method used in my earlier post.

Has anyone an explanation for this observation?

[Mireneye]

Im guessing here, that in first example you recieve
'raw' data which is going to translate and in the latter you recieve data which already has been translated. Hence I think the latter is more accurate to work with.

[Thulsa Doom]

ThanX Mireneye 4 reply,
also I have no idea what the difference between raw and non raw vertex data is, I might have found a way to walk around it.

@All:
Does somebody know source code of c++ 3d triangulation algorithm?

[Mireneye2]

Im positive you can find it somewhere here:

http://www.mathtools.net/C_C__/Computational_geometry/

http://gts.sourceforge.net/

http://directory.google.com/Top/Science ... /Software/

http://www.qhull.org/

http://www.geom.uiuc.edu/software/cglist/ch.html

*Put in the order I think is most logical, my best guesses first =)*
I hope that helps you in your further programming. What i meant with 'raw' is before it passes through a certain 'command' and after it passes. If you get what i mean ?

Best of luck, I still hav'nt got anything practical to show.