Celestia Forums

Hi All,

I decided to put model building on hold for a while due to the problems I've been experiencing. I'm not sure what is a bug in the code or what is a problem with the way the model or texture is created. I decided that it would be better to wait till all the enhancements are made for the next release and everything shifts to debugging.

Anyhow, I was thinking of spending my time to really get to know the C language and write some custom model building code. I've had it with trying to figure out what Blender is doing and how to export the files created. Then I would have more control.

One thing I would like to do is create a super high resolution model of the earth and mabey mars. The data I was thinking of using is SRTM3 90 meter files which I downloaded a while back while making a specmap. They are divided into 1201x1201 size files and I would create a model for each file. Don't know where I would get the textures though.

The reason I am writing this here is to get some feedback and see if it would possible for Celestia to support such a model where it would not get loaded into memory till a certain altitude was reached so only a few models ( and textures ) would be loaded at a time, depending on which files were in view. As soon as the view changed, new models would be loaded and the old ones discarded. Mabey this could be a plugin where Celestia would have the ability to call the programs that actually make this thing work.

Just thought I'd ask. Not sure if this were ever proposed before. It would also be safe to say that this is thinking way ahead.

cartrite

I don't know if Celestia ever will support dynamic loading of models, but, of course, you can use any resolution texture you can get your hands on

If you're creating a CMOD model from scratch, you can specify whatever texture coordinates are appropriate. e.g. different parts of the same texture could be mapped on different meshes and different textures can be mapped onto the same vertex list. Whether or not this counts as "onto the same model" is a technicality, I think.

If you want to use several textures on the same CMOD mesh, you have to have several vertices defined in the mesh's "vertices" section which have the same location but different texture coordinates. Then provide a separate trilist for each of the materials (each with a different texture0) that you want to map onto those vertices. (This is one of the optimizations that cmodfix does.)

Selden, these things you mentioned above I already do with Blender -> cmod exporter.

The model I was talking about would actually be a couple of thousand different models, each with it's own texture. They would of course be generated file by file with a program. Each model would cover 1 square degree of lat and long and use about 1/4 or1/8 of the actual data. The coordinates for each model is in the file name. N39W076.hgt for example.

Sort of like what Chris did with Eros but in may parts.

Such a model would only be practible if only about 10 square degrees were loaded at any one time. Max. Any new models loaded into storage would replace the models that left the feild of view. If you reached an altitude that displayed more than 10 square degrees in the feild of veiw the whole model would be disabled and Celestia would run normally.

This would have a lot to do with memory management. A topic I seen dicussed here from time to time. And it is probally futuristic. Mabey version Celestia 50.1

cartrite

I think that this is the wrong approach.

Instead than using cmod models a 3D terrain continuous LOD management is required.

There are many approaches for this and a lot of code already available even using Vertex Shaders. e.g http://sponeil.org/links.htm (the planet quad exapmple is exciting).

Unfortunately its a very complex thing, I guess that only Chris and perhaps Dirkpitt should manage this.

Kind regards.

Another link:
http://www.google.com/search?sourceid=n ... l+universe

Kind regards

I couldn't get into the top links. A username and password screen came up. I'll try your second link. Anyhow. For certain areas like Mt. St. Helens, Mt. Shasta, and (others?,) I'm going to create models. But I don't want to do it with Blender. It's getting too confusing.
As for the whole planet, I just wondered what it would take to do something like World Wind or Google Earth. The operative word here was plugin. The model managment would be done by a seperate program, that could be called by Celestia when certain conditions exsist. Like being close enough so a gazillion files aren't loaded into memory.

cartrite

I was registered at gamedev, perhaps this is the reason of the password request.

Another link http://www.gamedev.net/reference/list.a ... goryid=188

Using a heightmap + a normalmap texture with 1 km or higher resolution (that are not so huge) it should be possible to create a procedural sphere mesh and tassellate the surface using LOD algorithms. Introducing a bit of noise in the process it will be possible to simulate higher land resolutions, without having the need of downloading huge meshes. The normalmap will allow to discard the expensive continous normal calculations for the vertexes of the LOD procedural mesh. So correct illumination will be possible. Perhaps with new cubemap approach investigated by Chris the application of the textures to the procedural mesh will be easier to cumpute.

I guess that Google Earth works this way. The difference is that Google Earth dowloads the gazillion of files and blends the high resoution satellitary textures on the procedural mesh.

