Celestia Forums

I?ve painted a bumpmap for Miranda based Robert Johnston?s map.

Here the bumpmap:
https://dl.dropbox.com/u/84094104/Celes ... dabump.png
A slightly improved Version of the texture Map:
https://dl.dropbox.com/u/84094104/Celestia/miranda.jpg

And some screenshots:
https://dl.dropbox.com/u/84094104/Celes ... a-bump.png
https://dl.dropbox.com/u/84094104/Celes ... -bump3.png
https://dl.dropbox.com/u/84094104/Celes ... nda-V2.png

Here my settings for Miranda in solarsys.ssc:

BumpMap "mirandabump.*"
BumpHeight 10
Color [ 0.619 0.552 0.540 ]

I had some problems with 8 and 32 bit, because Celestia ignored the 32 bit bmp Version, so I?m not sure if it?s still in 32 bit; anyway the “steps” are still visible (like in screenshot 2) but not that annoying.

A few months ago I already created a bumpmap of Miranda based on data from Dr. Schenk's 3D House of Satellites:
http://stereomoons.blogspot.de/2009/09/ ... rning.html
But I wasn?t able to get the Map in the right projection to fit with the texture, but I mixed both maps to get the right height of regions.

One last note. As you see in this image:
http://www.practicalspace.com/uranus/im ... anda-4.jpg
Miranda is not a perfect sphere, so would be nice if anyone creates a 3D model.

Let me know if it?s ready to upload at the motherlode

Looks nice, but is unfortunately ficticious to some extent. Have you tried asking Dr. Schenk for yet unpublished elevation data of Miranda and what projection he is using? Reprojecting is no big deal in case it should be necessary. Some time ago I prepared a normalmap from his Iapetus data with the help of my texture tools. You might be interested in the result that I have displayed in my CelestialMatters site:

http://forum.celestialmatters.org/viewt ... 91&start=1
Here is a nice video of the result:
http://www.celestialmatters.org/users/t ... tus_nm.avi

Dr. Schenk is a member of CelestialMatters.
I am not related to the Motherlode and the respective upload of add-ons.

Fridger

I?ve not been asking him yet, but I think I?ll do so soon. His published height data seamed to be in high resolution, so I didn?t thought about it. But the Problem was to find the exact south pole of Miranda to reproject it with gimp, finally this image was not it polar projection. Painting the map was the better opportunity to fit it with the texture and get higher resolution in low-res areas.

Due to the Motherlode... I tried to upload a texture long ago and failed. I?m not sure if this bump map is too fictious or not.
About your Iapetus Textures, since I got a 3D Model of the equator ridge Celestia ignores every kind of height maps But I tired your textures months ago, but they didn?t fit to my Iapetus textures, so I removed them. But nice anyway...
And Normalmapping: My Computer ignores EVERY Tool wich has something to do with Height data

FarGetaNik wrote:And Normalmapping: My Computer ignores EVERY Tool wich has something to do with Height data

I don't understand that last statement of yours. If true then your computer has a problem. If only apparently true, then you probably have a problem associated with the formats of binary numbers that characterize the elevations. Possibly also you might have an issue with the storage mode of binary numbers > 8bit (e.g. 16bit signed/unsigned) with little-/big - endian machines. If you are a MAC user you might have this problem. My tools take account of byteswaps...

But the Problem was to find the exact south pole of Miranda to reproject it with gimp, finally this image was not it polar projection.

I was not thinking of reprojection with GIMP. I mean real reprojection software like in ISIS3 or less professionally but working well: 'mmps'. Celestia wants normalmaps as well as bumpmaps in simple cylindrical projection.

While Celestia accepts bumpmaps it doesn't work with them: all input bumpmaps are internally converted to normalmaps. Of course it's much faster and better quality, if you input a normalmap.

Normalmaps can be made compatible with (non-spherical) 3d models. Moreover there are entirely different approaches that I have also explored some time ago over at CelestialMatters

Video:
http://forum.celestialmatters.org/userp ... opinch.avi

Thread:
http://forum.celestialmatters.org/viewt ... sc&start=0

Fridger

