Revision: 69934
http://sourceforge.net/p/brlcad/code/69934
Author: starseeker
Date: 2017-06-28 13:34:39 +0000 (Wed, 28 Jun 2017)
Log Message:
-----------
Remove a few .txt doc files which look to be well and truly obsolete...
Removed Paths:
-------------
brlcad/trunk/doc/anim.txt
brlcad/trunk/doc/sun.txt
brlcad/trunk/doc/tube.txt
Deleted: brlcad/trunk/doc/anim.txt
===================================================================
--- brlcad/trunk/doc/anim.txt 2017-06-22 18:20:35 UTC (rev 69933)
+++ brlcad/trunk/doc/anim.txt 2017-06-28 13:34:39 UTC (rev 69934)
@@ -1,145 +0,0 @@
-Date: Fri, 30 Oct 87 3:58:14 EST
-From: Phil Dykstra <p...@brl.arpa>
-Subject: Re: Animation querry.
-
-I have been meaning to put a few notes together about animation in
-BRL-CAD for some time now. Your message presses the point so here's
-a really quick basic overview. Note that animation control is
-still very early and experimental. Don't be surprised if much of
-it changes in the future.
-------
-
-The earliest form of animation was just changing the viewpoint.
-So that RT could ray trace the "current" MGED view, a -M flag was
-added which tells RT to read the viewing matrix from stdin.
-This matrix is written on six lines in the form:
-
-viewsize
-xpos ypos zpos
-[4x4 rotation matrix, 4 elements per line]
-
-Such data can be saved along with an RT shell script by the "saveview"
-command in MGED. To get just this data (i.e. without the shell script),
-the "savekey" command can be used. Thus one can save a string of
-viewpoint keyframes via "savekey." ["Times" can also be added to
-the keyframes for the purposes of some interpolation programs.]
-
-Several tools were written (not in the distribution) which generate
-sequences of such views, interpolate a set a keyframes, etc.
-
-The "rmats" command was added to allow a file of these views to be
-read in to MGED so you could watch the keyframes go by. Feeding the
-same data to RT (via the -M flag) computes an image for each view.
-The views either go to the frame buffer, or if an output filename
-is given, they go into files with frame number suffixes.
-
-Animation previews are typically made via low resolution ray traces,
-composited into one large image via "pixtile," and viewed on a frame
-buffer via "fbanim" (preferably one with hardware pan and zoom).
-
-Later we wished to articulate the models themselves, so a command
-script language was created for RT. These are also fed to RT
-via the -M flag. RT figures out whether it is given the old form
-above or a real script. An animation description script contains
-transformation matrices to be applied to the model tree. A simple
-one might look like:
-
-start 42;
-clean;
-anim frob/nitz matrix rmul
- 1 0 0 1
- 0 1 0 2
- 0 0 1 0
- 0 0 0 0;
-end;
-etc.
-
-start - says to start frame number 42.
-clean - make RT clean up after itself (this may not be needed any more...).
-anim - says to apply an matrix animation to the arc connecting frob to
- nitz. The type of matrix operation is a right multiply (choices
- include right or left multiply, replace, or reroot (i.e. world
- coordinates)).
-end - tells it to go ahead and shoot this frame.
-
-Eventually there will be things besides "matrix" animations to allow
-material properties etc. to be animated.
-
-Various outboard tools generate motions, merge animation scripts
-together, allow the previewing/editing of motions, etc. For the
-most part these tools are sufficiently ad hoc and experimental
-that we aren't giving any of them away yet. Next year some time....
-
--------
-I didn't explain any of it in much detail, but hopefully it
-gives you an overview. One of these days we will write some
-more about it - like when we start including some motion tools.
-
-==============================
-Date: Fri, 30 Oct 87 16:42:14 EST
-From: Phil Dykstra <p...@brl.arpa>
-Subject: Re: Animation querry.
-
-Here's a bit more about the matrix operations available in RT
-animation scripts.
------
-
-RT Matrix Animation Operations:
-==============================
-
-In BRL-CAD, matrices are handled in their usual mathematical form
-(the transpose of the Newman and Sproull "computer graphics form").
-That is, a matrix looks like this:
-
- r1 r2 r3 dx
- r4 r5 r6 dy
- r7 r8 r9 dz
- 0 0 0 1/s
-
-Points are *column* vectors, so a point is transformed by:
-
- newpoint = Matrix * oldpoint;
-
-Thus the world coordinate system is on the "left" end of a stack of
-matrix operations; the local coordinate system being that of the point
-on the extreme right.
-
-In walking a model tree (such as "prep'ing" the model for ray tracing),
-each arc crossed from root to leaf normally gets its matrix multiplied on
-the right side of the current matrix stack[1]. Rigid body articulations
-of a model can then be described by changing or adding matrices at the
-appropriate points in this stack.
-
-The matrix animation operations currently recognized by RT are:
-
- rstack replace the entire stack up to this point
- rarc replace the matrix on the specified arc
- rboth replace the entire stack and the arc matrix
- rmul arc = arc * Matrix
- lmul arc = Matrix * arc
-
-The path specifying where in the model tree the operation is to
-be applied can either be an absolute path, e.g.
-
-/body/left/arm/hand
-
-which would affect the arc between the left arm of body and the hand
-(note that hand need not be a leaf), or it can be a "wildcard", e.g.
-
-arm/hand
-
-would mean the arc between arm and hand anywhere in the model tree, i.e.
-it is not restricted to the left one as above. Finally a wildcard like
-
-arm
-
-means the arc before any node called arm.
-
--------------------------
-[1] It is interesting to note that our "right multiply" operation
-corresponds exactly to the SGI Iris multmatrix() command. The later
-pre-multiplies the matrix stack, but the matrix stack post-multiplies
-any points being transformed! In fact, if one looks at the Iris at the
-geometry engine level, one finds that it works with matrices in the
-usual mathematical form - the gl2 library transposes them in and out of
-N&S form.
Deleted: brlcad/trunk/doc/sun.txt
===================================================================
--- brlcad/trunk/doc/sun.txt 2017-06-22 18:20:35 UTC (rev 69933)
+++ brlcad/trunk/doc/sun.txt 2017-06-28 13:34:39 UTC (rev 69934)
@@ -1,27 +0,0 @@
-Some notes on using BRL-CAD on Sun Workstations (Release 3.0):
-
-As of Release 3.0 MGED is much improved on the Suns. It now opens
-its own window which can be resized, iconified, etc., like other
-windows under SunTools.
-
-While a generic replacement for knobs and buttons was not completed,
-the function keys F1-F7 help somewhat. Pressing these keys attaches
-certain "knob" functions to the mouse X or Y motions:
-
-F# Function Mouse
- 1 Zoom y
- 2 Z Slew y
- 3 X Slew x
- 4 Y Slew y
- 5 X Rotate x
- 6 Y Rotate y
- 7 Z Rotate y
-
-These keys can be used as "chords", e.g. pressing F3 and F4 together
-will give you X and Y translates on the mouse.
-
-Frame buffer support has also been greatly enhanced, but the released
-version does not yet open its own window for display. Rather, it
-covers the window a frame buffer command was invoked from with the
-display. Panning and Zooming are now supported, as is shared memory.
-"/dev/sunp" can be used to get private memory.
Deleted: brlcad/trunk/doc/tube.txt
===================================================================
--- brlcad/trunk/doc/tube.txt 2017-06-22 18:20:35 UTC (rev 69933)
+++ brlcad/trunk/doc/tube.txt 2017-06-28 13:34:39 UTC (rev 69934)
@@ -1,158 +0,0 @@
-DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
-
-Specific details about producing an animation of a gun tube,
-using the BRL-CAD Package and various IBD simulation codes.
-
-As things presently stand, the central part of this linkage is a program
-called TUBE.C that takes two input files describing the motion of the
-scene, and generates an MGED database containing a separate tree
-(Directed Acyclic Graph [DAG]) for each frame. The name of combination
-at the top of the tree is the letter "g" (for group) followed by the
-frame number, so that the first frame of the animation is tree "g0", the
-second frame is tree "g1", etc.
-
-The current X displacement data for the gun tube center of mass points
-is presently contained in the array dxtab[] compiled into the program.
-
-The input file "pos.dat" contains the projectile position data. On each
-input line, the time (in milliseconds) is listed first, followed by the
-X displacement of the base of the projectile, offset from the projectile
-starting position. The time values listed in this file do not have to
-correspond to the time values listed for the articulation; the proper
-time will be chosen by the program. If the file "tank.out" contains the
-output from a normal run of IBHVG2, the file "pos.dat" can be created by
-running this Shell script:
-
-cat tank.out |
-sed -n '/ TIME TRAV/,/ PROJECTILE EXIT/p' |
-grep -v "[A-Z]" |
-cut -c2-132 |
-grep -v "^[ ]*$" |
-awk '{printf "%10.2f %10.2f\n", $1, $2 }' > pos.dat
-
-The mass displacement file is presented to the TUBE program on standard
-input, where each time step has the following format: First a line with
-the word "TIME" followed by a floating point number, in milliseconds.
-Then, one input line for each of ``nmass'' (e.g., 12) mass points, in
-ascending order of mass point number, starting with one, with one
-integer and three floating point numbers on each line: the mass number,
-the X, Y, and Z deviations (currently expected in inches, where +X is
-towards the muzzle, +Y is in the vertical direction, and +Z is to the
-right of the muzzle). There must be exactly one blank line after the
-last mass point data line and before the next "TIME" line. Note that
-mass point 1 corresponds to "m1" on the diagram, and mass point 12 is
-"m12" on the diagram. The position of a two additional points (0 and
-13) are guessed within the program, with mass point 0 being the outer
-edge of the breach block, and mass point 13 being the muzzle end, but
-these two points are not specified in the input file. E.g.,
-
-TIME 0.02
-1 0.01 0.00035 0.00000075
-2 0.01 0.00040 0.00000900
- (etc.)
-12 1.01 0.0784 3.129
-
-TIME 0.04
- (etc.)
-
-Therefore, assuming the mass displacement file is in "mass.dat",
-and that the "pos.dat" file exists in the same directory,
-and that the model for the projectile is in the file "projectile.g"
-with main (top) combination named "ke",
-the TUBE program is run as follows:
-
-tube < mass.dat > anim.g
-cat projectile.g >> anim.g
-
-This MGED database can be examined with MGED. To see the first
-frame, say:
-
-mged anim.g
-
-then respond to the "attach" question appropriately for the type of
-graphics device being used, and then enter the command
-
-B g0
-
-This will display the geometry configuration for frame zero.
-The "B" command in MGED stands for "Blast screen clear, then display
-named object(s)". To view frame 42, enter the command
-
-B g42
-
-and so on. The MGED control dials can be used to translate, rotate,
-and zoom the current viewpoint. When a desirable viewpoint has been
-selected, it can saved in a file called "view1.sh" with the command
-
-saveview view1.sh
-
-This file is actually a Shell script that will render that one frame for
-you, using RT, and store it in a file. However, in this case, a text
-editor is used to extract just the viewsize, eye point, and homogeneous
-transform matrix (20 numbers in all) and store them in another file, say
-"view1.mat".
-
-To preview the whole animation in wireframe format, assuming that there
-are 300 frames running 0 to 299, this Shell script (called, say,
-"preview.sh") is used:
-
-rm -f temp.sh
-cat << END > temp.sh
- mged anim.g
- attach ir (for SGI 3-D, or "sgi" for SGI 4-D)
- B g0
- rmats view1.mat
-END
-for frame in `loop 0 299`
-do
- echo "B g${frame}" >> temp.sh
-done
-sh temp.sh
-rm -f temp.sh
-
-Assuming that this animation sequence and viewpoint are satisfactory,
-and that the desired "graph paper" background file is stored in a
-128x128 .pix file called "movie128bw.pix" in the current directory,
-the animation can be rendered the Shell script given below (called, say,
-"render.sh"):
-
-for frame in `loop 0 299`
-do
- rt -s512 -M -o out.pix.${frame} \
- anim.g g${frame} < view1.mat >>& render.log
-done
-
-The "-s512" parameter specifies that the desired image is to be square,
-and 512x512 pixels in size. This is typically the desired resolution
-for videotape. The "-M" parameter specifies that the view matrix is to
-be obtained from stdin. The "-o out.pix.${frame}" says that the output
-picture is to be stored in a file called "out.pix.123" where "123"
-represents the current frame number. (The backslash at the end of the
-line continues the command to the next line). Specifying "anim.g"
-names the input MGED database, and "g${frame}" specifies the treetop
-appropriate for the current frame.
-
-Because this procedure is likely to take a significant amount of time,
-the shell script should be submitted as a batch job. On the minicomputers,
-the MDQS command
-
-batch render.sh
-
-should be used. On both of the UNICOS Cray systems, the NQS command
-
-qsub render.sh
-
-should be used.
-
-To view one of these files, the Shell environment variable FB_FILE
-should be set to indicate the appropriate framebuffer on the network
-to use, and the program "pix-fb" is used to transfer the picture to
-the framebuffer. For more details on the variable FB_FILE, consult
-the brlcad(1) manual page; for more details on the program "pix-fb",
-consult the pix-fb(1) manual page; for more details on the framebuffer
-library, consult libfb(3) manual page. This can be done on BRL-IBD
-with these commands:
-
-man brlcad
-man pix-fb
-man libfb
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Source Commits mailing list
brlcad-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-commits