Kind regards

I'm not sure what Google Earth is doing but I have World Wind and they seem to lode .bil files for the height info as you approach a certain altitude and angle of view. They are downloaded as your view changes and stored in a cache for future use so unless there is an update to the files they need not be downloaded again. This is what I had in mind.

From the links I did see, they seem to suggest drawing a psudeo mesh in real time through different algorithms.

cartrite

cartrite wrote:From the links I did see, they seem to suggest drawing a psudeo mesh in real time through different algorithms.

IMHO a procedural mesh is the best approach.

[quote="Paolo"]
Using a heightmap + a normalmap texture with 1 km or higher resolution (that are not so huge) it should be possible to create a procedural sphere mesh and tassellate the surface using LOD algorithms.
[/quote]

okay, you have caught my interest and closer to my expertise. It isnt
immediately obvious to me that this is possible to do but lets look closer.

Let me check what you mean.
1/ You have a lo-res byte heightmap representing the coarse heightfield
of the planet.
2/ you have hires 16bit normal map used for rendering.

you want to start with the lo-res heightmap and make a mesh, then
add detail (opposite of LOD) by some procedural method (eg perlin noise)
so that resulting mesh has normals that match the normalmap within
a given error.? Is my understanding correct?

I dont think you could go for mesh resolution that was higher than pixel-
scaled normalmap though. You would have to calculate a finer scaled
normalmap. Would there be any point if you were overlaying a texture
which was probably same resolution as a normalmap anyway?

10 years or so ago, I looked at using a heightmap as a basis and then
creating perlin terrain around this but using heightmap as seed
generators so that always looked the same whenever you revisited it and
whatever level of detail. You could this approach but then need some
way of generating procedural texture based on the texture overlay too.
This seems a workable approach for fantasy planets but dont know about
it producing "realistic" portrayal of say mars?

Has anyone looked at OpenSceneGraph? I've seen some 3D lunar videos and using elevation data along with image data really looked fantastic. I'd look at importing an digital elevation model (DEM) or newer format--perhaps from ISIS. Using a package that readily imports existing planetary data can be a huge benefit. All I know is it's a really huge and open topic--mapping and images that is. Many, many different formats. I'd try to go with the mainstream.

OSG seems to have alot to offer but there would be some work involved.

I also think ISIS offers code also for public use.

http://isis.astrogeology.usgs.gov/IsisW ... ntro2Isis/

Does this look familiar--kinda?

http://isis.astrogeology.usgs.gov/IsisS ... 20f622b8c9

I have ISIS 3 and I'm currently learning how to use it. I downloaded the 256 m MOC images and my first project with ISIS will be to change their map projection to conform with the megt and mdim2 files. I'm also looking forard to the MRO mission this fall. Haven't heard much about that mission lately. Hope it's still going well.

cartrite

RocketMan@JSC wrote:Has anyone looked at OpenSceneGraph? I've seen some 3D lunar videos and using elevation data along with image data really looked fantastic. I'd look at importing an digital elevation model (DEM) or newer format--perhaps from ISIS. Using a package that readily imports existing planetary data can be a huge benefit. All I know is it's a really huge and open topic--mapping and images that is. Many, many different formats. I'd try to go with the mainstream.

OSG seems to have alot to offer but there would be some work involved.

I think that it would be very difficult to integrate OSG with Celestia. Celestia has its own shader system and lots of techniques for managing rendering of objects of a huge variety of sizes. Planet rendering is one of the core specializations of Celestia, and thus a hard place to plug in a general purpose library. It's one of the main places for innovation, so I want to stay close to the metal for the most flexibility. I'd happily rip out appropriate sections of code from their terrain renderer and use them in Celestia, however I've been reading about terrain rendering algorithms, and have some ideas for a post 1.5.0 release. Some results from this research might even make it into 1.5.0 in order to address some performance issues--uniform tessellation of planet spheres (even with culling) is really inefficient, and that's especially noticeable with the more complex shaders that I've added recently.

--Chris

scaddenp wrote:

Paolo wrote:Using a heightmap + a normalmap texture with 1 km or higher resolution (that are not so huge) it should be possible to create a procedural sphere mesh and tassellate the surface using LOD algorithms.

okay, you have caught my interest and closer to my expertise. It isnt
immediately obvious to me that this is possible to do but lets look closer.