FarGetaNik wrote:About your Iapetus Textures, since I got a 3D Model of the equator ridge Celestia ignores every kind of height maps But I tired your textures months ago, but they didn?t fit to my Iapetus textures, so I removed them. But nice anyway...
And Normalmapping: My Computer ignores EVERY Tool wich has something to do with Height data

The 3D model of the Iapetus' ridge, was made before any Iapetus heights maps were elaborated and released, thus I didn't assign the support for normals to the 3D sphere. Now I suggest you use real Iapetus data; being that ridge available through normalmap; my model does account for the supposed ridge's height, but due to the scale's restrictness of the 3D modelling, it can't be precise to meters (if you are in search for pure scientific attendibility).

The 3D model of the Iapetus' ridge, was made before any Iapetus heights maps were elaborated and released, thus I didn't assign the support for normals to the 3D sphere. Now I suggest you use real Iapetus data; being that ridge available through normalmap; my model does account for the supposed ridge's height, but due to the scale's restrictness of the 3D modelling, it can't be precise to meters (if you are in search for pure scientific attendibility).

Except of non-spherical models Celestia (or the models itself) doesn?t support normalmapping, right? I think 3D models are better than normalmaps, because Celestia shows the shape of the bodys. The height data don?t have to be scientific correct, they only should fit to the textures.

I don't understand that last statement of yours. If true then your computer has a problem. If only apparently true, then you probably have a problem associated with the formats of binary numbers that characterize the elevations. Possibly also you might have an issue with the storage mode of binary numbers > 8bit (e.g. 16bit signed/unsigned) with little-/big - endian machines. If you are a MAC user you might have this problem. My tools take account of byteswaps...

I don?t know much about that stuff... but I?m a Windows 7 32 bit user. I found some tools about normalmapping and that stuff, but only a black (DOS?) window opened and the programs didn?t launch. Maybe I need other software if they only run as a tool of an other imaging software.
And I know that Clestia converts every bumpmap to normalmap, but if the image is not that big, I think this is not necessary to be done before, but if you know a program launching on my pc, I?ll try

I was not thinking of reprojection with GIMP. I mean real reprojection software like in ISIS3 or less professionally but working well: 'mmps'. Celestia wants normalmaps as well as bumpmaps in simple cylindrical projection.

I was thinking about such tools before, but didn?t found them. But I would need the degree grid of the image to convert it correctly, right?

FarGetaNik wrote:Except of non-spherical models Celestia (or the models itself) doesn?t support normalmapping, right? I think 3D models are better than normalmaps, because Celestia shows the shape of the bodys.

Celestia does support the normalmapping natively on whatelse default spheroid.
Celestia does support normalmapping on every 3D model which is got in CMOD (Celestia MODel) format; spheroid or not. Celestia doesn't support normalmapping for 3D model which is got in 3DS (3D Studio) format because 3DS format's limitations.

However, also for CMOD it's possible to specify whether the 3D model can or can't have the normal/tangents options which allows the normalmapping; in the case of Iapetus' ridge such options were unassigned, thus the 3D model cannot show whatelse normalmap.

FarGetaNik wrote:The height data don?t have to be scientific correct, they only should fit to the textures.

This statement is not completely true, because the height data from which the normalmaps are drawn are scientific data as long as the spacecraft does map the object's surface through instruments that samples its elevation.

FarGetaNik wrote:Except of non-spherical models Celestia (or the models itself) doesn?t support normalmapping, right? I think 3D models are better than normalmaps, because Celestia shows the shape of the bodys. The height data don?t have to be scientific correct, they only should fit to the textures.

Incorrect, see Fenerit's reply. Why don't you install this set of asteroids ( Vesta, Eros, Itokawa, Phoebe, Phobos, and Mimas) as a proof that Celestia works fine with normalmaps on non-spherical models. ChrisL did it. The trick here is that he uses lower resolution non-spherical models to start and applies normalmaps derived from high-resolution models. This saves a lot of polygons...

http://www.celestiaproject.net/~claurel/celest ... models.zip

E.g. Itokawa:
[Click on images by all means!]


or Eros

