3DMars update

[cartrite]

This is close to the dimensions of the new model I'm creating coverage wise.
The actual texture is about 25 meters per pixel. It's a mosaic from h0344 and h0360 from the Mars Express obtained from HRSCview. Freie Universitaet Berlin and DLR Berlin, http://hrscview.fu-berlin.de/ I don't know how much detail will be in the mesh but I'm one step closer to actually doing this.



This combined dem mosaic that was created along with this texture will also be used as the shapefile for the ctx mosaic I'm working on from the same area. That's going to be 6 meter per pixel resolution. I may also use this to create a close up VT.
cartrite

The MRO CTX Imager data was just updated at PDS. They now have 127 volumes and there may be a lot from this area. Hope so anyhow. They haven't updated the search tools yet because after entering the coordinates it only returned volumes up to 63.

I select files and generate a report with left and right longitude and upper and lower latitude file name and volume number. Then I load this into a spreadsheet and sort. This way I can identify overlapping files. I want to use ctx images and a dem from the area above and model it.
cartrite

[cartrite]

Hi All,

Hope this isn't confusing but I just updated the 3dmars model. For those of you that may have downloaded this model already this update is nothing new. In fact your better off with what you already have. I had to make space at my web site and one of the models had to go.
Here are the changes.
I deleted both versions 5 and 5a. I changed version 5a to 6 because I removed the tangents from the Vallesmarineris area due to conflicts with the shadows on the texture. So that area does not have a normalmap anymore.

The Olympus mons area still has a normalmap though. The model also uses smaller 4k textures. For those of you that have the tiled version these would be 2k equivalents. There is also an 8k texture folder available for those of you that have newer cards. These 4k textures that come with the model are 1 texture per area.. No tiles. No inside seems. If you can use the 8k textures that would be the same resolution as the original model or version 5.

Edit:For those of you with older cards, older than the 8000 series, you may get better frame rates with this version 6 model because of the smaller 4k textures and less tangents.

Don't confuse this update with what I posted above. I'm a ways from publishing that one.
cartrite

[cartrite]

The MRO CTX Imager data was just updated at PDS. They now have 127 volumes and there may be a lot from this area. Hope so anyhow.

After going through the data from the new MROCTX data release at PDS, there was only 1 more image to the west for the texture I wanted to use for this model. This is helpful but I was looking to extend it to the east. So it seems doubtful that this experimental model will be finished anytime soon. Not until the next release anyhow. I am going to see if there are other areas I could do. I could also develop it with the Mars Express texture though. Not sure yet.
cartrite

[danielj]

Apparently,the low frame rates I got was because the 3dMars from Motherlode wasn??t suited to Celestia 1.5.0,but for 1.4.1.I download the 3dmars ver6 and now I can get frame rates around 25-30 fps even under Open GL 2.0.However,I deleted the old 3d Mars folder in Extras,but Mars2 is still there and the new addon is in Mars3.How can I fix it?

The MRO CTX Imager data was just updated at PDS. They now have 127 volumes and there may be a lot from this area. Hope so anyhow.

After going through the data from the new MROCTX data release at PDS, there was only 1 more image to the west for the texture I wanted to use for this model. This is helpful but I was looking to extend it to the east. So it seems doubtful that this experimental model will be finished anytime soon. Not until the next release anyhow. I am going to see if there are other areas I could do. I could also develop it with the Mars Express texture though. Not sure yet.
cartrite

[cartrite]

Sorry danielj,
EDIT: FYI You don't have to delete an addon to disable it. You only need to rename the filename.ssc file to something like filename.ssc.txt. Then the addon will be disabled.
I was experimenting with brightening the sky as seen from the surface. Mars3 is a dummy model and does not really exist. It is there so I can render an "old" atmosphere that doesn't have a problem with a "dark" sky. Anyhow I uploaded the model with that experimental ssc file. Below are the contents of 3396mars.ssc. If you don't like having a mars3 you can delete the area in red. But then if you go to the surface the sky will be almost black. Removing mars3 from my file results in about a 2 to 5 fps gain. Not much. But I go to the surface a lot so........

