Celestia Forums

Started here: http://www.shatters.net/forum/viewtopic.php?f=6&t=15864
this is the 1.1 version of the CMODtracer.

- made perl scripts self-executables for standalone works with coords datasets (they works also within CMODtracer, of course);
- made the perl placeholder constructor (formerly absent, for the purposes above);
- increased the floating point values;
- thinned the SVG output pixel contour to 0.1px instead of 1.0px (this prevent "black" shapes when closest)
- some eye-candy
- added "refine" button for building line(s) from two distant points (see below):



From Chicago to L.A. Single line(s) built from two points goes inside the sphere, and a straight path should be not so easy to follow, either without the placement of successive markers or because here one doesn't deal with a 3D modeler. Then with repeated clicking of the refined button, will be added all the remains points (recursive means amongst ends). It isn't too much advanced, but is working. Note that the result is visible after restart. In the example above 5 clicks are enough. Do not click 100 times for covering the radius of an atoll, of course The refine works both on open and close shape(s)


Just after 5 clicks...


Here is as should be the line in SVG (scripts included).

Zip:
http://marauder.webng.com/files/cmod_tracer_1.1.zip (96 Kb)

CMODtracer ver. 1.2

- Added: internal coordinates' locations constructor (Perl);
- Added: customization for the time (stop/active) (Lua);
- Added: marker when CMODtracer is displayed (Lua);

Why the coordinates' location? Suppose that on Enceladus one do trace as below:



The shape is not continue (some distant points, partially beneath the surface) because is not refined, but such operation have to be set apart for the moment. Now suppose one wish to trace yet another shape, and such shape be contiguos, or let encounter the previous at one point of its sides. There is not way to know what points have been traced. For this purpose, the new CMODtracer version take into account the building of a coordinates' location file every time the CMOD shape is built. To view it, you must set "label features" and "other" in the Celestia's location menu (as below).



Now is supposed to trace a feature starting from the point 13.495... and ending at point 16.016... (arrows), In accomplish this, do open the "coordinates.txt" within you favorite text editor and copy/paste the starting point coordinate at end of file (be sure that after it there always be a blank line - if not, simply press enter). Save the file and on Enceladus place the marker upon the successive points of the new path. Do not start the new path, just click the second button (open path) and so on, like you should stay tracing as usual. When you are close to the ending point, just copy and paste the ending point coordinate at end of the file. Note that the coordinates.txt must be "refreshed" in order to see the new traced points; thus, if it's still open within the text editor, do close and then re-open it.
At this point do rebuild the CMOD placeholder + append the lines. Note that also the new coordinates will have now its location'text. Now you can restart Celestia and go to Enceladus newly.



This is as should be the new traced path (not yet refined). Now you can click the buttons' sequence: refine + placeholder + append and restart (or doing such operations "offline").



As you can see, although here the shapes are coarse for explanations, with only one refine's button click the lines no longer sinks into the moon. Note that the coordinates' locs accounts also for the refinement; and being this latter accomplished through means by means, it account just for the middle to middle points of a line, useful if one wish either to start or to end in such "middle points".
The operation sketched above can be repeated sequentially until to achieve pretty complex shapes (the more points are closest the more shape(s) is detailed). Then the coordinates' location SSC can be successively removed.

Do not forget to set the $locsplace = "Sol/Saturn/Enceladus" for Enceladus in this case (or whatelse object) within the relevant Perl script called "coords2locs.pl" (being the Earth as default).
Note that whether you forget to set the proper traced's SSC or the proper string within the Perl script for locs, you can always accomplish such operations "offline", without to re-tracing too; be careful, of course, of not to start the new path again. (anyhow, even though such operation should be done by error, the file coordinates.tmp will hold the coordinates' dataset unless the CMOD model is built; so you can copy the coords from it). When all the "files speciments" are done, unless specified, the follows operations can be done with Celestia active.

For the purpose above, the CMODtracer now show the marker when the plug-in is displayed and no longer when the "start new path" button is pressed.

http://marauder.webng.com/files/cmod_tracer_1.2.zip (100 Kb)

EDIT LATER:
Reds are corrections for better explanation.

One thing I forgot: the "coords2locs.pl" script work within the CMODtracer because its relevant loading string has been added to the DOS batch files. LINUX and OSx users must set this for the consoles; being aware that all Perl scripts performs their own operations upon the "coordinates.txt" simply through the double clicking on its icons (even in Windows). Basically, the CMODtracer can be used just to pick up the coordinates and then build the 3D model within the shell.

