Friends,
in this thread, I want to present my new results about an almost
complete reduction of the familiar polar pinch effect at the level of (ascii) shape models! I am quite happy how well this works.
For concreteness, let me discuss things via my recent Perl script for
conversion of shape model data of Phobos to ascii CMOD format. For now I'll assume that anisotropic filtering gets rid of polar pinching at the
level of textures. Hence, I won't bother about texture pinch now.
I'll present the main algorithm in some hopefully intuitive detail. I shall dispense with math formulae and rather show you with a couple of drawings what the new algorithm amounts to. In detail, the procedure is a bit tricky, yet I ask you to bear with me...the algorithm may open up a number of further important applications and certainly lends itself to generalizations!
The corresponding code and the results you can study explicitly in my
new update 1.2 of the Perl script that I have again made available for download towards the end of this post.
The underlying idea arose from the fact that my conversion script for Phobos had to generate the
triangular faces for the required
tesselation of the shape model.
I noted that conceptually this task is quite related to the previous (pinch) optimizations long available in my F-TexTools for
VT-tile generation. Unlike simple cylindrical maps, in both cases, the
lengths of circles around the North and South poles for fixed polar angle theta decreases to ZERO towards the poles. Hence, to avoid pinch problems due to a huge overlap of data along these
small circles, the data must be "thinned out" around there.
Analogously,
in shape models, the sizes of tesselation triangles must strongly increase towards the poles. This is less straightforward in practice than it might at first appear...
In the previous version 1.1 of my Perl script I conventionally used a
constant triangular mesh, as illustrated in this first drawing.
Apparently, the whole (i,j) plane is covered by triangles of same size. Of course, after a map to 3D this simplicity will be considerably distorted. But never mind for now.
The integers (i,j) are to label a
regular latitude and longitude mesh in a simple rectangular map. The entire
lines (j=0..180) at i=0 and i=90 will be
mapped into ONE point, respectively, the
South pole and the
North pole of the Phobos model. That's actually why I deleted half of the triangles in the top and bottom rows, since in reality these will become degenerate "two-point" triangles.
According to my above observation, the task was to decrease the number of triangles in the polar rows by increasing their
sizes in longitude (= jstep). How much can be easily estimated. Note that initially (in the above figure),
we had jstep = 1 throughout!,
A strong constraint is that the
jstep has to remain integer AND the
number of triangles/row = 180/jstep must also be integer!! A possibly unique solution is this
set (Note that
I only discuss the south pole now for simplicity)
Code:
i = 0: jstep = 36, # triangles = 180/36 = 5
i = 1: jstep = 18, # triangles = 180/18 =10
i = 2: jstep = 9, # triangles = 180/9 = 20
i = 3: jstep = 3, # triangles = 180/3 = 60
i >= 4: jstep = 1, # triangles = 180/1 = 180
and analogously for the North pole, of course.
With these considerations, one might
naively try a tesselation around the south pole like in diagram A) of the following display (to be continued a lot on the right, of course).
The triangular sizes in longitude (jstep)have been precisely drawn as indicated in the table above and also shown in the
Jstep column on the right.
BUT this cannot work right, yet!
The reason resides in the purple dots drawn in figura
A). Once the 3D mapping of this arrangement takes place, you will see
black triangular spaces in-between the individual rows (<=> successive circles around the pole), precisely
since at the purple dots triangle vertices remained DISCONNECTED to others!. Obviously, we need to be a little more sophisticated.
We do have to connect ALL vertices together, to get rid of this artefact!
How to do this uniquely was a bit of a chore, but figure
B) shows the unique result.
I have drawn the additional triangle insertions ("bionds") in
purple, so you may compare easily with figure A). Still, we got significantly less triangles than originally with the equal sized mesh. This is good, since it gives rise to a significantly smaller file size in the end.
Now let me show you how much the polar pinch situation has improved with my new tesselation.
Firstly, here is a large zoom of the
original pinch appearance around the North pole:
The disturbing starlike pattern should be familiar by now....
Next we look what my new algorithm has done to exactly the same region:
Not at all bad, I would say
, and here is the
South pole after the pinch correction:
Note that until VERY close to the actual pole (purple S), you can see graphical detail and
NO pinch rays! If you don't use excessive zoom, you are not able to tell anymore where the poles are precisely located!
++++++++++++++++++++++++++++++++++++
Finally, here is my updated set of files for you to try out. For your convenience, I have added again the scientific data file along with the processed ascii and binary CMODs. The latter you can directly try out in Celestia.
http://www.celestialmatters.org/users/t ... os_1.2.zip
A convenient new feature is that the required number of faces is now calculated and printed out by computer, since with this more complex tesselation the analytical calculation might be a bit heavy for some
.
++++++++++++++++++++++++++++++++++++
Let me know,
Fridger