Mars2 and Mars3 are occupying the same space. Mars2 is the real model and has the new atmosphere settings. Mars3 is the dummy model and has the old atmosphere settings. Both atmospheres are being rendered. You see the new settings from space and the old settings near the surface. Sorry for the confusion.

"Mars2" "Sol/Mars"
{
Mesh "mars.cmod"
Radius 3396
Atmosphere {
Height 30
Lower [ 0.8 0.6 0.6 ]
Upper [ 0.7 0.3 0.3 ]
Sky [ 0.83 0.75 0.65 ]
Sunset [ 0.7 0.7 0.8 ]
Rayleigh [ 0.000175 0.00000075 0.00000075 ]
Mie 0.00065
MieAsymmetry -0.21
Absorption [ 0.00002 0.00002 0 ]
MieScaleHeight 30
CloudHeight 10
CloudSpeed 0
CloudMap "MarsClouds.png"
# Slightly bluish sunset, as seen in true color pictures
# from Pathfinder
}

CustomOrbit "vsop87-mars"
EllipticalOrbit
{
Period 1.8809
SemiMajorAxis 1.5237
Eccentricity 0.0934
Inclination 1.8506
AscendingNode 49.479
LongOfPericenter 336.041
MeanLongitude 355.453
}

RotationPeriod 24.622962
Obliquity 26.72
EquatorAscendingNode 82.91
RotationOffset 136.005

Albedo 0.150

}

"Mars3" "Sol/Mars"
{
Mesh "dummy.cmod"
Radius 3376
Atmosphere {
Height 30
Lower [ 0.8 0.6 0.6 ]
Upper [ 0.7 0.3 0.3 ]
Sky [ 0.83 0.75 0.65 ]
Sunset [ 0.7 0.7 0.8 ]
# Slightly bluish sunset, as seen in true color pictures
# from Pathfinder
}

CustomOrbit "vsop87-mars"
EllipticalOrbit
{
Period 1.8809
SemiMajorAxis 1.5237
Eccentricity 0.0934
Inclination 1.8506
AscendingNode 49.479
LongOfPericenter 336.041
MeanLongitude 355.453
}

RotationPeriod 24.622962
Obliquity 26.72
EquatorAscendingNode 82.91
RotationOffset 136.005

Albedo 0.150

}

Here is a screenshot near the surface with mars3.



And here is a screen shot without mars3.



cartrite

[cartrite]

An old model revisited. This is the 3dmars on the Celestia Motherlode.
Unlike 3dmars-ver6 at my web site, this model is simple and uses only 1 texture which is whatever mars texture you have called mars.*. It has the same amount of triangles though. So I downloaded the 8k shaded version by Praesepe at the ML and renamed it to mars.dds. Then I ran it and took a couple of screen shots. Contrary to a PM I sent BobHegwood, maybe this "MODEL" is worth keeping at the ML after all? I told him the 3dmars MODEL probably wasn't worth keeping.


cartrite

[Johaen]

Unlike 3dmars-ver6 at my web site, this model is simple and uses only 1 texture which is whatever mars texture you have called mars.*. It has the same amount of triangles though. So I downloaded the 8k shaded version by Praesepe at the ML and renamed it to mars.dds.

The texture you use is limited by the max size allowed by your video card, correct? 8k for you, 4k for me, 2k for alot of people? I'll DL Don Edwards' 4k Mars texture and see what I think.

[Johaen]

I've tried it out using Don's 4k Mars DDS texture. It's interesting, but not detailed enough to be worth it, in my opinion. I did notice something odd happening though. Whenever I use any render path other than OpenGL 2.0, it works just fine. But when I switch to OpenGL 2.0, the entire planet disappears and turns black. The atmosphere is still there, but the planet itself is a black hole of nothingness. Odd, no? I've never seen it happen before. This is using pre4, just for reference.

[cartrite]

I've tried it out using Don's 4k Mars DDS texture. It's interesting, but not detailed enough to be worth it, in my opinion. I did notice something odd happening though. Whenever I use any render path other than OpenGL 2.0, it works just fine. But when I switch to OpenGL 2.0, the entire planet disappears and turns black. The atmosphere is still there, but the planet itself is a black hole of nothingness. Odd, no? I've never seen it happen before. This is using pre4, just for reference.

To answer your question from your previous post, yes, your card does have to support 8k to use the size I did. I tend to agree with you about being not being detailed enough to be worth it with 4k or less. That is why I downloaded the SHADED version. Even at 8k, an unshaded texture looks like it is lacking.

As far as why it turns black in OGL2, that is strange. The screen shots I posted were in OGL2 also using a dds texture running a cvs version dated 12/14. This is probably going to be a nightmare for a lot of addons after 1.5 is released.
cartrite

[BobHegwood]

Whenever I use any render path other than OpenGL 2.0, it works just fine. But when I switch to OpenGL 2.0, the entire planet disappears and turns black. The atmosphere is still there, but the planet itself is a black hole of nothingness. Odd, no? I've never seen it happen before. This is using pre4, just for reference.

I also have some strange problems with render paths. Using the
standard OpenGL 2.0 on my machine, I can hardly view some moons
and planets because they shine SO brightly that they are difficult to
look at. If I switch to OpenGL Vertex path, looks okay. This doesn't
work with every object though. Some I have to view in OpenGL 2.0
for the right effect, and some I have to use multi-texture, or some
other path.

Methinks these problems occur because of the various manufacturer's
versions of what they see as OpenGL. Then too, you have
various driver updates and so-forth, so all is not as it seems.

Thanks, Brain-Dead

[cartrite]

Bob,
If you are looking at a moon or whatever and it looks too bright in OGL2, I bet there is a specular definition in a ssc file somewhere. If I uncomment these settings in my solarsys.ssc

Code: Select all

   Texture "mars.*"
   NormalMap "mars-norm.*"
   #SpecularTexture "mars-spec.*"
   #SpecularColor [ 0.25 0.25 0.255 ]
   #SpecularPower 0.5   


The 3dmars model I showed the last 3 screenshots from looks too bright also.

[fsgregs]

I am reading about deletions and editing of the motherlode's contents with some increasing concern. The 3D shaded Mars texture is a good example.

I have used the texture for years because (1) it is very detailed, (2) its colors in my opinion reflect the true color of Mars. We went around with Mars color in the forum about two years ago, and this texture was rated the most realistic. All of the other mars textures on ML (in my opinion) are either more blurry or the wrong color.

To learn that Bob was asked by a forum member to delete the texture from ML is a bit distressing. Although there may be differences of opinion about it, we should not be arbitrarily deleting things like this texture. Some of us may want it and disagree with such a deletion.

I don't see the need to be editing the contents of the ML, unless there is something totally wrong with the object. Even then, some folks might have an interest in that texture or object for some fictional solar system. Who decides what to delete becomes a problem also.

I think we need this to be a separate thread so we can discuss it. As such, I am creating the thread in the Users section now.

Regards

Frank

[cartrite]

I am reading about deletions and editing of the motherlode's contents with some increasing concern. The 3D shaded Mars texture is a good example.

I have used the texture for years because (1) it is very detailed, (2) its colors in my opinion reflect the true color of Mars. We went around with Mars color in the forum about two years ago, and this texture was rated the most realistic. All of the other mars textures on ML (in my opinion) are either more blurry or the wrong color.

To learn that Bob was asked by a forum member to delete the texture from ML is a bit distressing. Although there may be differences of opinion about it, we should not be arbitrarily deleting things like this texture. Some of us may want it and disagree with such a deletion.

I don't see the need to be editing the contents of the ML, unless there is something totally wrong with the object. Even then, some folks might have an interest in that texture or object for some fictional solar system. Who decides what to delete becomes a problem also.

I think we need this to be a separate thread so we can discuss it. As such, I am creating the thread in the Users section now.

Regards

Frank

No one asked Bob to delete the shaded Mars texture to my knowledge. I told Bob in a PM that the 3dmars addon I created and uploaded to the ML may be obsolete. So it may go.

Whenever I use any render path other than OpenGL 2.0, it works just fine. But when I switch to OpenGL 2.0, the entire planet disappears and turns black.

I tried Dons mars textures and they turn black for me too. They might have mipmaps and that type of texture may not render on a mesh. Not Sure.
cartrite

[selden]

The planet turning black probably should be reported as a bug in Celestia in the Bug Tracker on SourceForge.

If *you* don't report it, it never will get fixed.

[cartrite]

The planet turning black probably should be reported as a bug in Celestia in the Bug Tracker on SourceForge.

If *you* don't report it, it never will get fixed.

I've been looking into this and I think the reason Dons textures turn black in OGL2 while using my model is his texture shows up as a RGBA. I remember having problems rendering a RGBA on a mesh. This has been addressed before, hasn't it?
cartrite

[selden]

My understanding is that

1. RGBA textures which are applied to Celestia's internal planetary spheres have their A channels treated as specularity.

2. RGBA textures which are specified within CMOD or 3DS models as diffuse materials have their A channels used for opacity. A separate material is used for specularity.

3. RGBA textures which are applied to CMOD or 3DS Meshes using an SSC Texture statement replace the models' internal diffuse textures and have their A channels used for specularity. This is for consistency with how RGBA textures are applied to Celestia's internal planetary spheres. All other SSC texture declarations are ignored when applied to Meshes.

If they don't work this way, it's a bug and needs to be reported.

(I have seen strange interactions with surface normal vector textures, but I convinced myself it was because I didn't understand them.)

I think Chris may be hoping to make SSC texture support for models more general in a future major release of Celestia, but that won't be soon.

[cartrite]

My understanding is that

1. RGBA textures which are applied to Celestia's internal planetary spheres have their A channels treated as specularity.

2. RGBA textures which are specified within CMOD or 3DS models as diffuse materials have their A channels used for opacity. A separate material is used for specularity.

3. RGBA textures which are applied to CMOD or 3DS Meshes using an SSC Texture statement replace the models' internal diffuse textures and have their A channels used for specularity. This is for consistency with how RGBA textures are applied to Celestia's internal planetary spheres. All other SSC texture declarations are ignored when applied to Meshes.

If they don't work this way, it's a bug and needs to be reported.

(I have seen strange interactions with surface normal vector textures, but I convinced myself it was because I didn't understand them.)

I think Chris may be hoping to make SSC texture support for models more general in a future major release of Celestia, but that won't be soon.

Here is the models ssc file.

Code: Select all

Modify "Mars" "Sol"
{
       Mesh "mars-mons-valles-131.cmod"
       Texture "mars.*"
       Radius 3396 #small
       Atmosphere {
      Height 50
      Lower [ 0.8 0.6 0.6 ]
      Upper [ 0.7 0.3 0.3 ]
      Sky [ 0.83 0.75 0.65 ]
                Sunset [ 0.7 0.7 0.8 ]
                # Slightly bluish sunset, as seen in true color pictures
                # from Pathfinder
   }

       
       Albedo            0.150
}


And here is the models material section.

Code: Select all

#celmodel__ascii

material
diffuse 0.8 0.8 0.85098
end_material


I got no idea what is going on here. With these settings, Dons RGBA texture, Mars_8k-050104.zip, is not being rendered and the model is opaque. You can't see stars through it.
EDIT: I did rename Don texture to mars.dds
Anyhow, what if the alpha channel is empty. This is probably the case here.
cartrite

[cartrite]

Just for fun I renamed earth.png (the one that comes with celestia) to mars.png and tried that on the model. Same results. Black. Now, given the specs on the model I posted above, is this really a bug. If it is I'll try to fill out a bug tracker report at source forge.
cartrite

[selden]

I have to wonder if there might be something funky in the materials definitions in the model. Be sure to provide a simple failing example in your bug report.

[cartrite]

I have to wonder if there might be something funky in the materials definitions in the model. Be sure to provide a simple failing example in your bug report.

I don't understand? The materials section only says

Code: Select all

material
diffuse 0.8 0.8 0.85098
end_material

Alright, just submitted a bug report at source forge. Dumb question here. How can I edit it or can I?
cartrite