Importing real / 2D image heightmap Data into an adt

[Steff]

Because there are many tools that generate grayscale to import and export. Also you can import existing maps into noggit. And i think that i can creat in photoshp the basic modeling much faster then inside of noggit.

[schlumpf]

Well before trying to do this in three dimensions I think it's easier to use a 2d or data oriented approach in place especially as the data is only one dimension

2D + 1D is 3D.

I BET that when doing a heightmap in two dimensions, you _will_ fuck up with the actual heights. It will be streched / not usable at all without a LOT of editing, when doing it in Photoshop.

Yes, there are tools like Terragen. Such terrain wont look good in WoW though anyway. But well, if you two really want to waste time for something like this..

And btw: Where exactly is the hard thing here to implement? Interpolation for the 8x8 grid? Everything else should be pure copying from the image data.

[Guest]

well sweetpea most heightmaps are in greyscale which only gives you 256 colours and still only 65536 if you use alpha too, I'm not sure what the maximum value wow can use is so i'm looking through every adt in every version of wow so i don't have to re-write everything like... oh yeah noggit!

[Steff]

My problem is not noggit but devil Cant write 16bit images. Hope the developer will answer. The rest is almost done.

[schlumpf]

The main problem is that you are converting values from 0 to 2^n with the representation of a color being these

to heights between -afewthousand to afewthousand.

The problem is not only finding a good factor to translate between the ranges but also, that in the end you will have to work with minimal different tones of grey to represent different heights. Do you see any difference between the first 16 entries in the picture above? You're awesome then or your monitor is calibrated really bad.

the human brain can't translate these colors to a height. It just can't. You will always see different tones of grey making shaping any terrain at all fucking hard.

Extending the range to 2^16 colors helps finding better translation factors and lets you define different heights better. But how many different shades of grey can you tell apart? 500? Your're good. Very good. (http://wiki.answers.com/Q/How_many_diff ... an_eye_see)

On the other hand, you wont ever have 0 and 2^n in the same image at any time. You will have colors ranging between 2^m and 2^(m+0.5) for example. especially, when having 2^16 colors possible.

You know why heightmap generation applications work? Because they abstract the data from the image. They will give you a 3d representation, augment the image with a direct color -> height association nearby, mark water height or color the image depending on the height in more than grey.

Predesigning an heightmap in photoshop on a 16 bit grey image?

Ahahahahahahahahahahahahahahhahahahahahahahahaha, no.

[Guest]

Actually I apologise for my last post, noggit is lovely, you are a good coder and I'm just a grumpy old git at times. You do keep banging on about editing in photoshop and that is not what this is intended for of course nobody will be able to use photoshop to completely work on wow maps. but they can use it's tools to cut around terrain features they find interesting, add to layers and save out as a bitmap which offers far improved workflow to noggit.

I want to first be able to dump height data from wow in 2d (because the x and y are static AFAIK) into a bitmap, this is so that I can get just the height data of specific objects like for example the floorplan of elwynn forest, the ravine leading to the swamp of sorrow or the icecrown glacier (these are just random examples, not something I want to do but they illustrate the idea). Now I have actually achieved this Yay me!

What I now need to do is implement addition/subtraction from specific MCNK's based on this data so if the data is just one color then +1.5 say to all verts (again just an example). The reason I want to do this outputting to 2D is because it's faster than 3D manual editing per vertex and there are a wealth of 2D imaging apps for cutting out specific objects from a terrain.

To visualise data I believe it may be prudent to actually output heights relative to a base height of the adt so if the smallest height value is 1.3+5E then that would be the base height and all height will be relative to this, thus rendering your point about the accuity of the human eye impotent. This does have implications to the maximum height achieveable per MCNK but with only 145 verts allowing excessively high modifications of this data would be foolhardy at best. For this part (the part I am working on to work I need to be able to translate wow's scale to real-world scales of objects, setting maximal gradients etc.

Remember I am only performing operations on a single dimension! Once this is done it will be a data class that you can implement to noggit (if you wish) to allow instant creation of landmarks (groups of verticies) like "add mountain here!", "add impression of your face here!" etc. This will allow less skilled terrain modellers to make good edits and more skilled modellers can export terrain textures and 2d heightmaps. (It will be like displacement mapping a 3d object as 3d max et al do).

End post  :uok:

[schlumpf]

I still think that the only good coming from heightmaps is copying. The second use of 2D representations of 3D environments is texturing. For those two: Yes, do it.

On the other hand: We already have texturing in Taliis. Thing there is, that one needs to abstract again from the actual texture to a color (RGBA), which is again not easy, especially as the meaning of one color can be different for two chunks next to each other.

The problem here is that there is no definition of _which_ texture you use in the alpha maps. It might be awesome for copying or if all your chunks have the exact same textures, but as soon as that is not the case, its pretty useless and fugly to work with.

The whole sense I can see in 2D based editing could be implemented way easier and better: Inside the 3D world. Being able to just select chunks and copy or move them gives you the possibility of creating copywork fast, wont give you the possibility of using your face as terrain. Being useless anyway.

Same goes for texturing. Being able to copy and paste chunks or having brushes not only being a circle would improve things (which is what Photoshop gives you in contrast to Noggit). You wont really use anything of the advanced filters in Photoshop. Importing your face as alpha map might be funny once but completely useless on the other hand.

Having a 2D view of the map (as we have in noggit) and giving it the possibility to select a chunk and copy textures would be better. Copying terrain should be done in 3D as terrain is 3D. It just is. And all the talk about "I only have one dimension being easier": No. Its not. You still have three dimensions and its harder to map a number / color / weenie to a height. Which is not hard in 3D.

Quick modeling tools do the job, again. Automatic generation of terrain and textures do the same. But Photoshop doesn't.

And btw: How do you define the base height of a chunk in your image? You don't right. So you need an additional table with base heights per chunk. Being a fourth dimension, if you want. Again, this destroys brains instead of helping.

[Guest]

sorry schlumpf but while some of that was intelligent, other parts were at the very least an oversight!

On dimensions of data:
Vertexes in the MCVT are singular dimensional data because the x and y coordinates are not present in the chunk. (we programmed them as constants relative to wow), in your own documentation it shows that the MCVT chunk is actually four characters, followed by an unsigned 32-bit integer followed by 145 floating point numbers. Thats it!

On use in noggit:
I think we are both not explaining this right. You keep saying about having this in noggit, I'm more than happy to document the class so you can add it to noggit through dll call. I'm going to create a standalone set of classes and procedures for implementing this terrain editing on a stream of data and a filename. It will not expose the data but rather return MCVT and MCNR chunks in an object that noggit can then use.

I'm actually really busy at the moment so It won't be done for a while but please stay patient and when it's done i'll host the dll online or e-mail to you and whoever else is interested.

[schlumpf]

Noggit is cross platform so a dll is not an option.

On dimensions of data:
Yes, the data is stored in one dimension, as data can't be stored in multiple dimensions. I just worked on 4D applications with data stored in 1D. Still, the thing, the data represents is four dimensional, not one dimensional. Everything on a computer has one dimension. This is irrelevant. Completely. You can of course just display 145 floats besides each other. Its useless though, as the data represented is three dimensional. It is always a problem if you don't display data as its thought to be displayed. I nearly destroyed my brain on those four dimensions.

I'm not saying that I want to have this feature in noggit. I want to have features in noggit, enabling you to get the positive things from your feature while not destroying users brains.

[Guest]

absolutely have not had time to look at this sorry guys, just been sooo busy marking papers and coming up with new course content for my teaching. I promise I'll try to do something but just don't hold your breath