Final Thoughts

There are a few other projects that leverage Xplanet.  I’ve already discussed one of them, TotalMarker, and its ability to provide real time context to Xplanet’s rendering.  Another project is xplanetFX, developed by Markus Schmidt for Linux environments, which manipulates the Xplanet rendering with lighting effects.

Just for fun, I wanted to see if I can get TotalMarker and xplanetFX running locally on my Intel Mac and also add some information for running Xplanet on secondary displays.

xplanetFX

Run xplanetFX on Mac OS X

Due to a policy change the Homebrew maintainers implemented, I’m now hosting the xplanetFX formula on my personal tap.

Furthermore, Homebrew is incrementally updating formulae that depend on OpenSSL which has been upgraded from 1.0 to 1.1.  Formulae that depend on OpenSSL must use the same version.  Currently, only one of xplanetFX’s dependencies, wget, requires OpenSSL 1.1.  If there exist any other dependencies, then you will have to change the wget dependency from 1.1 to 1.0.

*** – with the beta build of macOS 10.14 Mojave, imagemagick cannot install so xplanetFX does not yet install.

brew tap blogabe/xplanetfx
### if you have other Homebrew dependencies that still use OpenSSL 1.0
### update wget.rb and edit the OpenSSL dependency from "openssl@1.1" to "openssl"
brew install xplanetfx
xplanetFX --gui

xplanetFX is a collection of scripts rather than a compiled binary.  The scripts utilize command line binaries like Xplanet, ImageMagick, wget (which Apple no longer includes with OS X), date, and sed.  While Apple does ship with date and sed, they differ from the GNU versions the xplanetFX scripts are built around.

The above install command will install xplanetFX, the optimal dependencies to provide like-for-like experience with the original Linux version, and will set the environment variables automatically.

Display Xplanet Image on Secondary Screens

Let’s use Rogan and Hari’s comments at the bottom of the Scripts page to save the Xplanet renderings and display them to either your primary or non-primary screens.  There are two ways to go about this.  One would be, per the comments, to delete the last image before Xplanet updates.  The other would be to save the images in an output directory and symbolically link to the most current image.  I’m going to show the latter because, to me, if you’re going to go through the trouble outputting the file and saving it somewhere, you might want to animate the images using mencoder.  This way will obviously take up a lot more disk space – ~2 GB / wk assuming continuous five minute updates – so you’ll want to delete files older than, say, 36 hours.

We need to create two output directories: one to store the Xplanet images, and the other to store the symbolic link for OS X to reference.  We’ll need a set of these directories for each monitor we want to draw to (let’s assume three with varying ratios).

cd ~/.xplanet/personal
mkdir output/display1-1920x1080 output/display2-1920x1080 output/display3-1680x1050
mkdir ~/Pictures/XplanetDesktop1 ~/Pictures/XplanetDesktop2 ~/Pictures/XplanetDesktop3

It’s probably a good idea to edit the definitions file as well and specify the geometry of each screen.

...
XPLANET_GEOMETRY1=1920x1080
XPLANET_GEOMETRY2=1920x1080
XPLANET_GEOMETRY3=1680x1050
...

Next up is to change the Xplanet startup in the xplanet.sh script.  You’ll probably want to add some logic to use a different config file or different command line options.

