Hi all,

I am not at all interested in fiddling with (CMOD) models by trial and error e.g. via Blender, Anim8or etc..
Actually, I hate to work with Blender, where EVERYTHING is non-standard, even the file selector
Since Steve (aka cartrite) and John VanVliet spent so much time with Blender import/export in this forum and in shatters.net, I was fortunately put off in an early stage of the affair.

Instead, my idea was to CMOD-convert directly standardized published shape model data, to which corresponding scientific texture mosaics are matched.

Due to its potato shape, Phobos is a good example for the obvious that a simple cylindrical map depends pretty strongly on the underlying non-spherical model. Consequently, any such texture update also needs a corresponding 3D-model update. Since my recent 4k Phobos texture update, an import of the published and matched shape model to CMOD format has become a necessity.

++++++++++++++++++++++++++++
So my task was to circumvent Blender entirely. Instead, I wrote just a little Perl script that produces directly an ascii CMOD version of the shape model in question. Chris Laurel's cmodfix utility can then be used to generate normals and convert the result into a binary CMOD format etc.
++++++++++++++++++++++++++++

Thanks to some pedagogical explanations by Chris Laurel about CMOD format essentials, this task amounted to just writing a Perl script not longer than HALF a page (apart from my detailed comments). Being "cross-platform", Perl runs almost everywhere and offers any kind of fancy math, even including a quaternion module Notably, its easy to learn...

Before explaining a bit more precisely what I did, consider first the cucumber shaped asteroid Itokawa,



where a quite analogous procedure was applied already. The respective scientific shape model data are published here http://hayabusa.sci.isas.jaxa.jp/index.php => Shape Model. With sufficiently high resolution, the Gaskell shape models on that site can give almost photo-realistic results!

For that purpose, ChrisL wrote a little utility in C++, as part of the Celestia distribution, called txt2cmod. It is located in the src/tools/cmod directory of the Celestia sources. It can very easily be compiled. This utility is just half a page of code and specializes in reading-in the published shape model data of Itokawa (in various resolutions) and converts them into ascii CMOD format. Subsequently, you just run cmodfix on this file and readily get a finalized binary CMOD. The command reads typically

cmodfix --normals --smooth 90 --weld --binary <input file> <output file>

That is all there is and it takes just a few minutes with fabulous results! That's what I wanted to do, too in case of Phobos.

There is one difference of most published shape models with the one for Phobos: The scientific reference for Phobos' 3D shape only contains vertex data (16471), but NO (triangular) faces that are required for using the cmodfix tool. Here is the reference for the latest scientific Phobos shape model by Peter Thomas/Cornell U., to which my new 4k texture was matched.:

EAR-A-5-DDR-SHAPE-MODELS-V2.1

http://sbn.psi.edu/pds/asteroid/EAR_A_5 ... phobos.tab
I have attached my Perl script that leads within minutes to perfect results for Celestia 1.6.x, like so:



The texture is what I recently discussed here: http://forum.celestialmatters.org/viewt ... 33&start=0

But the shape model (phobos.cmod) to which this texture has been assigned, is NEW, obtained just from these two commands:

> ./phobos_cmod.pl < m1phobos.tab
involving that above input file with the 16471 Phobos vertex data.
> cmodfix --normals --smooth 90 --weld --binary phobos_ascii.cmod phobos.cmod

The file phobos_ascii.cmod is the ascii-CMOD output from my Perl script and phobos.cmod is the improved binary CMOD that produced the above image. Note in particular how well now the crater labels match up with the center positions of their corresponding craters!!

Let me finally explain briefly what my Perl script does:

• Read-in the generalized Phobos elevation map (m1phobos.tab),
  [lat, long, radius(lat,long)] , lat=-90 + 2*i, long = 2*j, i = 0..90, j = 0..180. South pole<=> i=0, North pole <=> i=90, 2 degree mesh
  
• Define appropriate polar and azimuth angles in radian from the input (lat,long). Convert to Cartesian coordinates ([km]) by using the familiar expresion of [x,y,z] in terms of spherical polar coordinates. Note: Celestia involves z <=> y exchange convention! Hence
  
  
  Code:
  x[l] = radius * cos(phi) * sin(theta);
  z[l] = radius * sin(phi) * sin(theta);
  y[l] = radius * cos(theta);
  
  
  
• Next I introduce the appropriate (standard) map for OGL 2D texture coordinates (s,t)
  
  Code:
  s[l] = 0.5 * (1 - phi/pi);
  t[l] = 1 - theta/pi;
  
  
  
• Next I print out the various required entries of an ascii CMOD file and thereafter the list of 16471 vertices in Cartesian coordinates.
  
• The final step is to construct the required list of triangular faces that provide a tesselation of the 3D model. That's really easy... notably given Chris' explanations
  
  First, calculate facecount, the number of faces: Let m=90. Count the triangles that fit into the (i,j) cylindrical map with (2*m + 1)*(m + 1) = 16471 vertices: obviously, it contains 2*m * (m-2) non-degenerate quadrilinear faces = 4*m*(m-2) non-degenerate triangular faces and in addition 2*m non-degenerate triangles from the i=0 row (South pole) and 2*m such triangles from the i=m row (North pole). Altogether this gives
  
  facecount = 4 * m * (m -1) = 32040
  
  The 2*m degenerate triangles both in the i=0 and i=m rows are left out!
  (Recommendation by ChrisL)
  
• Finally, the list of triangular faces is printed out. That completes the ascii-CMOD for Phobos.