FarGetaNik wrote:I don?t know much about that stuff... but I?m a Windows 7 32 bit user. I found some tools about normalmapping and that stuff, but only a black (DOS?) window opened and the programs didn?t launch. Maybe I need other software if they only run as a tool of an other imaging software.
And I know that Clestia converts every bumpmap to normalmap, but if the image is not that big, I think this is not necessary to be done before, but if you know a program launching on my pc, I?ll try

Right... 16bit...32bit binary numbers in the context of elevation maps are completely unrelated to whether you use a 32bit or 64bit Windows OS. To encode elevations in form of integer numbers (e.g. meter units) saves a lot of storage space! That's why this format is used.

If one restricts oneself to just 8bit numbers, there are obviously only 2**8 = 256 elevations you may assign. Usually this is much too rough for describing elevations of moons or planets. With 16bit numbers you already can use 2**16 = 65536 elevations, which is already MUCH better and thus mostly used.. 32bit numbers are already an overkill, since this would give you 2**32 = 4 294 967 296 elevation values to encode.

It seems you also don't know about using command line programs. If you don't tell windows the PATH where your command line software resides, it will not be found. Instead you'll get all sorts of crazy sounding errors This is all completely independent of height maps.

I was not thinking of reprojection with GIMP. I mean real reprojection software like in ISIS3 or less professionally but working well: 'mmps'. Celestia wants normalmaps as well as bumpmaps in simple cylindrical projection.

I was thinking about such tools before, but didn?t found them. But I would need the degree grid of the image to convert it correctly, right?

You enter all image data along with the the body's radius and the camera vector. Then a reprojected image is generated. You can also simply enter the initial projection along with the desired one.

Fridger

Celestia does support the normalmapping natively on whatelse default spheroid.

Ok. Really? Forget about spherical or not.

http://www.celestiaproject.net/~claurel/celest ... models.zip

I?ve got this addon and I?m confused, because this works. BUT it didn?t work with some other cmod models and normal- or bumpmaps, so whats the problem with iapetus cmod and normalmaps?

Right... 16bit...32bit binary numbers in the context of elevation maps are completely unrelated to whether you use a 32bit or 64bit Windows OS. To encode elevations in form of integer numbers (e.g. meter units) saves a lot of storage space! That's why this format is used.

Ok, you were talking about Mac, and I meant the tools. As far as I know it makes a diffrence if a program is launching if you use 32 or 64 bit windows. I didn?t mean the elevations. BUT back to bumpmaps: there are only 256 different heights at 8 bit in grayscale. I thought 16 bit were the double numbers, the exponetial stuff would relate to colors (normalmaps). Because in my 32 bit version of the grayscale image there were still steps visible. Or what are we talking about

FarGetaNik wrote:
The height data don?t have to be scientific correct, they only should fit to the textures.

This statement is not completely true, because the height data from which the normalmaps are drawn are scientific data as long as the spacecraft does map the object's surface through instruments that samples its elevation.

Aha, my opinion is wrong. Am I that bad in english? The normal- or bumpmaps should fit to the textures, if they don?t every surface-feature is shown twice. The data of spacecrafts are correct, but that?s not the point. But reprojecting them to a map there is always a bit error quote (?). Only compare the maps of some saturnian moons during the time of cassini?s mission. If a new map is released, the same features are not at the exact the same pixel.

FarGetaNik wrote:I?ve got this addon and I?m confused, because this works. BUT it didn?t work with some other cmod models and normal- or bumpmaps, so whats the problem with iapetus cmod and normalmaps?

In order to shown normalmaps, every 3D CMOD model must have assigned geometric normals in seat of 3D modelling output; such geometric normals must be not confused with the normalmap which then will map that surface. They are the undelying "bed" which will allows that normalmap to shows its bumps. In the case of 3D Iapetus that wasn't willingly made because no Iapetus normalmap was then available. However, you can try to add the normal/tangents through the CMODview utility: do import the Iapetus 3D model within it and do choose the menu options: "Operation">"Generate Normals..." and then "Generate Tangents...". Do save the model through "save" and within its SSC do add the Normalmap directive; then do load Celestia and go to Iapetus. Note that somethime the results can be unpredictable; therefore do save several copies of the original 3D Iapetus model and do work on them separately to find the best settings for both "Normal" and Tangents" parameters of the cmodview utility.