if [[ ${SWITCH} == 'start' ]]; then
SCREEN=$2
SCREEN_TEMP=XPLANET_GEOMETRY${SCREEN}
SCREEN_GEO=${!SCREEN_TEMP}
OUTPUT=Screen${SCREEN}-${SCREEN_GEO}-$(date +"%Y%m%d.%H.%M.%S").png
  /usr/local/bin/xplanet \
    -searchdir=${XPLANET_HOME} \
    -config=config \
    -projection=${XPLANET_PROJECTION} \
    -longitude=${XPLANET_LONGITUDE} \
    -labelpos=+10-45 \
    -date_format="%D at %r" \
    -color=green2 \
    -geometry=${SCREEN_GEO} \
    -output=output/display${SCREEN}-${SCREEN_GEO}/${OUTPUT} \
    -num_times=1

  find output/display${SCREEN}-${SCREEN_GEO}/ -mtime +36h -delete
  rm ~/Pictures/XplanetDesktop${SCREEN}/*.png
  ln -s output/display${SCREEN}-${SCREEN_GEO}/${OUTPUT} ~/Pictures/XplanetDesktop${SCREEN}/${OUTPUT}

  echo "$(date): Xplanet ran for display ${SCREEN}"
fi

To automate this, we’ll need to copy the local.xplanet.start.plist file for each screen, e.g., local.xplanet.start1.plist, local.xplanet.start2.plist, and local.xplanet.start3.plist and make some minor changes.  Be sure to change the Label key as well.  It’s not below, but it is imperative the Label and file name match.

ORIGINAL PLIST:
...
<key>ProgramArguments</key>
<array>
  <string>./personal/scripts/xplanet.sh</string>
  <string>start</string>
</array>

<key>RunAtLoad</key>
<true/>
...

NEW PLIST:
...
<key>ProgramArguments</key>
<array>
  <string>./personal/scripts/xplanet.sh</string?
  <string>start</string>
  <string>[DISPLAY # - MUST MATCH NUMBER USED IN PLIST]</string>
</array>

<key>StartInterval</key>
<integer>300</integer>
...

Last step is to open up Desktop & Screen Saver in OS X System Preferences.  For each display, point to the respective directory holding the symbolic link under ~/Pictures, and change the background setting to 5 minutes.  You can do this not just for the physical displays, but also for the individual OS X spaces within each physical display (where one screen can house multiple virtual desktops).

Making a Movie

And a little something extra.  Let’s create a movie using mencoder.

brew install mplayer
cd ~/.xplanet/output/[specific display sub-folder]
ls *.png > stills.txt
mencoder mf://@stills.txt -nosound -ovc lavc -lavcopts \
  vcodec=mpeg4:aspect=16/9:vbitrate=8000000 -vf scale=1920:1080 \
  -o xplanet.avi -mf type=png:fps=24

This will output two hours worth of 5 minute stills each second – 24 frames per second – so a movie showing one day’s worth of renderings taken every 5 minutes will be 12 seconds long.

Run TotalMarker Locally Using the Windows Executable and WINE

Remember that the Mac version of TotalMarker is built for PowerPC processors or an Intel processor running OS X 10.6 or earlier.  This list of steps is to get the Windows version of TotalMarker to run on an Intel processor running OS X 10.7 or greater.  Download the Windows executable from the wizabit website and place it in your Xplanet home directory, e.g., ~/.xplanet.

Since we used Homebrew to install Xplanet and the necessary graphic packages, go ahead and use Homebrew to install Wine.  Wine, a binary designed for GNU/Linux environments prefers to be compiled using GNU GCC, not LLVM/Clang GCC which Apple now ships with OS X.  Wine also depends on universal – PowerPC and Intel – builds of image libraries.  The binaries Homebrew compiles are by default set to compile for Intel only.

The first few steps are to install GNU GCC and re-install Wine’s dependencies as universal builds.

brew tap homebrew/dupes
brew install apple-gcc42
brew rm $(brew deps wine)
brew install $(brew deps wine) --universal
brew install wine --cc=gcc-4.2
cd ~/.xplanet
mkdir config markers arcs satellites images
wine Totalmarker.exe

Wine will create a ~/.wine directory the first time you run it.  Totalmarker.exe will create two files in the config sub-directory: totalmarker.dat and totalmarker.ini.  As I write this, however, there is something that precludes the creation of these two files.  You can download these two files here and place them in ~/.xplanet/config.  Re-run “wine Totalmarker.exe“.  Follow the instructions available on the wizabit website as to how to use TotalMarker.  You can now run TotalMarker locally on your machine using the Windows executable to update the marker files instead of downloading them directly from the wizabit.

 

2 Responses to Final Thoughts

  1. Ziuve says:

    Something is still wrong:
    blogabe/xplanetfx/xplanetfx contains conflicting version recursive dependencies:
    openssl@1.1, openssl

    • Xplanet Blog says:

      Yes. Homebrew seems to be transitioning carefully from OpenSSL 1.0.x to 1.1, but wget was an exception and is already using the newer version. This is causing conflicts with installing xplanetFX since it has other dependencies that themselves require the older version of OpenSSL. I can confirm I can get xplanetFX to work by manually changing the OpenSSL dependency back to the older version, i.e., edit `openssl@1.1` to `openssl`. I have this working on 10.12 as well as 10.13 Beta.

Leave a Reply

Your email address will not be published. Required fields are marked *