Let me check what you mean.
1/ You have a lo-res byte heightmap representing the coarse heightfield
of the planet.
2/ you have hires 16bit normal map used for rendering.

you want to start with the lo-res heightmap and make a mesh, then
add detail (opposite of LOD) by some procedural method (eg perlin noise)
so that resulting mesh has normals that match the normalmap within
a given error.? Is my understanding correct?

Correct but if available you can have 16/24Bit height maps too. It will be a compromise.

scaddenp wrote:I dont think you could go for mesh resolution that was higher than pixel-
scaled normalmap though. You would have to calculate a finer scaled
normalmap. Would there be any point if you were overlaying a texture
which was probably same resolution as a normalmap anyway?

The tassellation of additional vertices obviously will interpolate the heightmap values. The amount of added noise to the interpolated vertices should be small. So the additional tassellated vertices should keep the same normalmap values. It's an approximation that IMHO should be acceptable.

A 500m resolution of Earh/Mars/Moon should be enough for heightmap/normalmap/texturemap.

scaddenp wrote:10 years or so ago, I looked at using a heightmap as a basis and then
creating perlin terrain around this but using heightmap as seed
generators so that always looked the same whenever you revisited it and
whatever level of detail. You could this approach but then need some
way of generating procedural texture based on the texture overlay too.
This seems a workable approach for fantasy planets but dont know about
it producing "realistic" portrayal of say mars?

It should be more than enough to give a realistic idea of a real 3D surface of the planets from an height of 500m even if some detail is added procedurally and a good compromise to keep an eye to performance. Also because I think that the transition between flat planetary surface seen form outer space with shaders(like now) and 3D LOD planetary mesh seen form inside atmosphere should be very smooth. Because both the meshes share the same texture and normalmaps.

In my vision this approach should merge seamlessly with the Virtual Texture feature.
Virtual textures with "virtual" Heightmaps and "virtual" normalmaps should add extremely high details to limited portions of the surface without the need of modeling the surface as CMOD. I think to this for places on Earth and for probe landing missions. This should give realistic idea of 3D surface to the observer if it stays on the surface.

But perhaps I'm missing something and this approach is not so good ad it seems to me.

Kind regards.

Paolo wrote:

A 500m resolution of Earh/Mars/Moon should be enough for heightmap/normalmap/texturemap.

But would the methods described above display veiws like this:





Some sreenshots taken with World Wind.

cartrite

I think that Celestia won't never be a clone of Google Earth or World Wind. So the images shown by Cartrite will be possible only using Virtual Textures.

But if you take a look to this thread http://www.celestiaproject.net/forum/viewtopic.php?t=10033 you'll understand what I'm meaning. The image shown by Fridger contains all the necessary data to implement a real 3D Landscape with enough detail. Of course referred to places of Earth that we know very well the amount of detail should seem low. But if applied to Mars, Moon and other planetary bodies for which Heightmap info is available this kind of data should allow extraordinary journeys on other planet surfaces.

Kind regards

I was kinda joking around when I posted those WW shots but I'm getting these shots like these now with a 64k base map and a cmod mesh.

http://www.celestiaproject.net/forum/viewtopic.php?t=10005

cartrite

[quote]
The tassellation of additional vertices obviously will interpolate the heightmap values. The amount of added noise to the interpolated vertices should be small. So the additional tassellated vertices should keep the same normalmap values. It's an approximation that IMHO should be acceptable.
[/quote]

Hmm. Say you used a 4k texture for normal map. It means you are still
using 1 normal for a something like a 2-10km square area of the planet.
No way is that good enough for 500m. This means calculation of
new normals or deal with the problem of LOD from much more detailed
heightmaps. (which is what I am sure worldwind would be doing). This
is very much frontier area of graphics at moment as far as I can tell. Well
to it in real time, it is anyway.

One of the reasons I want to start writing programs to create planetary models is shown in these screenshots. When I use too many samples from the input file, which has 64 data points per degree, I get these ridges.







At a further distance they become less noticeable but?????

The models created by Chris (eros) and GlobeMaker ( mars, earth, and venus) used their custom programs and came out looking cleaner and more realistic. What supprised me about Chris's eros was the small file used to created such a detailed model.

cartrite

Just found this page.

http://ozone3d.net/tutorials/vertex_dis ... apping.php

Perhaps should help.

Kind regards