Modcraft - The community dedicated to quality WoW modding!
Community => Random => Topic started by: Guest on April 12, 2011, 02:50:42 pm
-
Hi, I was looking at some topography images of planets taken by nasa and available for download (free) and it got me to thinking, how hard would it be to gather that data and import it into an adt file.
This is in suggestions because I think there needs to be a tool for this as it would allow much more realistic terrain creation for wow ;)
end minddump--
-
I work in the moment on a grayscale import/export function for noggit.
With this it will be possible.
-
isn't this already working with taliis?
-
Not realy :) Tigu started as i know but it never was working implemented. Also i export a real graysacel 16bit heighmap with a resolution af 272 pixels. If it is done ;)
-
Taliis heighmap is totally fucked up... not working at all XD
-
this is all gravy (good) except that, It does not need to be a part of any toolset IMHO. What about command-line batch processing, then noggit etc could integrate it via a simple gui and the apps development would remin seperate.
One of the things I have noticed that worries me a little is that everyone wants Noggit, Yias, Taliis etc to be an all in one toolset like blizzard probably uses but it does not have to be so nd would probably benefit from a more compartmentalised approach. Using win32 API it is entirely possible to capture a form by name and put it inside a picturebox instead of using the start-menu. I know it's just a lot of I want... but I think I may even be able to amble together this myself with an empty adt and just have the app edit the height data.
Also wow 272pixels is miniscule, the data set I'm looking at is like 5000x4000 pixels lol, so probably a bit more than wow can handle, anyway, I'll see if I can code up a little demo app (although it may be for 2.x.x initially)
-
this is all gravy (good) except that, It does not need to be a part of any toolset IMHO. What about command-line batch processing, then noggit etc could integrate it via a simple gui and the apps development would remin seperate.
One of the things I have noticed that worries me a little is that everyone wants Noggit, Yias, Taliis etc to be an all in one toolset like blizzard probably uses but it does not have to be so nd would probably benefit from a more compartmentalised approach. Using win32 API it is entirely possible to capture a form by name and put it inside a picturebox instead of using the start-menu. I know it's just a lot of I want... but I think I may even be able to amble together this myself with an empty adt and just have the app edit the height data.
Also wow 272pixels is miniscule, the data set I'm looking at is like 5000x4000 pixels lol, so probably a bit more than wow can handle, anyway, I'll see if I can code up a little demo app (although it may be for 2.x.x initially)
Way more than wow can handle, i recall alpha layers are 1024x1024, so i suppose that REAL heighmaps are of the same size, which is reasonable.
-
A height map is 9x9 interleaved with 8x8 per MCNK.
Take that times 16 and times 64 so you get the maximum resolution per continent.
-
so... (9x9) * (8x8) * 16 is per adt, I think I have now been sufficiently confused, the pp will only work on one adt at a time because traditional 2d imaging apps can sort out cutting a heightmap into tiles. also maybe i'm doing something wrong but is any part of the adt's height data relative to a global height?, maybe I came out of alignment :S
-
No 9*9 + 8*8 * 16 chunks = 1 ADT = 272 pixels. This will get filled with fake pixel that get not used during import and get generated during export.
That is my plan :)
http://www.madx.dk/wowdev/wiki/index.php?title=ADT/v18 (http://www.madx.dk/wowdev/wiki/index.php?title=ADT/v18" onclick="window.open(this.href);return false;)
The MCVT sub-chunk subsection.
-
thank you very much lol. is this correct for wow version 1.1.2 (only version I have portable on my laptop lol)
-
right I have the app built to read the mcvt data but need to know how to write to the data from a bitmap or just as helpful would be how to write the data to a bitmap as a heightfield, I was thinking of reading the data but as uint32 and using C#'s Color object to represent the data correctly but this presents alpha issues so how about ignoring that idea and rounding the float to an int32, I'm just not sure if I'm going to be doing it in the right order
-
I am short befor finishing this inside of noggit. So why do you not spend the time working on M2 or WMO tools?
-
This is the most worthless thing anyone could do. Why do people work on this? Its counter-intuitive, bad to use and just useless as you can do quick mockups of terrain faster in 3D than in a 2D image using colors, twisting your head to add the third dimension in your brain. Its just useless.
-
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
-
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.
-
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.
-
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!
-
My problem is not noggit but devil :) Cant write 16bit images. Hope the developer will answer. The rest is almost done.
-
The main problem is that you are converting values from 0 to 2^n with the representation of a color being these
(http://www.sketchpad.net/images/graypal-01-01.gif)
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 (http://wiki.answers.com/Q/How_many_different_shades_of_grey_can_the_human_eye_see" onclick="window.open(this.href);return false;))
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.
-
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:
-
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.
-
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.
-
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.
-
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