FarGetaNik wrote:Aha, my opinion is wrong. Am I that bad in english? The normal- or bumpmaps should fit to the textures, if they don?t every surface-feature is shown twice. The data of spacecrafts are correct, but that?s not the point. But reprojecting them to a map there is always a bit error quote (?). Only compare the maps of some saturnian moons during the time of cassini?s mission. If a new map is released, the same features are not at the exact the same pixel.

In fact I said that was "not completely true"; not that was "completely false".

Absolutely this is not an "harsh contact" from my part; your work on Miranda is stunning and I've quickly adopted it because it does revitalize a forgotten moon. I can't wait for other works like this.

Ok, you were talking about Mac, and I meant the tools.

I just mentioned PPC MACs as an example of machines where the storage mode of multi-byte numbers (e.g. 16bit = 2 byte) differs from familiar x86 PCs: In case of 2byte numbers there are TWO possible inequivalent ways of storing the two bytes of a binary number: a) the low byte first or b) the high byte first.


These two inequivalent ways of representing the SAME 16bit number in the computer are distinguished as little-endianness and big-endianness. Note, endianness is a hardware property!

Well-known processor architectures using little-endianness are the familiar x86 PCs or Intel MACS..

+++++++++++++++++++++++++++++++
Obviously the endianness starts to become relevant if you deal with numbers >= 2byte in your computer, no matter what computer or OS you are using! That gets us back to elevation maps...

As long as you are using only 8bit elevation maps, you can forget about endianness entirely, BUT you will not be pleased by the visible steps in your rendered terrain!
With elevations encoded as 16bit binary numbers you DO need to worry about endianness, but you'll be very happy about the absence of noise or orther artefacts in your rendered surfaces.

+++++++++++++++++++++++++++++++

How about glancing into a 2007 tutorial of mine about normalmaps, my normalmap tools and related issues like multi-byte numbers, endianness etc:

http://www.celestialmatters.org/?q=node/10

As far as I know it makes a diffrence if a program is launching if you use 32 or 64 bit windows. I didn?t mean the elevations.

Sure there is a difference, else we wouldn't be using mostly 64bit operating systems these days
These differences, however, are related to the efficiency of crunching long numbers, since in 64bit systems it takes fewer CPU clock cycles to deal with long numbers.

But there is NO principal difference between using 32bit and 64bit OS. You can get the same physical / mathematical results with either. Yet the results from 64bit systems have a tendency of being accurate to more digits.

BUT back to bumpmaps: there are only 256 different heights at 8 bit in grayscale. I thought 16 bit were the double numbers,

the exponetial stuff would relate to colors (normalmaps). Because in my 32 bit version of the grayscale image there were still steps visible. Or what are we talking about

I am talking about the fact that all these considerations are very general and certainly independent of specific applications like elevations, colors or normalmaps. All this follows immediately when you transform the decimal number basis into the binary basis, where trivially a 8bit number has 8 digits (i.e. bits), each bit being able to take the values 0 or 1 only. A 16 bit number has 16 digits (bits) each being again able to be 0 or 1. Just count how many different decimal number values you may represent this way with a 16bit binary structure.

Fridger

--- edit ---

--- edit ---

Note that somethime the results can be unpredictable;

Yeah... right unpredictable. So... what has this to do with normalmaps? The program is generating crazy bump shadows or tiles. The normalmap itself is still not visable (i think so... or where do the shadows come from? Could be the normalmap). And don?t know if I only didn?t recognized it before or whatever, but Iapetus has a axial tilt of 90° with the model. I unzipped the original model but it?s the same. Finally, forget about the model, I?ll use only the normalmap

forgotten moon

Or forgotten planet. Can?t wait for a Uranus Orbiter to start

To t00fri: Nice tutorial, but the program(s) (4 tools, right?) don?t launch, no matter if I reboot or try to activate it with the control panel. Did I overlooked something or is it my system (I read something about only win XP is supported).

To john Van Vliet: Yes, I?ll take some days to understand everything...

FarGetaNik wrote:To t00fri: Nice tutorial, but the program(s) (4 tools, right?) don?t launch, no matter if I reboot or try to activate it with the control panel. Did I overlooked something or is it my system (I read something about only win XP is supported).