It's really not hard, TRY it yourself!

Fridger

+++++++++++++++++++++++++++++++++++++++++
Here is my well commented Perl script for download
http://www.shatters.net/~t00fri/images/ ... mod.pl.zip
++++++++++++++++++++++++++++++++++++++++++

After the John and Steven battle for a phobos model via Blender this solution of yours appears really sweet!
I would definitively try it myself but... what is needed to use this perl script? Can one feed it via terminal (command line on osX) with the .tab file?
Ideally for non fluent coders, a tool to convert whatever .tab file to a ready to go cmod would be great. Is that possible?

Mac OS X has perl installed by default. You can run the script from the command line like this:

perl phobos_cmod.pl < phobos.tab

...and it will create phobos_ascii.cmod.

--Chris

Christophe,

you Mac OSX guys got a complete UNIX system which OF COURSE includes Perl. So all you got to know is how to open your console

Then after downloading the scientific shape data (m1phobos.tab) to the same dir, type at the prompt

>perl phobos_cmod.pl < m1phobos.tab

An ascii-CMOD output file, phobos_ascii.cmod, will be generated after a few seconds. Then you got to work on it with cmodfix. Don't know, in what form you have that...

Fridger

Took seconds. . Looking at the ascii file though leads me to believe that I construct the triangle list wrong.
In this ascii file, is every line a triangle? If so, I'm not sure why any model I exported from Blender even works. I just generate a list of numbers. A number for every vertex. But the verticies are in a triangle order. This is because it is written in order for every face in the model.

The script looks pretty simple. I'll have to look into the inner workings of Perl.

The model had a little pole pinching though. Anyway to deal with that?
cartrite

I think I can understand now why both methods work. The vertex list produced by the perl script is in "file order". But your triangle list is in "face order". When I export a Blender model, my vertex list is in "face order" and my triangle list is in numerical order.

Oh by the way. I'm starting to work on a new gui system for Blender. I'm starting with that export script but it doesn't seem to be that hard to call up GTK's FileChoser instead of Blender's FileSelector. The copy of Blender I got running is built from source code. So I may be able to change things around a bit.
cartrite

Steve,


The easiest way of understanding my triangle tesselation is by looking at the simple cylindrical map depending on the two indices (i,j), i=0..m, j=0..2*m, (m=90). You may just start at the South pole (that corresponds to the row i=0) drawing triangles corresponding to that given 2 degree mesh. The particular problem with the first and last rows (mappend into South and North poles, respectively) is that the quadrilinear face vertices

degenerate into a triangle and a confluent "2-point triangle", since all vertices in these rows are mapped into one point! Hence I took 180 + 180 = 360 degenerate triangles out of the accounting. Apart from these subtleties, the rest is pretty straightforward: you just count the quadrilinears in rows 1 .. 88 and count twice the number of triangles replacing the quadrilinears. The vertices defining the triangles should all be enumerated with a well-defined orientation sense (clockwise or anti-clockwise)!

Fridger

Chris, Fridger,

it works just great! Tx for the hint!

Definitively being a coder do have some advantage...

Now, same as Steven, what about this polar pinch problem??

Edit: Fridger, for the cmodfix I just used the Cmodtool by DW (ChrisL tools wrapped into a GUI) and it worked just great too!

This will work if the vertices are duplicated every time they're used in a triangle. It's simple, but results in a larger model that will be rendered more slowly. However, cmodfix should take care of removing the duplicate vertices if you specify the --weld and --uniquify options.



Some polar pinch is inevitable. If you think about how the texels are assigned to triangles, you'll realize that some of the texels in the polar area aren't assigned to any triangle at all. Or rather, they're assigned to the degenerate triangles that are optimized away by Fridger's script (correctly--they wouldn't be drawn anyway.) It should be possible to mitigate the polar pinch effects by adding some extra rings of triangles near the poles. And of course, anisotropic filtering is important here too.

--Chris

Christophe, Steve,

the polar pinch problem is not big with my new 4k texture, since I worked hard to keep it small in the environment of the poles. You can locate the pinch "rays", put depending on the illumination, it can be hardly noticable.

As we both know, the pinch problem is not my responsability

Fridger

_________________

Perso, to appreciate the model I temporally removed the texture, and this is what I get with a 80° smoothing angle.



As I guess whatever texture will never "erase" this feature, I was wondering if you guys with your coder guru skills could not thing in something to rework those pole via some kind of interpolation of the geometry to remove the problem...

Christophe,

as I wrote, my new 4k texture does definitely do much better. Here is a big magnification of the North pole in my new 4k model with 8x anisotropic filtering.



I have also prepared special views of the Noth pole and South pole regions in my original thread about my new 4k Phobos texture here: http://forum.celestialmatters.org/viewt ... 33&start=0

The relevant views are





++++++++++++++++++++++++++++++
At least the remaining polar pinch doesn't appear to be a DOMINANT "eyecatcher"...
That's all that I can comment about this familiar issue.
++++++++++++++++++++++++++++++


Fridger

Ok, just to verify, could you post a similar shot without texture? I'd like to see how is the geometry on your system because I fear something is wrong on mine...

Here with the texture I use so far; the pinch of the texture is unnoticeable (tx to the anisotropic filtering and all), but the pinch in the geometry do affect my final rendering...

OK, here it comes (Click for somewhat bigger display),



I run the CMOD again with no texture coordinates, but the texture color...

Fridger

Tx, I'm relieved, I do have the very same pinch.

BTW, is this script good for any .tab files or it was just done for Phobos?