Another use of the CMODtracer could be that of pick up single coordinate and then assigning to it a custom name. In such manner is possible to get a personal location SSC. For this purpose, the Perl script below, either through console or in standalone mode (double click) will help in that. In the image below, to the Earth's geological provinces have been assigned the names is that way.



How it work: no matter what program you launch first, either Celestia or the script, when you are above your custom location press the CMODtracer's button sequence 1) - 2) and add the name by the script's prompt. Always repeat these steps for all locations. A custom mylocs.ssc file will be created in append mode. You then can rename it as you wish for making another one, and so on. The directives can be set first within the script and then modified (on the whole) by a good text editor if you wish. Note that you must pick up the coordinate first. Do not be afraid if type the wrong name, the mylocs.ssc is always editable in standalone by a text editor, without to exit Celestia/script.



Copy/paste the code in a text editor, save it as "yourname.pl" and put the script within the ../cmod_tracer/models folder. Double click on it or lauch the console with the path relevant to it and type: perl "yourname.pl"

Found a bug and a pseudo-bug.

1) bug: lines 51-52 of the asvg.pl must be commented for appending shapes and then writes newly at the end of the obtained SVG (copy/paste from the script, for the moment).

2) pseudo-bug: the single picked up coordinates' method doesn't work when the CMODtracer is inserted into the LUATOOLS. The coordinates.txt is not cleaned up when the first button (start new path) is pressed, while the file is wrote in appending mode (as it must be) istead when the second button (next point) is pressed.

Vincent, Jogad, your suggestion here? Why the LUATOOLS must "know" what happen to the coordinats.txt?

Apart the "bug", indeed my fault, the Perl scripts for SVG really works, though. Below there are two screenshots of the shapes made during the CMOD conversion of the world's country dataset shipped within the Large Igneous Provinces pack. Here is a 4k texture, but the SVG on which I worked around was set to 8k (as sketched here: http://www.shatters.net/forum/viewtopic.php?f=6&t=15864&start=0) and then resized after colored. Note how the "no man's lands" (here left white) matches perfectly with the relevant CMOD model.






The "wet painting" affect is achieved through the assignment of the 50% trasparency to the layer.

Hi,

pretty pictures and very good job

Fenerit wrote:2) pseudo-bug: the single picked up coordinates' method doesn't work when the CMODtracer is inserted into the LUATOOLS. The coordinates.txt is not cleaned up when the first button (start new path) is pressed, while the file is wrote in appending mode (as it must be) istead when the second button (next point) is pressed.

This doesn't work because lat and long are always "nil" when your start_new_path function is called.

in Lua_edu_tool long and lat are global variables and not in LUAPLUGINS.
Your must delcare long and lat as local at the beginning of your plugin (like long1 and lat1) and not inside another function.

Hi Jo?l. Thanks!

CMODtracer ver. 2.0



- Added: temporary files clean up button (Lua);
- Added: SVG builder (Perl);
- Added: restyling of custom location builder (Perl);
- added: new PDF guide;

changes from v.1.2
- removed the placeholders constructors.
CMODtracer now work through temporary file and get final outputs. This make the placeholders (CMOD and SVG) constructors' steps obsolete.
- increased the SVG output resolution to 8k;

Bug fixed:
- SVG builder.

The SVG output has been tested with Inkscape 0.47 (vector) and GIMP 2.6 (raster + trace paths).
The script has been set with a table for converting the workplace amongst 32:45 px as follow:

my $constant = 32/45; # constant;

0.25k (256x128) = 360 * 1 * (32/45) x 180 * 1 * (32/45) --> multiplier 1;
0.5k (512x256) = 360 * 2 * (32/45) x 180 * 2 * (32/45) --> multiplier 2;
1k (1024x512) = 360 * 4 * (32/45) x 180 * 4 * (32/45) --> multiplier 4;
2k (2048x1024) = 360 * 8 * (32/45) x 180 * 8 * (32/45) --> multiplier 8;
4k (4096x2048) = 360 * 16 * (32/45) x 180 * 16 * (32/45) --> multiplier 16;
8k (8192x4096) = 360 * 32 * (32/45) x 180 * 32 * (32/45) --> multiplier 32;
16k (16384x8192) = 360 * 64 * (32/45) x 180 * 64 * (32/45) --> multiplier 64;
32k (32768x16384) = 360 * 128 * (32/45) x 180 * 128 * (32/45) --> multiplier 128;

in which one can choose e.g.:

my $width = 8192; set the SVG width;
my $height = 4096; set the SVG height;
my $multiplier = 32; is the scalar multiplier (see above);

