Skip to content
Snippets Groups Projects
Commit d13071af authored by slevy's avatar slevy
Browse files

Assorted updates, including warp command.

parent a417b028
No related branches found
No related tags found
No related merge requests found
......@@ -31,6 +31,9 @@
<!--
$Log$
Revision 1.25 2010/04/27 23:44:49 slevy
Assorted updates, including warp command.
Revision 1.24 2005/02/16 13:52:36 pteuben
added some FC3 comments
......@@ -48,7 +51,7 @@
Describe thresh, only=/only-/only+, see and sel commands.
But really need a separate section about how selection sets should work.
(Maybe writing the section will make it clear how they *should* work.)
Add "thresh" example. Look at stellar distribution by B-V -- the Orion
Add "thresh" example. Look at stellar distribution by B-V - the Orion
spur really does show up in blue!
Describe transform syntax including "tfm camera", making multiplication
......@@ -64,7 +67,7 @@
<title> Partiview (PC-VirDir)
<author> Peter Teuben, Stuart Levy
<date> 15 February 2005
<date> 27 April 2010
<abstract>
......@@ -86,51 +89,19 @@ of partiview.
<sect> Installation
<p>
This assumes you have the post-July 2001 release (version 0.6 or later) of
<bf/partiview/, not the earlier "<bf/gview/" release that was described
in earlier versions of this document. We keep copies of some Linux support
files (Mesa, FLTK) on our current
<htmlurl url="http://www.astro.umd.edu/nemo/amnh"
name="http://www.astro.umd.edu/nemo/amnh"> website. Although
more current versions of support libraries may be available, they
may not have been tested out. This release has been tried on
Linux (red hat 6.2, 7.1, 7.2), Irix and Windows. Additional comments
were added how to compile and run under a more modern version of
redhat,e.g. Fedora Core 3.
This release has been tried on Linux (Fedora, Ubuntu, etc.), Mac OS X, Irix and Windows.
<p>
partiview needs two libraries to compile: OpenGL (or MESA) for the
drawing operations, and FLTK for the graphical user interface.
These libraries are known to work on MS-Windows as well as many Unix flavors.
Newer version of X-windows (notably xorg-x11-Mesa) also work.
<sect1> MESA/OpenGL
<sect1> OpenGL (possibly via Mesa)
<p>
First make sure <tt/Mesa/ is installed, for <tt/redhat6.2/
there are rpm files available. For <tt/redhat7.1+/ they
are now included in the basic distribution.
Check if you have something like the following (version numbers may be different):
<tscreen><code>
% rpm -qa | grep Mesa
Mesa-3.2-2
Mesa-devel-3.2-2
else:
% rpm -i Mesa-3.2-2.i686.rpm Mesa-devel-3.2-2.i686.rpm
for Fedora Core 3 you will need
xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21
xorg-x11-Mesa-libGL-6.8.1-12.FC3.21
or variations thereof. This particular version worked for FC3.
</code></tscreen>
You should have both installed. Some packages will use <tt/libMesaGL/, others
<tt/libGL/. Our <tt/configure/ script (see below)
should take care of the two possible options.
Most platforms will have it installed already, whether as libMesaGL or libGL.
Our <tt/configure/ script (see below)
should take care of the two possible options.
<p>
Homepage: <htmlurl url="http://mesa3d.sourceforge.net/"
name="http://mesa3d.sourceforge.net/">
......@@ -138,16 +109,14 @@ or variations thereof. This particular version worked for FC3.
<p>
Redhat packages: (part of powertools I believe)
<P> Mesa3D is under continuous development. As of this writing the
stable release is 4.0.1, but it has not been tested with the current partiview release.
Redhat 7.1 comes with Mesa-3.4 and also works with partiview.
You can also use a CVS release of Mesa.
<sect1> FLTK
<p>
Also make sure <tt/FLTK/ is installed. If you got our version, do this (as
root)
Also make sure <tt/FLTK/ is installed, from fltk.org.
FLTK versions 1.1.x (e.g. 1.1.7, 1.1.9, ...) work.
FLTK 2 will not work with partiview.
If you're not sure whether you already have it, try
<tscreen><code>
% locate libfltk.a
......@@ -155,71 +124,23 @@ You can also use a CVS release of Mesa.
if they fail, then
% cd <where-ever>/fltk-1.0.9
% cd &lt;where-ever&gt;/fltk-1.1.9
% make install
</code></tscreen>
(you only need it if you want to recompile the program at some point,
not if you just want to run it)
(you only need it if you want to recompile partiview at some point,
not if you just want to run it, since FLTK is built-in to partiview binaries.)
<p>
Homepage: <htmlurl url="http://www.fltk.org/"
name="http://www.fltk.org/">
<p>
Redhat packages: <htmlurl url="http://www.cs.cornell.edu/nogin/RPM/fltk-devel.html"
name="http://www.cs.cornell.edu/nogin/RPM/fltk-devel.html">
<p>
Find rpms: <htmlurl url="http://rpmfind.net"
name="http://rpmfind.net">
<P> FLTK is under continuous development. Versions from 1.0.9 through
1.1.0rc3 have been successfully tested with partiview. Some problems
with other versions exist, but 1.1.4 is also known to work. The upcoming 2.0
version of FLTK is unlikely to work with partiview.
<p> A more recent example with which partiview was compiled was fltk 1.1.4. On
Fedora Core 3 this is available as RPM in the fedora-extras repository.
The following 3 rpm's were needed and lead to a successfull compile:
<tscreen><code>
fltk-1.1.4-8
fltk-fluid-1.1.4-8
fltk-devel-1.1.4-8
and use
--with-fltk=/usr
in the configure step of building partiview (see below)
</code></tscreen>
<!-- therefore we don't want to mention this now, right? -slevy
Here is an example of getting a CVS version of FLTK and installing it in your
alternate installation tree /opt:
{tscreen}{code}
% cvs -d :pserver:anonymous@cvs.fltk.sourceforge.net:/cvsroot/fltk co fltk
% cd fltk
% configure {-}-prefix=/opt/lib
% setenv LD_LIBRARY_PATH `pwd`/lib
% make
% make install
{/code}{/tscreen}
Note that fltk uses .h and .H files, and installing does not fix these problems.
--><tscreen><code>
% tar zxf partiview-0.6.tar.gz
% cd partiview-0.6/src
% make clean (if you really must compile a new executable)
% ./configure (GNU autoconf toolset to ease installation)
% make depend (might need to make new local dependancies)
% make partiview (should not have to edit Makefile anymore)
</code></tscreen>
<P> FLTK is under continuous development. Versions from 1.1.1 through
1.1.9 have been successfully tested with partiview. Some problems
with other versions exist, but 1.1.4 is also known to work.
<sect1> partiview
......@@ -252,17 +173,19 @@ value is taken from environment variable STARLAB_PATH if that is set.
<sect1> CVS
<p>
Since version 0.5 <tt/partiview/ is under CVS control, and occasionally we
will stamp out a new release when we deem it stable. Anonymous or read-only
CVS access is also offered. Currently the CVS repository machine is
<tt/cvs.astro.umd.edu/ and you will need to setup your developers account with
Peter (<tt/teuben@astro.umd.edu/). Here's a sample session with some commonly
used CVS commands:
The current source code of <tt/partiview/ is always available from CVS,
with public anonymous read-only access. Occasionally we stamp out a
packaged release, too, but looking to CVS is best.
(Partiview developers can request a non-anonymous CVS account
from Peter Teuben -- <tt/teuben@astro.umd.edu/.)
Currently the CVS repository machine is <tt/cvs.astro.umd.edu/.
Here's a sample session with some commonly used CVS commands:
<tscreen><code>
setenv CVSROOT :pserver:anonymous@cvs.astro.umd.edu:/home/cvsroot
setenv CVSEDITOR emacs
setenv CVS_RSH ssh (not needed for pserver access though)
cvs login (only needed once, and only for pserver type access)
......@@ -273,7 +196,8 @@ used CVS commands:
cvs update # if so, update your sandbox and/or resolve conflicts
cd partiview/src # goto the 'src' directory of partiview
./configure
./configure --with-fltk=/some/where/fltk-1.1.something/ ...
emacs partibrains.c # edit some files
make all # compile the program
./partiview # test the program
......@@ -321,10 +245,6 @@ To compile with MinGW and company, you'll need to:
UNIX-like tools. All three packages are available at:
<htmlurl url="http://www.sourceforge.net/projects/mingw/"
name="http://www.sourceforge.net/projects/mingw/">
Recent releases of w32api include MinGW versions of OpenGL
libraries and headers, which partiview needs.
As of June 2002, current versions seem to be <tt/mingw-1.0.1-20010726,
w32api-1.4-2, and MSYS-1.0.7/.
Unpack the .zip or .tar archives of MinGW and w32api;
both packages are intended to live in the same directory.
The MSYS package comes as a self-extracting archive and
......@@ -341,7 +261,8 @@ or the analogous setting of PATH using (on WinNT/2000 at least)
<tt/My Computer -> Control Panel -> System -> Environment/
to make a permanent change to PATH.
<item> Build FLTK using MinGW. Unpack its source distribution and say
<item> Use MinGW to build FLTK. (FLTK 1.1.x, e.g. 1.1.9, works with partiview. FLTK 2.0 won't work.
Not sure about versions in between.) Unpack the FLTK source distribution and say
<tscreen><verb>
sh configure
make
......@@ -390,16 +311,16 @@ to make a permanent change to PATH.
with forward- instead of backslashes and a /<it/drive-letter/ prefix.
Also, if typing to a Windows command-window, shell scripts like
<tt>configure</tt> must be explicitly fed to <tt>sh</tt>.
Thus for example if FLTK is installed in <tt>C:\util\fltk-1.1.0</tt>
Thus for example if FLTK is installed in <tt>C:\util\fltk-1.1.9</tt>
and Starlab is in <tt>F:\src\starlab</tt>, then you might build
partiview by typing
<tscreen><verb>
sh configure --with-fltk=/c/util/fltk-1.1.0 --with-kira=/f/src/starlab
sh configure --with-fltk=/c/util/fltk-1.1.9 --with-kira=/f/src/starlab
make
</verb></tscreen>
Note there's no need to specify the location of the OpenGL or other
libraries; the configure script and MinGW tools already know
where to find them.
where to find those. Omit the "--with-kira=..." if you're not using Starlab.
</enum>
......@@ -407,7 +328,7 @@ to make a permanent change to PATH.
<sect> Directory structure
<p>
Here is the directory structure, as per version 0.1:
Here is the directory structure:
<p>
<tscreen><verb>
......@@ -415,10 +336,10 @@ Here is the directory structure, as per version 0.1:
partiview/src source code
partiview/data sample datafiles (e.g. Hipparcos Bright Star Catalogue)
partiview/doc manual (sgml, and derived html, txt, ps/dvi)
partiview/scripts various useful scripts (calculator, moviemaker, etc.)
partiview/nemo NEMO specific converters/code
partiview/starlab STARLAB specific converters/code
partiview/tutor examples of tutorial type code (added in 0.2)
partiview/windows windows executables/support (old)
</verb></tscreen>
......@@ -781,16 +702,29 @@ or its complement with
<p>
There are two types of commands in <tt/partiview/:
Control Commands and Data Commands.
Probably the most important difference between the two is that Control
Commands return feedback to the user, whereas Data Commands
are interpreted without comment. The command window expects
to receive Control Commands. However, it is possible to
enter a Data Command where a Control Command is expected,
using the <tt/add/ command prefix. Likewise, a Control Command
may be given where data is expected, using the <tt/eval/ prefix,
e.g. in a data (or .cf) file. The <tt/real/ (Control) Command expects
data commands, but if Control Commands are needed, they need to be preceded
with the <tt/eval/ command. See also the previous <bf/starlab/ example.
Probably the most visible difference between the two is that every Control
Command returns feedback to the user, whereas Data Commands
are interpreted without comment unless an error occurs.
Some situations, e.g. the command-entry text box, expect to receive
Control Commands; others, e.g. files (.cf, .speck, etc.) named on
the command line or specified by <tt/read/ or <tt/include/ commands,
are expected to contain Data Commands.
However, it is always possible to enter a Data Command
where a Control Command is expected,
using the <tt/add/ command prefix, e.g. you could type in the text box:
<tscreen><code>
add 0 0 0 text The Origin
</code></tscreen>. Likewise, a Control Command
may be given where data is expected, as in a data or .cf file,
using the <tt/eval/ prefix:
<tscreen><code>
1 0 0 text X=1
eval bgcolor 0.3 0.2 0.1
</code></tscreen>
See also the previous <bf/starlab/ example.
<p>
......@@ -1148,11 +1082,15 @@ Frame number <it/FRAMENO/ (default 0) increments with each snapshot taken.
<p>
<tag>
snapshot [<it/FRAMENO/]
snapshot [<it/FRAMENO/ | <it/FILENAME/]
</tag>
Capture a snapshot image of the current view.
Use <tt/snapset/ to specify the output image name.
Default format is <tt/snap.%03d.tif/.
Either give <tt/snapshot/ an explicit filename,
or else specify a file format string with <tt/snapset/
and then let <tt/snapshot/ fill in the frame number.
With neither <it/FRAMENO/ nor <it/FILENAME/,
<tt/snapset/ adds one to the previous frame number.
<tt/Partiview/ generally invokes the ImageMagick program <tt/convert(1)/,
which must be installed and be on the user's $PATH. <tt/Convert/ determines
......@@ -1221,20 +1159,36 @@ pointsize
-->
<tag>
polysize [on|off] [a|s|r]
poly [on|off]
</tag>
Display polygons, or don't.
<tag>
polylum
polysize [<it/scalefactor/]
</tag>
Multiplier for polygon size. Default is zero (!), so you must
set polysize to something else before polygons will show up.
<tag>
polyminpixels
polylumvar [<it/attrname/ | <tt/point-size/] [<tt/area/ | <tt/radius/]
</tag>
Choose which attribute determines the radius of a particle's polygon.
By default, it is <tt/point-size/, a pseudo-attribute which varies with
the brightness of points (so adjusting the slum slider scales polygons too).
Each polygon's 3-D radius is the <tt/polysize/ <it/scalefactor/ times its particle's
given attribute (whether an actual particle attribute or <tt/point-size/). Or,
if the <tt/area/ keyword is specified, then the radius is the square root
of attribute * scalefactor. <tt/area/ is useful if the attribute represents
a luminosity; in that case, the polygon total brightness (which is proportional
to its screen area) becomes proportional to the attribute / distance^2.
<tag>
polymin <it/minradius/ [<it/maxradius/]
</tag>
Specify a minimum screen radius for polygons, in pixels.
If smaller than this, they are not drawn.
<tag>
color
......@@ -1313,16 +1267,20 @@ at which apparent brightness should match that in the 1/r^2 modes --
a distance to a "typical" particle.
<tag>
labelminpixels
labelmin <it/minpixels/
</tag>
Labels computed to be smaller than this screen size (pixels) are suppressed.
<tag>
labelsize
labelsize <it/scalefactor/
</tag>
<tag>
lsize
lsize <it/scalefactor/
</tag>
lsize (alias labelsize) sets the 3-D height of labels. If the text was created with a
<tt/text -size /<it/textsize/ option, the scalefactor is multiplied by that to determine
the 3-D size.
<tag>
point[s] [on|off]
......@@ -1366,7 +1324,7 @@ Report setting of <tt/texturevar/ data-command, which see.
laxes [on|off]
</tag>
Toggle label axes. When on, and when labels are displayed,
shows a
shows a set of red/green/blue (X/Y/Z) axes to indicate orientation.
<tag>
polyside(s)
......@@ -1376,7 +1334,7 @@ polygons. For textured polygons, <tt/polysides 4/ might do as well,
and be slightly speedier.
<tag>
fast
fast [on|off]
</tag>
see also <tt/ptsize/
......@@ -1507,6 +1465,12 @@ All particle attributes (not positions though)
are written to a <it/dump-filename/. Useful for debugging.
Warning: it will happily overwrite an existing file with that name.
<tag>
warp [on|off]
</tag>
Enable, disable, or report the status of any <tt/warp/ data-command set up for the current group.
If it exists, particles's positions can change with time, in a handful of canned ways
built into the <tt/warp/ command. See the <tt/warp/ entry under Data Commands.
</descrip>
......@@ -1776,14 +1740,15 @@ read a <tt/speck/ formatted file.
<tag>
ieee [-t time] <it/file/
</tag>
read a IEEEIO formatted file, with optional timestep number (0 based).
Read a IEEEIO formatted file, with optional timestep number (0 based).
Support for this type of data must be explicitly compiled into the program.
<tag>
kira <it/file/
</tag>
read a <tt/kira/ formatted file. See the <tt/kiractl/ Control
Command to modify the looks of the objects.
Command to modify the looks of the objects. Only present if Starlab is compiled
into partiview.
<tag>
setenv name value
......@@ -2098,6 +2063,71 @@ datatime <it/time/
</tag>
Label subsequent data with this <it/time/ (a non-negative integer).
<tag>
warp
</tag>
When 'warp' has been defined for a group,
all its particles get their positions (re)computed according to
(a) the warp data-command's parameters, (b) the current time, (c) the particle's
initial position, and (d) maybe some attributes of each particle.
There are several (mutually exclusive) kinds of warping available:
<itemize>
<item> for doing a sort of differential rotation for disk-like galaxies;
<item> for doing N-D to 3-D projection, where particle positions are replaced with
(time-independent) linear combinations of attribute values;
<item> linear or polynomial extrapolation of the particle position with time,
with coefficients specified as triples of attributes
</itemize>
Options to <tt/warp/ data command:
<descrip>
<tag>-p period0[f|s]</tag>
"Rotation period". Sets timescale of motion, in frames (f) or seconds (s).
<tag>-extrap coef0[,degree]]</tag>
Extrapolate position with time. Velocity is given by attribute coef0 and the two attributes following it
(coef0 .. coef0+2), in the sense p = p_0 + [coef0 .. coef0+2] * (time/period0).
If <it/degree/ given (default 1), uses 3*<it/degree/ attributes as polynomial coefficients, as
p=p0+(t/period0)*field[coef0..coef0+2]+(t/period0)^2*[coef0+3..coef0+5]+...
<tag>-sheet ampl,xlength,zlength</tag>
For disk galaxy style: Applies exponential sheet warp for disk lying in the X-Z plane.
Scale set by xlength and zlength, Y-displacement set by ampl.
<tag>-f fin,fout</tag>
For disk-galaxy style: gives time range over which warp applies.
<tag>-z zerotime</tag>
For disk galaxy style: sets time at which particles are in their original positions.
<tag>-R rot[,drot]</tag>
Disk galaxy style: Add constant to rotation angle.
<tag>-T o2d</tag>
Provide object-to-disk coordinate transform (in "disk" coordinates, the disk lies in X-Z plane).
9 or 16 numbers.
</tag>-F d2o</tag>
Provide disk-to-object transform. 9 or 16 numbers.
<tag>-r rcore[,transition][w]</tag>
Disk galaxy style: set radius of rigidly-rotating inner region, and transition to constant-velocity region
<tag>-fix x,y,z[w]|radius[w]</tag>
Disk galaxy style: Keep the given 3-D point, or a point at the given disk radius, fixed.
E.g. track the sun.
<tag>-galaxy gorbcoef0</tag>
Special disk galaxy style. Each star is on its own disk-galaxy-like orbit,
with 8 orbital parameters given by 8 consecutive attributes starting with gorbcoef0.
See galaxyorbit.h (read the source).
<tag>-ride speckno</tag>
Ride along with speckno'th particle in first loaded group (displace particles by the difference
between their computed orbit position and the ridden-on particle).
<tag>
<it/Xpos Ypos Zpos Var0 .... /
</tag>
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment