It is currently Sat, 24-08-19, 22:24 GMT

All times are UTC




Post new topic Reply to topic  [ 47 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Wed, 30-09-09, 1:42 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
t00fri wrote:
++++++++++++++++++++++
Altogether I am VERY happy with the result. Now I really don't manage anymore to spot
any clearcut pinch signatures!
++++++++++++++++++++++


Just a short trash-feedback to say I too find this result quite acceptable! :D

Now I'll wait in silence to see more complex/clever decimation even if this last model is fine for me.

Tx for the good work! :D


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 13:27 GMT 
Offline
User avatar

Joined: Sat, 13-10-07, 18:18 GMT
Posts: 373
Please accept my thanks too Good Doctor.
Rather amazing what one can learn here on this science-based repository. :wink:

Thanks again, Brain-Dead

EDIT:
You don't suppose that this technique could be applied to Callisto do you?
In other words, does a tab file exist for this moon? Sorry, but you have me
looking at polar pinches now. :)


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 14:02 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
BobHegwood wrote:
...You don't suppose that this technique could be applied to Callisto do you?
In other words, does a tab file exist for this moon? Sorry, but you have me
looking at polar pinches now. :)


In fact most models in the actual Celestia official package do have such polar pinch. Look at Deimos for example. So yep, once Fridger create the ultimate tool someone at Shatters will probably have to rebuild all models having such tab files available. Of course I guess Fridger's Sci package will have by default such optimized models...


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 14:17 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4634
Location: Hamburg, Germany
Thanks friends,

that was well spoken ;-)

Fridger

PS: ...and if anyone wants to get rid of a little sarcastic remark from time to time, you're welcome over here... as long as noone is being personally offended, of course...


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 14:28 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
t00fri wrote:
PS: ...and if anyone wants to get rid of a little sarcastic remark from time to time, you're welcome over here... as long as noone is being personally offended, of course...

:lol:


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 14:58 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4634
Location: Hamburg, Germany
chris wrote:
Fridger,

Your system of reducing the subdivision in longitude is quite clever--sort of a prime factorization of the original subdivision level as you approach the pole. The results are much better than with the original and more straightforward tessellation. I've got a few further suggestions that may or may not be useful.

First, there's some region of texture space near the poles that will not be applied to the model because it's mapped to the degenerate triangles. Since the radii are given at intervals of two degrees in latitude, the affects of these gaps will be noticed within +/- 2 degrees of the pole. Would it work to add an extra row at, say, 90-0.25 degrees and -90+0.25 degrees? The vertex position and texture coordinates would simply be linearly interpolated from the +/- 88 degree rank. This should restrict the region affected by texture 'gaps' to only the places within 0.25 degrees of a pole. However, this generates some rather skinny triangles and may require filtering help than even 16x anisotropic filtering can provide.

Second, the maximum level of anisotropy is currently set to 8x in Celestia. We should probably increase this to 16x, which is commonly support by hardware. Change the following line in texture.cpp:

texCaps.preferredAnisotropy = min(8, maxAnisotropy);

This extends the effectively filtered region from latitude acos(1/8) up to acos(1/16) (82.8 degrees to 86.4 degrees.)

Finally, it looks like the remaining geometrical (as opposed to textural) 'pinching' is simply a result of anisotropy in the sampling of radii that remains even after decimation. I don't think that there's any way to get rid of it without a more 'destructive' decimation scheme that uses some filtering to generate new vertices at ideal spacings. You gain a better visual appearance, but sacrifice some data transparency (though not all of it, since the source code for the processing script is available.) I don't doubt that we have a philosophical difference on the proper approach here. :) Personally, I'd reduce the longitudinal tessellation by a factor two as soon as the value aspect ratio of the quads was less than 0.5 and use interpolated vertex positions. I can also understand why one might not choose to do this and instead use your current approach, which appears to offer an optimal tessellation without introducing interpolated vertices.

--Chris


Chris,

after first releasing yesterday version 1.3, corresponding to an extended pinch correction domain around the poles (cf my report above), let me now add a few more detailed comments about your suggestions:

(First:) Your first proposal sounds like worth a try. The insertions of an additional row at "pole - 0,25" is straightforward in principle and appears well motivated. According to my positive experience with adding in a few more 9's and 3's (=Jstep's) , I think the corresponding jstep in the extra line should just be 36 as well. The triangulation between 90, 89.75 and 88 degrees becomes VERY simple and solid if the triangulation level does not change..

But this "minor" change will clearly require a bit of recoding. The result will also look less easy and transparent, since so far, the face generation etc was all based on the loops over the integers (i,j) . Notably the "triangular networking" code will tend to loose transparency by various necessary exceptions due to this single extra line.

I think I would prefer, therefore, to take such changes in along with my generalizations of the whole tesselation process that I am working on already. There is also a somewhat scientific reason why e.g. for Phobos there is no particular hurry: so far, the texture data around the poles are not very good and the extra line may be a bit of an overkill. But we also know that there are these phantastic SRC (Super Resolution...) images in the pipeline that are excellent around the poles. Matching to these images there is also a forthcoming still unpublished new shape model. Here is a reminder of what I showed earlier:

Image

Finally, as Christophe mentioned already, my Celestia.Sci package will certainly come with no-pinch, scientific shape models by default. So there will be plenty of other applications, of course which justify fully the extra effort.

(Second:) OK, the 16x anisotropy setting is clear, except that I can't profit here on my old desktop.

(Finally:) Since yesterday's Version 1.3 appeared to be yet a significant pinch improvement step, you might reconsider perhaps your suggestion of interpolated vertices. If there is convincing evidence for a visible benefit, I don't think we have much different philosophical views here. As long as the original data and the source code are well documented I am happy.

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 23:42 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
Quote:
There is also a somewhat scientific reason why e.g. for Phobos there is no particular hurry: so far, the texture data around the poles are not very good and the extra line may be a bit of an overkill. But we also know that there are these phantastic SRC (Super Resolution...) images in the pipeline that are excellent around the poles. Matching to these images there is also a forthcoming still unpublished new shape model. Here is a reminder of what I showed earlier:
Fridger,
Raw camera images that the SRC camera took of Phobos are available through PDS. So these camera images can be projected with ISIS3 and use the m1phobos.tab as the shape model. There are some problems though. First, many images taken by the SRC camera are nothing but noise. Second, these same images that do contain data also have artifacts/problems that was processed out of the image before the mosaic was produced. Mainly the mirror distortion and possibly camera smear. It would be a lot easier if a complete list of the 53 images used for the mosaic was available but I can not find such a list.

The shape models, dtm files currently only cover up to orbit 2800 or so and it may be years before they actually make this latest dtm file of Phobos available.

The files can be found at PDS. http://pds-geosciences.wustl.edu/missio ... s/hrsc.htm
They do have the orbits that covered Phobos in the RDR files. The SRC files have a _sr2 affixed to the filename just before the extension. For example, the image you posted above corresponds to file h5889_0003_sr2.image, where 5889 is the orbit number, 0003 is the image number, and sr2 is the SRC camera.
Here is that image processed with ISIS3's pds2isis and std2isis. I did have to open with the gimp and transform->flip vertically. Then I scaled it down for this forum.

Image

If a list can be obtained, a similar mosaic can be produced with a projection based on the m1phobos.tab.

But a simple cylindrical projection of the polar area would compromise this data. No? Could polarstereographic and simple cylindrical textures both be used if, say, there were 3 meshes. One for the north pole, one for the center latitudes, and one for the south pole? I was thinking about this but I'm not sure the textures can be made to match each other.


cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 23:59 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
Another question I have about the 53 image mosaic is, why is the northern border of this mosaic black? The image showed above seems to suggest that there is data for 90 north so why was this left out of the mosaic? I know that no one here can answer that but has anyone else wondered about this?
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-10-09, 10:22 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4634
Location: Hamburg, Germany
cartrite wrote:
Fridger,
Raw camera images that the SRC camera took of Phobos are available through PDS. So these camera images can be projected with ISIS3 and use the m1phobos.tab as the shape model. There are some problems though. First, many images taken by the SRC camera are nothing but noise. Second, these same images that do contain data also have artifacts/problems that was processed out of the image before the mosaic was produced.


Yes, Steve, I was aware that the 53 images are available, but honestly prefer not to have to do the re-projections, the various subtle corrections (discussed in Prof. Neukum's site) and finally the elimination of artefacts myself. Also I was a bit hesitant whether the isis3 projection machinery would perfectly work (without "insider" info) for such a complex shape as m1phobos.tab.

Yet, if you have done already some promising evaluations of feasibility, we could try to do it nevertheless. Yet, as is often the case, one can spend weeks with such challenging tasks and then get finally lost, since some corrections are missing etc. ;-)

Quote:
Mainly the mirror distortion and possibly camera smear. It would be a lot easier if a complete list of the 53 images used for the mosaic was available but I can not find such a list.

That's already one of these little nasty obstacles on the way ;-)

Quote:
The files can be found at PDS. http://pds-geosciences.wustl.edu/missio ... s/hrsc.htm
They do have the orbits that covered Phobos in the RDR files. The SRC files have a _sr2 affixed to the filename just before the extension. For example, the image you posted above corresponds to file h5889_0003_sr2.image, where 5889 is the orbit number, 0003 is the image number, and sr2 is the SRC camera.

Thanks for the references! I will certainly have a closer look...

Quote:
Here is that image processed with ISIS3's pds2isis and std2isis. I did have to open with the gimp and transform->flip vertically. Then I scaled it down for this forum.
If a list can be obtained, a similar mosaic can be produced with a projection based on the m1phobos.tab.
But a simple cylindrical projection of the polar area would compromise this data. No?

What type of projection is that supposed to be? stereographic? like the one I quoted from their site, right? One observation that astonished me is that the quality of the published map at ESA by the Neukum group is so much lower despite their claim that their simple cylindrical map contains ALL these 53 new images!?

Image

That may well indicate that the deterioration happens via the simple cylindrical projection!
Quote:
Could polarstereographic and simple cylindrical textures both be used if, say, there were 3 meshes. One for the north pole, one for the center latitudes, and one for the south pole? I was thinking about this but I'm not sure the textures can be made to match each other.


As far as I know that's just the domain of cube maps. Yet as long as we don't get rid of the cube map seams that I proved to exist generically a long time ago, I am not so happy with switching to them.

Anyway, your digging was very useful to me!

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-10-09, 12:37 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
Quote:
What type of projection is that supposed to be? stereographic? like the one I quoted from their site, right?
The image I posted was a raw camera image. No projection. The RDR files are only calibrated. They also have map projected files but the orbits that the HRSC and SCR took images of Phobos are not included.

I have to figure out how to run spiceinit on the RDR files. Then I can try to project them with cam2map. I got an error when I tried to run spiceinit last night. It may be for one of a couple of reasons.
One being a bug in ISIS.
Two being an update is needed for the "mex" kernels. I see that NAIF has many more kernels than ISIS has in it's data folder for mex.
Three, it may be I need to do something special that I'm currently unaware of. I'm going to try and figure out what is going on with spiceinit today or tomorrow.

But my biggest drawback is finding which 53 images were used. On this page, http://www.geoinf.fu-berlin.de/eng/proj ... vation.php , down near the middle of the page, there is a chart. If you add up all the SRC images listed in this chart, it comes to 52. But at least 50 % of these could not have been used. These 50 % are total noise. Phobos is not even visible. All you see is gray and black dots with no pattern at all.
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-10-09, 14:33 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
t00fri wrote:
(Finally:) Since yesterday's Version 1.3 appeared to be yet a significant pinch improvement step, you might reconsider perhaps your suggestion of interpolated vertices. If there is convincing evidence for a visible benefit, I don't think we have much different philosophical views here. As long as the original data and the source code are well documented I am happy.


Pardon the delayed response--I was en route from Seattle to the Netherlands, and am now coping with the effects of a 9-hour time adjustment. Anyhow, the geometry looks much improved in your latest Phobos movies, so I agree that interpolation isn't necessary here.

--Chris


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 01-10-09, 16:03 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4634
Location: Hamburg, Germany
chris wrote:
t00fri wrote:
(Finally:) Since yesterday's Version 1.3 appeared to be yet a significant pinch improvement step, you might reconsider perhaps your suggestion of interpolated vertices. If there is convincing evidence for a visible benefit, I don't think we have much different philosophical views here. As long as the original data and the source code are well documented I am happy.


Pardon the delayed response--I was en route from Seattle to the Netherlands, and am now coping with the effects of a 9-hour time adjustment. Anyhow, the geometry looks much improved in your latest Phobos movies, so I agree that interpolation isn't necessary here.

--Chris


Welcome back to European time (and lifestyle ;-)) . I am surprised that you went so early? Didn't you talk about at least one week later? Or are you staying for 2 weeks this time?

Anyway, wishing high (STA) productivity and some fun, too...

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 02-10-09, 15:47 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 432
Location: Tuscany, Tyrrhenian Sea
Tested you phobos_cmod.pl: seem that polar pinching is really no longer more a problem! I spent a bit of time on how to "port" 16k Phobos' vertex count to the 2701 vertex of s7hyperion.tab but without success, due to my ignorance in programming. Anyhow, your script has suggested new evolution. See further in Docs & Tutorial.


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 02-10-09, 16:53 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4634
Location: Hamburg, Germany
Massimo,

good thanks. Extending my method to any other moon from the lot should be easy. I'll have a look.

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 02-10-09, 18:04 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
Probably the best way to extend the script to other moons / asteroids would be to have the script read keywords from the lbl files to get the parameters for lines, samples, resolution, etc.

I had a quick look through the shape model folder and it looks like there are 3 different resolutions used. 2 degrees, 3 degrees, and 5 degrees. There isn't a keyword for resolution but there seems to be a few constants. For lat, latitude, the constant is 181. For long, longitude the constant is 361 because 0 and 360 are probably both used. There is a keyword "ROWS" which seems useful. So
Code:
resolution = abs(ROWS) / (lat + long)
.
resolution should be rounded to the nearest integer.
But will the jsteps work for a model with 3 degree or 5 degree spacing between radius points?
cartrite


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 47 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group