Creating a terrain editor

[Kazeon]

Hello guys.

I have been thinking to build a terrain editor program. And this is what I got so far (only worked on it for 2 days, but I'm pretty much stuck at this point):

Hidden

I know it's still nothing. Only a few things can be done at the moment, like rotating camera, zooming, and changing world size. Now I'm still working on camera's angle of attack but I'm kinda stuck here, I don't know what formula should I use for it. I hope somebody can help me with this.

I also have other questions:

1. Is it possible to create terrain editor without using vertices for the terrain like this?

So that you will be free to add details on the terrain (raising, cliffs, etc), at least it's what I predicted. Tho I also predict that it will require much larger storage than World Editor's.

2. What programming language is the best to make these kind of things? Currently, I use VB.net and I think I made a wrong choice.

I will take any advice for this newbie programmer (but just don't advise me to take a look at other terrain editor's source code, I want to build my own from zero). Thank you for any help.

 

[GhostWolf]

What do you mean by "without using vertices like this"?

You didn't really ask any questions, so it's not clear what you're stuck on.

 

[Kazeon]

You didn't really ask any questions, so it's not clear what you're stuck on.

I'm sorry if I was not clear. I'm stuck in making the angle of attack of the camera looks right. It's hard to explain things since english is not my primary language. Heck, it's still hard to explain using my language since I don't understand what exactly I need to ask. I will explain it in pictures, so gimme some minutes.

What do you mean by "without using vertices like this"?

I have googled about some recommendations how to start building a terrain editor, and they said that the easiest way is to create vertices for the terrain. It makes sense tho, I imagine using vertices will be easier to modify the terrain like raising and adding cliffs by adding vertex's z value. I wonder is it possible to do it (modifying terrain) without the use of vertices? If I imagine it correctly, every pixel will be a vertex, so it would need extra storage to save each vertex's Z value.

And thanks. I'm glad someone responded. Sorry about my awful level of newbie-ness.

EDIT:
Okay here is my angle of attack problem. I will use WE for this:
First, I use 270 degrees for angle of attack, and the terrain looks perfectly symmetrical:

Then if I increase the camera of angle, it looks like forming a trapezoidal shape:
(300 degrees)

(330 degrees)

I can't figure it out what formula is used to re-calculate terrain's dimension based on camera's angle of attack?

 

[GhostWolf]

Right.
In order to get a camera working, you need to work with matrices, in order to apply transformations over your vertices.
I don't know if you have any background in this subject (linear algebra), or what kind of API you are using for the graphics, so it's a bit hard to be more precise.
In general, you want a world/camera matrix (moves/rotates the world), and a projection matrix (one that handles perspective divide, such that things that are further away are smaller than things that are closer).

As to vertices - that's what defines the terrain. Remember that you are using a computer, you don't have infinite resolution for your world objects.
At the most, you can increase the density of your vertices, in order to make the terrain smoother (which as you said, obviously increases the amount of memory, and processing on the CPU/GPU, required for it).

 

[Kazeon]

I don't know if you have any background in this subject (linear algebra)

Actually I learned it a bit. So which part of it is related to this matter?

I think I found something that can be useful: http://www.skytopia.com/project/cube/cube.html
Last night I was trying to change my point of view about how to solve this problem: I assume the terrain is the bottom of a cube. So I googled how to change the angle of cube, etc. and that was what I found, I haven't took a good read through it tho. And maybe I will add vertices instead, since now I think 1:1 is too extreme.

 

[GhostWolf]

You can think of your camera as a frustum, here's a good image to illustrate this.
You can read on how to handle frustums and transformations in any DirectX/OpenGL tutorial (I think they are a lot more practical than pure mathematics tutorials).
Here's a tutorial geared for OpenGL, using C++, but you can still understand the idea from it.

About the vertices - what is 1:1? how many pixels do you have? while it would seem the answer is whatever your screen resolution is...what happens if you zoom in or out? you basically need infinite accuracy.
This can be done, just not in the way you are thinking, and you really shouldn't bother with it at beginning.
If it interests you in the future, you can look into generating meshes on the fly using random functions such as perlin noise (aka procedural generation).

 

[Dr Super Good]

WE I believe divides the terrain into patches (every 4*4 tiles?) which it loads on demand.

This approach is very useful since it means that only a small part of the terrain may need to be in the GPU at any time (the area around where you are looking). It also means any changes to terrain will affect only a small part of it (a couple of patches) making it faster to update them.

Each patch would be a vertex buffer with accompanying texture coordinates. Cliff geometry could even be included as part of the patch. Each patch is generated from the w3e terrain with some other files. It fundamentally consists of two layers, one for ground and the other for water, which has the triangles aligned differently. You only need to generate the patches you need and once generated they could be cached for faster use in future.

 

[Rex.]

Is it for War3 or standalone games?

 

[Kazeon]

It's not even for a game, neither for wc3. I'm not good enough for that, way too far.

Wait guys, I'm still trying to understand your suggestions.

 

[Dr Super Good]

Wait guys, I'm still trying to understand your suggestions.

Instead of trying to generate the entire terrain mesh as a single unit, you can break it into smaller and more manageable parts. This not only makes changes to the mesh more light weight, but also can allow for improved shader performance. If you were to fragment the game world into uniformly sized squares such as of the size 4*4, 8*8, 16*16, 32*32 etc (recall that map dimensions are multiplies of 32) then you have a number of smaller meshes to handle to produce the terrain.

The advantage of this comes from only caring about the meshes which are directly visible to the user, meaning that the rest (which for a large map is most of the terrain) do not have to be generated or loaded into the GPU. Changes such as from a brush tool for terraining will only affect a limited number of such chunks which can be very efficiently updated to the GPU (not having to resend all vertices). Best of all shader performance is improved since you can use culling algorithms to remove out of bounds chunks so that they do not get processed by vertex shaders.

 

[GhostWolf]

Instead of trying to generate the entire terrain mesh as a single unit, you can break it into smaller and more manageable parts. This not only makes changes to the mesh more light weight, but also can allow for improved shader performance. If you were to fragment the game world into uniformly sized squares such as of the size 4*4, 8*8, 16*16, 32*32 etc (recall that map dimensions are multiplies of 32) then you have a number of smaller meshes to handle to produce the terrain.

The advantage of this comes from only caring about the meshes which are directly visible to the user, meaning that the rest (which for a large map is most of the terrain) do not have to be generated or loaded into the GPU. Changes such as from a brush tool for terraining will only affect a limited number of such chunks which can be very efficiently updated to the GPU (not having to resend all vertices). Best of all shader performance is improved since you can use culling algorithms to remove out of bounds chunks so that they do not get processed by vertex shaders.

Please don't begin with your silly optimization suggestions.
Not only is it, as usual, irrelevant at the beginning, and based on a game from a decade ago, in this case you are also generally wrong - a small amount of large buffers is generally better than many small buffers (and of course this affects the render calls, state binds, etc.)