Then is matter of stroke-width to find the best user-setting. Now is set as 0.1 and with a res. of 8k it can do the lines invisibles at first sight. Then, do zoom in. This is good whether one wish to work on the shape(s) as vector (Inkscape, Aldus, Illustrator etc.), less whether one wish the final raster. However, even though in raster, the SVG importers allow the trace paths (GIMP), thus one can assigning them its stroke width within the graphic program.

http://marauder.webng.com/files/cmod_tracer_2.0.zip (0.96 Mb, mainly the pdf)

CMODtracer 2.0 experimental service pack 1.0
Why an experimental service pack?

Facing with the problems of this map:
http://www.shatters.net/forum/viewtopic.php?f=5&t=16045
in which the same geo-age's text must have different Importance directive, I've made few modification to the CMODtracer.

1) Completely rebuilt the "mylocs.pl" script in order to assign also the Importance;
2) Added one function to the "cmod_tracer.lua" in which is taken into account the linear assignment of the custom Importance(s) through the relation (observer/object)-radius.

Enstabilished the superior/inferior limits for the distances and its Importance's values, all the remains values are within this range. For my geomap's purpose I use 5 linear values, but they could be morer, both randomized and not linear as well. In sumn, in my case they depend on the linear "zoom in".
Now, when CMODtracer does pick up a coordinate, it add also the relevant, computed, Importance. In this manner the file "coordinates.txt" has 3 values: lat/long/importance respectively. Note that the addition of further values inside the "coordinates.txt" doesn't change the way in which the Perl constructors deal with the CMODs, since the split function wasn't set to reckon it. One can continue to use the CMODtracer as usual. It's just in the case of "coordinate's picking" which they assumes relevance.
Once the "coordinates.txt" is full of points and Importance(s), the new "mylocs.pl" is able to process them by assigning only one name for the several Importance(s). In this way the same geo-name has just high Importance's value for big areas and just low Importance for small areas of the map. This procedure can be improved either with a further Lua textbox in which to display the Importance itself, or with a PNG centered on screen and made like a submarine's periscope.
Note that if to the Perl split function is assigned also the third value, it should be the Z value whether in the Lua module is disabled the Importance's computation and is left instead just the distance. Centered on an object, one could make 3D objects when tasselated. A discussion about the triangle tasselation of XYZ dataset is here:
http://forum.celestialmatters.org/viewtopic.php?t=337

However, 2 screenshots of the new "mylocs.pl" script.



The front-end, the help.



The Menu Options.