Oh sorry, I forgot.

The C++ runtime *.dll modules required are from an older MS VS compiler and would be missing on a Windows 7 installation. Most somewhat experienced users on Windows 7 would simply recompile the tools which takes a few seconds (given some basic know-how about Windows compiling). This failure of my binary tools on Win 7 is an illustration of the major disadvantage of binary distributions...

So I trivially updated my tools to version 2.0pre2 here on CelestialMatters
http://forum.celestialmatters.org/viewt ... =1005#1005

These archives should now work fine on Windows 7 (32bit and 64bit).

Note: The normalmap tools are in the nmtools-2.0pre2.zip archive and the surface texture tools are in the F-TexTools-2.0pre2.zip archive. While the nmtools require signed 16bit elevation maps as input, all F-TexTools work with 8bit/color. Endianness is irrelevant for all F-TexTools. For the latter, the input may also be as *.PNG images.

The tools support CUDA GPU computing which can enhance the speed of the tool execution easily by a factor of 10 or more for CUDA-enabled NVIDIA graphics cards. Also, the tools optionally output VT tiles in highest-quality DXT compressed format (*.dds, *.dxt5nm), which greatly enhances the rendering performance of "monster VT sets" without sacrificing quality. Celestia of course supports these formats.

Please use the installer *.exe (nmtools-2.0pre2.exe and F-TexTools-2.0pre2.exe) in the respective Win32_PC.bin\ subdirectories for a correct installation. Reboot thereafter.

Please let me know whether installation and execution worked OK. In my NM tutorial, I referred to a "dwarf" dataset for practising (5400x2700 px).

http://www.celestialmatters.org/users/t ... esttex.zip

This is highly recommended for command-line Newbies!!!

Fridger

t00fri wrote:This failure of my binary tools on Win 7 is an illustration of the major disadvantage of binary distributions...

Mostly, it is a M$ failure in supporting its OSes; meanwhile adding lots of futile weight files...

--- edit ---

--- edit ---

About F-TexTools and NmTools: sorry, but with a normal installation nothing works. Only one tool of F-TexTools opens an empty cmd window (the other tools too, but they?re disappearing bofore they?re started completely). If necessary, someone else should create a normalmap...

I think now I know enough about projections. No wonder I didn?t got the bump map of Dr Schenk in the right projection, It?s in azimuthal projection. Are the reprojection software able to reproject this? They both seam not to run on windows -.-
Finally, my cylindrical projection should fit for Miranda. But, is this painted texture OK or not? Gimp isn?t able to convert it to 16 bit; I asked someone else to convert it with photoshop, but this program obviously works only with 8 bit, the steps were visible in the 16 bit version.

To make sure my modify-ssc works not only with my Celestia, please check it:
https://dl.dropbox.com/u/84094104/Celestia/Miranda_Bump_Map.zip
I modified the bump map a bit since my last upload. A readme is included, tell me if this is OK.

FarGetaNik wrote:About F-TexTools and NmTools: sorry, but with a normal installation nothing works. Only one tool of F-TexTools opens an empty cmd window (the other tools too, but they?re disappearing bofore they?re started completely). If necessary, someone else should create a normalmap...

What you interpreted as a failure was actually a sign of success!

From your description, I infer that you tried to open the tools by just clicking on them. For command-line tools the start is different, however! I thought you know this, after all this is part of of your own OS, i.e. Windows 7.

You first open a 'cmd' shell by clicking Start ->Run...

Then type into the opened Run window: cmd <return>
This causes a cmd shell windows to open. Now you can check whether the NM-tools were correctly installed, i.e. whether windows knows their location:
You type into the cmd shell at the prompt

> nms
This is the name of a normalmap tool from the nmtools archive. Since you entered the name without arguments, a help text should be printed out. Next you can change to the directory where you have some input files. Then you follow my tutorial.

You also will note that the windows close by no means if you do things right.
If you click instead on the tool icon, the associated cmd app is started first and then quickly a help text printed as described above. In the click-start mode, however, the shell window closes right away if no tasks remain to be done. That's like this in Windows, Linux and MAC OS...

Fridger