Celestia Forums

John is doing his best to improve the quality of the Addons provided on the Motherlode. He gets quite frustrated when people continue to make the same mistakes, even when they've been pointed out repeatedly.

Years ago, when Celestia and the Motherlode were young, the ML was just a file storage for people who were starting to learn how to do Addons. There were very few Addons and very few people knew how to make them correctly. As a result, many of those old Addons were very poorly made.

Celestia is no longer young. People who download Addons from the Motherlode expect them to be done right. There are many tutorials explaining what the components of an Addon are and how they should be made. Many of the components of an Addon are not unique to Celestia. Bumpmaps, normalmaps, surface maps, map projections, alpha channels, file name requirements, and model construction are a only a few examples of the things people need to know to construct 3D graphics used in many different situations.

Understanding the different types of "maps" is very important when designing a 3D object, whether for Celestia or otherwise. A bumpmap or a normalmap, for example, is used by Celestia and other display packages to generate a shaded relief map. Providing a shaded relief map and calling it a bumpmap is not appropriate. Recognizing the difference between a map with a simple cylindrical projection (which Celestia uses) and one with a Mercator projection (which Celestia does not use) is important, too.

If you use the wrong kind of image as a bumpmap, it might "look good", but it wouldn't look correct. John is a stickler for things being correct.

Personally I'd document the type of image that you're using and why and ask for help creating one that's correct. (Sorry, I can't provide that help: I have too many other on-going projects that I'm much too far behind in.)

Similarly for the orbital reference specification.

pla879 wrote:Thanks,

I will and I have a question and need clarification. From what I am understanding, Bumpmaps made in GIMP are not usable and I think I know why. Is it because they give a false illusion of height by giving the image a slight embossing effect?

I don't use gimp so I can't answer that.

So what I need to do is make a height map and use it as a Bumpmap?

Well, perhaps "translate a height map into a bump map" would be a more accurate description of what you need to do. Height maps are arrays of height values. They can specify the height of a location either using floating point numbers or using integers with 8 bits, 16 bits or more. Celestia's bumpmap images must have (are limited to) integers with 8 bits per pixel. Celestia's normalmap images use the equivalent of 16bits per pixel, so they can represent much greater height differences than bumpmaps can.

Am i on the right track of understanding?

Close!

Is a height map made from a displacement map?

It can be, although usually it's the other way around: height maps usually are the basis for generating bumpmaps, normalmaps and/or displacement maps. Displacement maps are used by 3D display programs to actually distort (displace) the surface of a model. Shadows and highlights are then a natural consequence of light cast on an irregular surface. In contrast, 3D display programs use bumpmaps and normalmaps to create the illusion of bumps by drawing shadows on a smooth surface. Using a displacement map requires significantly more computational power than using a bumpmap or normalmap.

Are there any programs out there that would generate a height map from a normal map?

Yes, although I haven't investigated them for several years.

I'll leave it to someone else to respond to the rest of your post.

If so, is the program one that someone with a very limited understanding would be able to use effectively? My skill level with Photoshop is mainly by using the clone tool. I don't want to shell out $$ on something that I couldn't use. Are there any users out there that wouldn't mind giving it a shot making the bumps? If so, I would give credit where credit is due and appreciate iimmenselyly. Also, if someone does take up the task would they show me how they made them? I have an idea for another add-on (alternate Trek universe) started working on the models and want to soon devote my full attention to working on it.

Thanks,

Pla879

I think one contributing factor is that a lot of the tutorials are simply too confusing, including the ones regarding bump maps and height maps. I'd say about 90%, 95% of the tutorials out there went way over my head by oodles and oodles of giga-light-years. Heck, I spent a whole four days (all of which I had all to myself), trying to grasp the VT tutorials a few months ago.

--- edit ---

--- edit ---

John, one thing is still unclear for me: why the Google normalmap GIMP'S plugin wouldn't make a correct normalmap which maps to a sphere? Below there is a naive planetary 256 grayscale image got from my 3D modeler as unwrapping upon 0.5k texture of a 3D shader applied on a sphere. Aside the fact that in the same way should possible to get the normalmap too (and more big sizes), and therefore should be calculated also its fictional "heightfield", nonetheless such map once were being processed by the nm GIMP plugin, it would be "normalmapped" like it is, without any variation of its projection; that is, it would mapping to a sphere. Or not?


blacks aren't shadows, just the effects of noises/generators/gradients, etc.

P.S.
My 3D modeler is now dead (trueSpace) but here seems there are people with 3DS MAX and such, which would do the job best yet; Blender too, if I've understood by the way.

--- edit ---

--- edit ---

--- edit ---

pla879 wrote:I am really trying to understand all of this and appreciate the comments that are made trying to clarify my questions but I will be straight up and say that the posts tonight are way over my head and I feel even my questions are totally beneath the level of expertise you gentlemen have. Just the mention of 8 bit, 16 bit is starting to go over my head. It's weird, I can hack my OS all to kingdom come and back but I get lost over what is probably considered basic image manipulation. If anyone would like to work on my bumpmaps let me know. I would give full credit and probably learn how to do them. Right now I am in a holding pattern until my add-on is approved. I have annother I want to work on. To put in bluntly, this sucks.


Thanks,


Pla879

I think, when it comes to images, the difference between 8 bit and 16 bit is how many colors an image can have. Remember the "olden" days of computer imaging, where you could only use 256 colors for one image (such as a .gif), and later the ranges of colors expanded? It's just like that. 16 bit probably has more colors than 8 bit, but I will admit that I'm no expert in computer imaging. Maybe someone more experienced could either confirm or refute?

--- edit ---

BTW, with the gray map above I do not see valuable differences in the direction of lights (aside the 8 vs.16 bit details); at least for fictional objects, to which the real displacements are as real as unreal the map is. Anyhow, there isn't mention on the site about such plugin's limitation, how it would be, because for euclidean curved surfaces being a normal always orthogonal to its surface point tangent, whatelse non-platonic UV-mapped solid shouldn't be correctly normalmapped and that must be specified among the plugin's claims.

--- edit ---

--- edit ---

Hi pla879, you should take a look at Wilbur. This software works like John is saying.


The heightfield generation. You will not see nothing before to do that operation. There are lots of way to generate height data. The maps can map to a sphere and are seamlessly.


Its normalmap equivalent. The program doesn't make a shaded map before and then its bump/normal; but like John say, it do the converse. The tools on the left are for painting your custom height data, not colors. The program internally will convet it into its shading settings (optional)


A shaded relief of such heightfield. Useful to see where to paint in GIMP (layers). Of course you cannot paint the ocean where there is a mountain, otherwise you will get a bulb into the planet's ocean when the normalmap is specified within SSC.

Fenerit wrote:

p_2.jpg

Its normalmap equivalent. The program doesn't make a shaded map before and then its bump/normal; but like John say, it do the converse. The tools on the left are for painting your custom height data, not colors. The program internally will convet it into its shading settings (optional)

Do these normals wrap to a sphere the same way Vliet wants?

BTW, in the image below the shaded relief has been fully blended with the heightfield, so one can see how the planet will look on the whole (texture + normalmap). There are also the option for land and sea color altitudes. These parameter are borrowed from the height data but each color can be custumized by user. This can help with the texture color making, before final hand retouches. Maybe the hetero-terrain generator is not suited for class M planet while is more suited for barren moons, but one can play with its settings. For class M planets seem more suited the fractional brownian motion. There are erosion, noise, math formulas and more as filters to deform the map even locally.