The options should be pretty selfexplanatories; Option 4 is the option which perform the discourse above.
The default Importance is customizable in the first part of the script, in which there are the location's directives.
Option 2, together with the manual name, it assign also the manual Importance.
With the option rename one can save with another name the "mylocs.ssc" for making another (in the same time the original will be cleaned up.
The script avoid the double entering of the precedent versions and is less error prone. The options can be interactives. Now the letter "#" is used to return to the menu in whichever step.
Importance values and distances are easy individuables in first part of "cmod_tracer.lua" and the function as well.
Being experimental, one could to add its distance/Importance parameters in more quantity; if more values are added, let's add also the relevant conditionals to the function.

For Windows users the "mylocs.pl" is shipped also as batch file. For making batch files of the Perl scripts
type within the Win cmd: pl2bat "yourfile.pl" "yourfile.bat" (without quotes) then enter

Zip:http://marauder.webng.com/files/cmod_tracer_2.0_sp1.zip (8kb)
3 files: "cmod_tracer.lua", "mylocs.pl", "mylocs.bat". Backup the previous, first.

Updated the link above. Was wrong.

Submarine attack!!!



The space amongst Importance(s) is proportional, so I must use the small font. Note the hypen how is a bit more narrow amongst 20 and 12 (20-12 = 8 ) respect to 20 and 30 (30-20=10). I've omitted the min. value 8 because its sovrapposition with the previous 12 (12-8=4 fontspacing, too small).
Recapitulating:
The big areas, which can be pick up from space, will have always the max. value and the arrival on the soil always the min. (customizables). The aperture acts like a ruler for features.

P.S.
These meters have a name in the navy realm, but their english translation is no matter for me here.

- Added the "metertracer"'s colors shifting from customizable non-zero bright to dark zero accordingly with the phase angle; this prevent the light's blending saturation when the object toggle over Sun's hit zones.

EDIT LATER:
The metertracer will be active from within the CMODtracer toolbar; no further entry into "config.lua".

This workaround allows the normal font also for Importance 1. I've posit them in such a way in order to make a target area. Now is shown also the relevant distance. All these parameters are customizable.







BTW,
does someone knows a good way to convert fonts in txf? Here on the forum I had found a link to a converter no longer available, though.

- Removed exceeding customization's parameters. Left just the superior limit, in order to show the marker, now drawn in GL. (otherwise should be "out of screen"). All calculus are done with the default start.cel parameters.

Here the Importance = (sqrt(2 * d^2))/100; and the marker's diagonal is the visual diameter for features. The variable function, is within a separate module, so one can change it as he wish without to dig into the main interface module.


for such visual screen area (at such distance) 146 is the Importance for features' diagonal wide.
.

for such visual screen area (at such distance), 60 is the Importance for features' diagonal wide.


for such visual screen area (at such distance) 11 is the Importance for features' diagonal wide.

Hope the concept be clear. The Importance now are no longer assigned, but computed automatically; although math.floor(ized). I've made this for resolving my personal issues with a map, but the square GL marker could be used also for other purposes: cockpits, comparison star/planet etc. Being fillable with image textures, it could be used to load the relevant VT tiles on which insist the marker pointer through a table in which is taken into account the long/lat quadrants of the splitted tiles, in order to make some sort of magnifying glass.

- Added small console log;
- minor fixes;



Colors are customizables. Note that marker and text will be black when inside the phase angle range. Check the "config_cmod_tracer.lua" to set your custom phase angle.
Zip here:
http://marauder.webng.com/files/cmod_tracer_2.0_testmark.zip (8 kb)
3 files: "config_cmod_tracer.lua", "cmod_tracer.lua", "metertracer.png". Backup the previous. The png must be placed in ../icons".

BTW, I've finally compiled the qttxf dir, and the converter works; now to make new fonts is no longer a problem.

CMODtracer 2.0.1



This version collects all the improvements after v. 2.0 previously scattered within the topic.

Changes:
- new restyling; icons' background is now transparent;
- added metertracer's icon;
- added improved "mylocs.pl"/"mylocs.bat" scripts;
- added console log;
- minor fixes;
- rebuilt the PDF manual.



Zip here (496 kb)

The Perl script below converts the "coordinates.txt" data file into point sprites CMOD mesh. Color, texture and pointsize atributes are user-defined parameters: do set it like you wish and save the script.
USAGE:
in Perl console do type: "coords2sprites.pl < coordinates.txt" (without quotes, then ENTER).
in Windows command (MS-Prompt): "perl coords2sprites.pl < coordinates.txt" (without quotes, then ENTER).

NOTE:
The CMOD will have its invisible placeholder.
The "pointsize" attributes is now set for showing point sprites suited for the Earth object's radius like here. This is a somewhat empiric value and a bit "taste related": for object's radius lesser than Earth its value must be lowered, while for object's radius bigger than Earth its value "ought to be" raised. In short: "how the sprites looks" is a choice parameter. The script doesn't write the relevant .SSC file. This latter job is left to the user.

In the previous post has been shown the method to get point sprites with the placeholder. This method is suited for points which needs to be wrapped around a spherical object, since the points are constrained onto the spherical surface of the placeholder. In this way, once set forth the suited pointsize, the CMOD's mesh radius is conform to the object's radius, if only with the former having a bit more great radius in order to avoid the "sink" of the blob texture beneath the object's surface. All that is managed by the usual SSC specification:


However, this method isn't suited for sprites which must be "free" in their position, for example whether few sprites needs to light up starbases' windows or starship' engines, because such 3D model's positions aren't wrapped onto the spherical surfaces, but usually are "inside" their "virtual" spheres (the planetographic grid shows the concept). Thus, the placeholder must be removed, and every single point must be precessed standalone, like single CMOD. The collection of each CMOD is then specified by the SSC' directives below:

Unfortunately, this method needs that each point sprite must undertake a trial-and-error task to find its right "FixedPosition" on the 3D model, due to the 3D model's "Planetographic" coordinates.
One thing must be noted: diversely from setting forth a generic point sprite and then finding its lat,long,alt position on the 3D model, the picking with the CMODtracer always get their lat and long whatever be their altitude; at least whether the picking is well centered on the target; since the projection follows the radius. Thus, it is matter of specifing only the altitude within the SSC, since the lat and long are thats which are written into the "coordinates.txt" and they can bring from.
The altitudes can be negatives respect to the "wrapping" surface, to insert the sprites in their suited positions: i.e. a sprite which light up a starbase's window.

The zip below get the sprites from "coordinats.txt" without the placeholder. Be sure that each CMOD be renamed before processing the next picked up point.