Initial revision
This commit is contained in:
curt
parent
f7f4bf5ff5
commit
29f6d05875
575 changed files with 10909 additions and 42163 deletions
|
|
@ -205,6 +205,9 @@ effectiveness of your controller.
|
|||
|
||||
%------------------------------------------------------------------------
|
||||
% $Log$
|
||||
% Revision 1.1 1999/04/05 21:32:34 curt
|
||||
% Initial revision
|
||||
%
|
||||
% Revision 1.1 1999/03/09 19:09:41 curt
|
||||
% Initial revision.
|
||||
%
|
||||
|
|
|
|||
|
|
@ -102,6 +102,9 @@ built this system, feel free to e-mail me at
|
|||
|
||||
%------------------------------------------------------------------------
|
||||
% $Log$
|
||||
% Revision 1.1 1999/04/05 21:32:34 curt
|
||||
% Initial revision
|
||||
%
|
||||
% Revision 1.1 1999/03/09 19:09:41 curt
|
||||
% Initial revision.
|
||||
%
|
||||
|
|
|
|||
|
|
@ -1,13 +0,0 @@
|
|||
# The "checkoutlist" file is used to support additional version controlled
|
||||
# administrative files in $CVSROOT/CVSROOT, such as template files.
|
||||
#
|
||||
# The first entry on a line is a filename which will be checked out from
|
||||
# the corresponding RCS file in the $CVSROOT/CVSROOT directory.
|
||||
# The remainder of the line is an error message to use if the file cannot
|
||||
# be checked out.
|
||||
#
|
||||
# File format:
|
||||
#
|
||||
# [<whitespace>]<filename><whitespace><error message><end-of-line>
|
||||
#
|
||||
# comment lines begin with '#'
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
# The "commitinfo" file is used to control pre-commit checks.
|
||||
# The filter on the right is invoked with the repository and a list
|
||||
# of files to check. A non-zero exit of the filter program will
|
||||
# cause the commit to be aborted.
|
||||
#
|
||||
# The first entry on a line is a regular expression which is tested
|
||||
# against the directory that the change is being committed to, relative
|
||||
# to the $CVSROOT. For the first match that is found, then the remainder
|
||||
# of the line is the name of the filter to run.
|
||||
#
|
||||
# If the repository name does not match any of the regular expressions in this
|
||||
# file, the "DEFAULT" line is used, if it is specified.
|
||||
#
|
||||
# If the name "ALL" appears as a regular expression it is always used
|
||||
# in addition to the first matching regex or "DEFAULT".
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
# Set this to "no" if pserver shouldn't check system users/passwords
|
||||
#SystemAuth=no
|
||||
|
||||
# Set `PreservePermissions' to `yes' to save file status information
|
||||
# in the repository.
|
||||
#PreservePermissions=no
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
# This file affects handling of files based on their names.
|
||||
#
|
||||
# The -t/-f options allow one to treat directories of files
|
||||
# as a single file, or to transform a file in other ways on
|
||||
# its way in and out of CVS.
|
||||
#
|
||||
# The -m option specifies whether CVS attempts to merge files.
|
||||
#
|
||||
# The -k option specifies keyword expansion (e.g. -kb for binary).
|
||||
#
|
||||
# Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers)
|
||||
#
|
||||
# wildcard [option value][option value]...
|
||||
#
|
||||
# where option is one of
|
||||
# -f from cvs filter value: path to filter
|
||||
# -t to cvs filter value: path to filter
|
||||
# -m update methodology value: MERGE or COPY
|
||||
# -k expansion mode value: b, o, kkv, &c
|
||||
#
|
||||
# and value is a single-quote delimited value.
|
||||
# For example:
|
||||
#*.gif -k 'b'
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# The "editinfo" file is used to allow verification of logging
|
||||
# information. It works best when a template (as specified in the
|
||||
# rcsinfo file) is provided for the logging procedure. Given a
|
||||
# template with locations for, a bug-id number, a list of people who
|
||||
# reviewed the code before it can be checked in, and an external
|
||||
# process to catalog the differences that were code reviewed, the
|
||||
# following test can be applied to the code:
|
||||
#
|
||||
# Making sure that the entered bug-id number is correct.
|
||||
# Validating that the code that was reviewed is indeed the code being
|
||||
# checked in (using the bug-id number or a seperate review
|
||||
# number to identify this particular code set.).
|
||||
#
|
||||
# If any of the above test failed, then the commit would be aborted.
|
||||
#
|
||||
# Actions such as mailing a copy of the report to each reviewer are
|
||||
# better handled by an entry in the loginfo file.
|
||||
#
|
||||
# One thing that should be noted is the the ALL keyword is not
|
||||
# supported. There can be only one entry that matches a given
|
||||
# repository.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
# The "loginfo" file controls where "cvs commit" log information
|
||||
# is sent. The first entry on a line is a regular expression which must match
|
||||
# the directory that the change is being made to, relative to the
|
||||
# $CVSROOT. If a match is found, then the remainder of the line is a filter
|
||||
# program that should expect log information on its standard input.
|
||||
#
|
||||
# If the repository name does not match any of the regular expressions in this
|
||||
# file, the "DEFAULT" line is used, if it is specified.
|
||||
#
|
||||
# If the name ALL appears as a regular expression it is always used
|
||||
# in addition to the first matching regex or DEFAULT.
|
||||
#
|
||||
# You may specify a format string as part of the
|
||||
# filter. The string is composed of a `%' followed
|
||||
# by a single format character, or followed by a set of format
|
||||
# characters surrounded by `{' and `}' as separators. The format
|
||||
# characters are:
|
||||
#
|
||||
# s = file name
|
||||
# V = old version number (pre-checkin)
|
||||
# v = new version number (post-checkin)
|
||||
#
|
||||
# For example:
|
||||
#DEFAULT (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commitlog
|
||||
# or
|
||||
#DEFAULT (echo ""; id; echo %{sVv}; date; cat) >> $CVSROOT/CVSROOT/commitlog
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
# Three different line formats are valid:
|
||||
# key -a aliases...
|
||||
# key [options] directory
|
||||
# key [options] directory files...
|
||||
#
|
||||
# Where "options" are composed of:
|
||||
# -i prog Run "prog" on "cvs commit" from top-level of module.
|
||||
# -o prog Run "prog" on "cvs checkout" of module.
|
||||
# -e prog Run "prog" on "cvs export" of module.
|
||||
# -t prog Run "prog" on "cvs rtag" of module.
|
||||
# -u prog Run "prog" on "cvs update" of module.
|
||||
# -d dir Place module in directory "dir" instead of module name.
|
||||
# -l Top-level directory only -- do not recurse.
|
||||
#
|
||||
# NOTE: If you change any of the "Run" options above, you'll have to
|
||||
# release and re-checkout any working directories of these modules.
|
||||
#
|
||||
# And "directory" is a path to a directory relative to $CVSROOT.
|
||||
#
|
||||
# The "-a" option specifies an alias. An alias is interpreted as if
|
||||
# everything on the right of the "-a" had been typed on the command line.
|
||||
#
|
||||
# You can encode a module within a module by using the special '&'
|
||||
# character to interpose another module into the current module. This
|
||||
# can be useful for creating a module that consists of many directories
|
||||
# spread out over the entire source repository.
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
# The "notify" file controls where notifications from watches set by
|
||||
# "cvs watch add" or "cvs edit" are sent. The first entry on a line is
|
||||
# a regular expression which is tested against the directory that the
|
||||
# change is being made to, relative to the $CVSROOT. If it matches,
|
||||
# then the remainder of the line is a filter program that should contain
|
||||
# one occurrence of %s for the user to notify, and information on its
|
||||
# standard input.
|
||||
#
|
||||
# "ALL" or "DEFAULT" can be used in place of the regular expression.
|
||||
#
|
||||
# For example:
|
||||
#ALL mail %s -s "CVS notification"
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
# The "rcsinfo" file is used to control templates with which the editor
|
||||
# is invoked on commit and import.
|
||||
#
|
||||
# The first entry on a line is a regular expression which is tested
|
||||
# against the directory that the change is being made to, relative to the
|
||||
# $CVSROOT. For the first match that is found, then the remainder of the
|
||||
# line is the name of the file that contains the template.
|
||||
#
|
||||
# If the repository name does not match any of the regular expressions in this
|
||||
# file, the "DEFAULT" line is used, if it is specified.
|
||||
#
|
||||
# If the name "ALL" appears as a regular expression it is always used
|
||||
# in addition to the first matching regex or "DEFAULT".
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# The "taginfo" file is used to control pre-tag checks.
|
||||
# The filter on the right is invoked with the following arguments:
|
||||
#
|
||||
# $1 -- tagname
|
||||
# $2 -- operation "add" for tag, "mov" for tag -F, and "del" for tag -d
|
||||
# $3 -- repository
|
||||
# $4-> file revision [file revision ...]
|
||||
#
|
||||
# A non-zero exit of the filter program will cause the tag to be aborted.
|
||||
#
|
||||
# The first entry on a line is a regular expression which is tested
|
||||
# against the directory that the change is being committed to, relative
|
||||
# to the $CVSROOT. For the first match that is found, then the remainder
|
||||
# of the line is the name of the filter to run.
|
||||
#
|
||||
# If the repository name does not match any of the regular expressions in this
|
||||
# file, the "DEFAULT" line is used, if it is specified.
|
||||
#
|
||||
# If the name "ALL" appears as a regular expression it is always used
|
||||
# in addition to the first matching regex or "DEFAULT".
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# The "verifymsg" file is used to allow verification of logging
|
||||
# information. It works best when a template (as specified in the
|
||||
# rcsinfo file) is provided for the logging procedure. Given a
|
||||
# template with locations for, a bug-id number, a list of people who
|
||||
# reviewed the code before it can be checked in, and an external
|
||||
# process to catalog the differences that were code reviewed, the
|
||||
# following test can be applied to the code:
|
||||
#
|
||||
# Making sure that the entered bug-id number is correct.
|
||||
# Validating that the code that was reviewed is indeed the code being
|
||||
# checked in (using the bug-id number or a seperate review
|
||||
# number to identify this particular code set.).
|
||||
#
|
||||
# If any of the above test failed, then the commit would be aborted.
|
||||
#
|
||||
# Actions such as mailing a copy of the report to each reviewer are
|
||||
# better handled by an entry in the loginfo file.
|
||||
#
|
||||
# One thing that should be noted is the the ALL keyword is not
|
||||
# supported. There can be only one entry that matches a given
|
||||
# repository.
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
#FIG 3.2
|
||||
Landscape
|
||||
Center
|
||||
Inches
|
||||
Letter
|
||||
100.00
|
||||
Single
|
||||
0
|
||||
1200 2
|
||||
5 1 0 1 0 7 0 0 -1 0.000 0 1 0 0 8962.500 6000.000 3600 5100 3525 6000 3600 6900
|
||||
5 1 0 1 0 7 0 0 -1 0.000 0 1 0 0 10762.500 6000.000 5400 5100 5325 6000 5400 6900
|
||||
5 1 0 1 0 7 0 0 -1 0.000 0 1 0 0 4500.000 -262.500 3600 5100 4500 5175 5400 5100
|
||||
5 1 0 1 0 7 0 0 -1 0.000 0 0 0 0 4500.000 1537.500 5400 6900 4500 6975 3600 6900
|
||||
5 1 2 1 0 7 0 0 -1 3.000 0 1 0 0 9825.000 6075.000 4500 5175 4425 6000 4500 6975
|
||||
5 1 2 1 0 7 0 0 -1 3.000 0 0 0 0 4425.000 637.500 5325 6000 4425 6075 3525 6000
|
||||
2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 1.00 60.00 120.00
|
||||
6000 5175 4425 6075
|
||||
2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 1.00 60.00 120.00
|
||||
6000 5175 8550 5175
|
||||
2 1 0 1 0 7 0 0 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 1.00 60.00 120.00
|
||||
6000 5175 6000 2625
|
||||
4 0 0 0 0 0 18 0.0000 4 195 180 8475 5475 X\001
|
||||
4 0 0 0 0 0 18 0.0000 4 195 180 5700 2700 Y\001
|
||||
4 0 0 0 0 0 18 0.0000 4 195 180 4500 5850 Z\001
|
||||
|
Before Width: | Height: | Size: 101 KiB After Width: | Height: | Size: 101 KiB |
|
Before Width: | Height: | Size: 84 KiB After Width: | Height: | Size: 84 KiB |
|
Before Width: | Height: | Size: 60 KiB After Width: | Height: | Size: 60 KiB |
|
Before Width: | Height: | Size: 93 KiB After Width: | Height: | Size: 93 KiB |
14
Docs/Misc/Features
Normal file
14
Docs/Misc/Features
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
Sky
|
||||
stars
|
||||
correct placement for time, date, and viewer position
|
||||
correct magnitude
|
||||
sun
|
||||
correct position
|
||||
lights the scene correctly
|
||||
sky
|
||||
blends into haze at horizon
|
||||
sunset/sunrise effects
|
||||
planets
|
||||
correct position
|
||||
correct magnitude
|
||||
|
||||
142
Docs/Portability/fgfs-portability-guide.tex
Normal file
142
Docs/Portability/fgfs-portability-guide.tex
Normal file
|
|
@ -0,0 +1,142 @@
|
|||
%% This LaTeX-file was created by <root> Sat Dec 5 17:56:02 1998
|
||||
%% LyX 0.12 (C) 1995-1998 by Matthias Ettrich and the LyX Team
|
||||
|
||||
%% Do not edit this file unless you know what you are doing.
|
||||
\documentclass{article}
|
||||
\usepackage[T1]{fontenc}
|
||||
|
||||
\makeatletter
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LyX specific LaTeX commands.
|
||||
\newcommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\spacefactor1000}
|
||||
|
||||
\makeatother
|
||||
|
||||
\begin{document}
|
||||
|
||||
|
||||
\vfill{}
|
||||
\title{\emph{FlightGear} Flight Simulator\\
|
||||
Portability Guide}
|
||||
\vfill{}
|
||||
|
||||
|
||||
\author{Bernie Bright (bbright@c031.aone.net.au)}
|
||||
|
||||
|
||||
\date{28 November 1998}
|
||||
|
||||
\maketitle
|
||||
FlightGear is a multi-platform general aviation flight simulator\@. It is an
|
||||
open development project in which anyone with network access and a C++ compiler
|
||||
can contribute patches or new features.\\
|
||||
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
The file \emph{Include/compiler.h} attempts to capture the differences between
|
||||
C++ compiler and STL implementations through the use of ``feature test macros''\@.
|
||||
The file is divided into two parts. The first part contains a section for each
|
||||
compiler, consisting of manifest constants specifying the features supported
|
||||
or absent from the particular compiler/STL combination\@. The second part uses
|
||||
the feature test macros to supply any missing features\@.
|
||||
|
||||
|
||||
\subsection{Supported compilers (more to come)}
|
||||
|
||||
gcc 2.7.x\\
|
||||
gcc 2.8.x\\
|
||||
egcs 1.x\\
|
||||
Inprise (Borland) C++ 5.02\\
|
||||
Inprise (Borland) C++Builder 1 (5.20)
|
||||
|
||||
|
||||
\subsection{Features Tests}
|
||||
|
||||
|
||||
\subsubsection{STL}
|
||||
|
||||
\begin{description}
|
||||
\item [FG\_NEED\_AUTO\_PTR]Some STL implementations don't supply an \texttt{auto\_ptr<>}
|
||||
class template. Define this to provide one.
|
||||
\item [FG\_NO\_DEFAULT\_TEMPLATE\_ARGS]Define this if the compiler doesn't support
|
||||
default arguments in template declarations. \emph{(example)}
|
||||
\item [FG\_INCOMPLETE\_FUNCTIONAL]Some STL implementations don't have \texttt{mem\_fun\_ref()}.
|
||||
Define this to provide one.
|
||||
\item [FG\_NO\_ARROW\_OPERATOR]Define this if iterators don't support \texttt{operator->()}.
|
||||
\emph{(example)}
|
||||
\item [FG\_EXPLICIT\_FUNCTION\_TMPL\_ARGS]~
|
||||
\item [FG\_MEMBER\_TEMPLATES]~
|
||||
\end{description}
|
||||
|
||||
\subsubsection{Compiler}
|
||||
|
||||
\begin{description}
|
||||
\item [FG\_NAMESPACES]Define if compiler supports namespaces.
|
||||
\item [FG\_HAVE\_STD]Define if std:: namespace supported.
|
||||
\item [FG\_HAVE\_STD\_INCLUDES]Define if headers should be included as \texttt{<iostream>}
|
||||
instead of \texttt{<iostream}.h>. Also implies that all ISO C++ standard include
|
||||
files are present.
|
||||
\item [FG\_HAVE\_STREAMBUF]Define if \texttt{<streambuf>} or \texttt{<streambuf}.h>
|
||||
are present.
|
||||
\item [FG\_CLASS\_PARTIAL\_SPECIALIZATION]~
|
||||
\item [FG\_NEED\_EXPLICIT]Define if the compiler doesn't support the \texttt{\textbf{explicit}}
|
||||
keyword.
|
||||
\item [FG\_NEED\_TYPENAME]Define if the compiler doesn't support the \texttt{\textbf{typename}}
|
||||
keyword.
|
||||
\item [FG\_NEED\_MUTABLE]Define if the compiler doesn't support the \texttt{\textbf{mutable}}
|
||||
keyword.
|
||||
\item [FG\_NEED\_BOOL]Define if the compiler doesn't have the \texttt{\textbf{bool}}
|
||||
type.
|
||||
\end{description}
|
||||
|
||||
\subsubsection{Include Files}
|
||||
|
||||
This section deals with header file naming conventions. Some systems truncate
|
||||
filenames, 8.3 being common, other systems use old or non-standard names for
|
||||
some header files. We deal with the simple cases by defining macros that expand
|
||||
to the appropriate filename.
|
||||
|
||||
\begin{description}
|
||||
\item [STD\_ALGORITHM]=> <algorithm>, ``algorithm''
|
||||
\item [STD\_FUNCTIONAL]=> <functional>, ``functional''
|
||||
\item [STD\_IOMANIP]=> <iomanip>, <iomanip.h>
|
||||
\item [STD\_IOSTREAM]=> <iostream>, <iostream.h>, <iostreams.h>
|
||||
\item [STD\_STDEXCEPT]=> <stdexcept> (ignore this, FlightGear doesn't use exceptions)
|
||||
\item [STD\_STRING]=> <string>
|
||||
\item [STD\_STRSTREAM]=> <strstream>, <strstream.h>
|
||||
\end{description}
|
||||
In use, instead of writing \#include <iostream> you write \#include STD\_IOSTREAM.\\
|
||||
\\
|
||||
The situation becomes complicated with missing header files. <streambuf> is
|
||||
a good example. In this case we must rely on FG\_HAVE\_STD\_INCLUDES and FG\_HAVE\_STREAMBUF.\\
|
||||
\emph{}\\
|
||||
\emph{TODO}
|
||||
|
||||
|
||||
\subsection{and the rest}
|
||||
|
||||
|
||||
\subsubsection{Namespace Issues}
|
||||
|
||||
\begin{description}
|
||||
\item [FG\_USING\_STD(X)]~
|
||||
\item [FG\_NAMESPACE(X)]~
|
||||
\item [FG\_NAMESPACE\_END]~
|
||||
\item [FG\_USING\_NAMESPACE(X)]~
|
||||
\end{description}
|
||||
|
||||
\subsubsection{Templates}
|
||||
|
||||
\begin{description}
|
||||
\item [FG\_NULL\_TMPL\_ARGS]~
|
||||
\item [FG\_TEMPLATE\_NULL]~
|
||||
\end{description}
|
||||
\begin{thebibliography}{}
|
||||
\bibitem{1}Stroustrup, Bjarne, \emph{The C++ Programming Programming Language}, 3rd edition,
|
||||
June 1997, ISBN 0-201-88954-4
|
||||
\bibitem{2}SGI Standard Template Library (STL) release 3.11
|
||||
\end{thebibliography}
|
||||
\end{document}
|
||||
|
|
@ -202,6 +202,9 @@ so that you can never fly any closer to them.
|
|||
|
||||
%------------------------------------------------------------------------
|
||||
% $Log$
|
||||
% Revision 1.1 1999/04/05 21:32:34 curt
|
||||
% Initial revision
|
||||
%
|
||||
% Revision 1.1 1999/02/14 19:10:47 curt
|
||||
% Initial revisions.
|
||||
%
|
||||
3
Docs/Scenery/DEM.info
Normal file
3
Docs/Scenery/DEM.info
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
An online guide for interpreting the DEM data file format is available at:
|
||||
|
||||
http://edcwww.cr.usgs.gov/glis/hyper/guide/1_dgr_dem
|
||||
BIN
Docs/Scenery/DLG/dlg3sdts.wp.gz
Normal file
BIN
Docs/Scenery/DLG/dlg3sdts.wp.gz
Normal file
Binary file not shown.
BIN
Docs/Scenery/DLG/dug-2.wp6.gz
Executable file
BIN
Docs/Scenery/DLG/dug-2.wp6.gz
Executable file
Binary file not shown.
3013
Docs/Scenery/OBJ.format.txt
Normal file
3013
Docs/Scenery/OBJ.format.txt
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -549,6 +549,9 @@ Generates the width of a 1/8 x 1/8 degree tile at various latitudes.
|
|||
|
||||
%------------------------------------------------------------------------
|
||||
% $Log$
|
||||
% Revision 1.1 1999/04/05 21:32:34 curt
|
||||
% Initial revision
|
||||
%
|
||||
% Revision 1.4 1999/03/21 15:12:51 curt
|
||||
% Updated to reflect current scenery progress.
|
||||
%
|
||||
50
Docs/Scenery/SceneGeneration/terrain.outline
Normal file
50
Docs/Scenery/SceneGeneration/terrain.outline
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
Basically what I'm doing is starting with the 3 arcsec DEM files (a
|
||||
point every 100 meters roughly.)
|
||||
|
||||
I start out at one corner and walk down a horizonal row. I start with
|
||||
the first 2 points and do a least squares fit, I then add the next
|
||||
point, and the next, and the next until my least squares fit exceeds
|
||||
some error tolerance from the original data. At that point, I back up
|
||||
one point and include that point in the output set of points. This
|
||||
point then becomes my new starting point for the least squares fit. I
|
||||
repeat this until I finish the row. I do this for each row to produce
|
||||
an "irregular" set of output points from the original. I'm sure from
|
||||
a pure mathematical perspective you can see some potential flaws in
|
||||
this approach, but the actual real life result is actually quite good.
|
||||
|
||||
I then do a Delauney triangulation of these points (and add in more to
|
||||
keep the triangles from getting too long and skinny.)
|
||||
|
||||
I have to go through additional pain to make sure that all the points
|
||||
coincide on the edge between two adjacent areas (and the normals to so
|
||||
there is continuity in the shading.)
|
||||
|
||||
I then run a "tri-striper" program to connect up all the individual
|
||||
triangles into more efficient opengl strips.
|
||||
|
||||
Finally I post process everything to compensate for bugs in our lousy
|
||||
tri-striper and to add in a few other things that our render requires.
|
||||
|
||||
There is a wee bit of documentation at:
|
||||
|
||||
http://www.menet.umn.edu/~curt/fgfs/Docs/Scenery/CoordinateSystem/CoordinateSystem.html
|
||||
|
||||
Here I lay out our basic coordinate system. Essentially the scenery
|
||||
tiles that result in the above process are just cutouts of the Earths
|
||||
surface. The maintain the curved shape and spacial orientation. The
|
||||
renderer translates everything to near (0,0,0) to compensate for
|
||||
GLfloat precision limitations.
|
||||
|
||||
All the tools I use to do this are distributed with the FG source, so
|
||||
feel free to download them, play around, and ask questions.
|
||||
|
||||
Our resulting scenery tile format is structured to facilitate view
|
||||
frustum culling on a per tile basis as well as a per "fragment" basis.
|
||||
|
||||
The next thing I plan to work on is sorting by material properties.
|
||||
As I walk through the tile structures doing my view frustum culling,
|
||||
instead of immediately rendering the visible fragments, I plan to toss
|
||||
them into buckets by material property. Then I make a pass through
|
||||
each of these buckets, rendering all the items with like properties.
|
||||
This should minimize opengl state and texture changes which should
|
||||
help keep the performance from going in the dumpster.
|
||||
|
|
@ -223,6 +223,9 @@ determine the proper angle for the sky dome rotation.
|
|||
|
||||
%------------------------------------------------------------------------
|
||||
% $Log$
|
||||
% Revision 1.1 1999/04/05 21:32:34 curt
|
||||
% Initial revision
|
||||
%
|
||||
% Revision 1.1 1999/02/14 19:12:21 curt
|
||||
% Initial revisions.
|
||||
%
|
||||
152
Docs/Time/Events/Events.tex
Normal file
152
Docs/Time/Events/Events.tex
Normal file
|
|
@ -0,0 +1,152 @@
|
|||
%
|
||||
% `Events.tex' -- describes the FG Event Manager
|
||||
%
|
||||
% Written by Curtis Olson. Started December, 1997.
|
||||
%
|
||||
% $Id$
|
||||
%------------------------------------------------------------------------
|
||||
|
||||
|
||||
\documentclass[12pt]{article}
|
||||
|
||||
\usepackage{anysize}
|
||||
\papersize{11in}{8.5in}
|
||||
\marginsize{1in}{1in}{1in}{1in}
|
||||
|
||||
\usepackage{amsmath}
|
||||
|
||||
\usepackage{epsfig}
|
||||
|
||||
\usepackage{setspace}
|
||||
\onehalfspacing
|
||||
|
||||
\usepackage{url}
|
||||
|
||||
|
||||
\begin{document}
|
||||
|
||||
|
||||
\title{
|
||||
Flight Gear Periodic Event Manager and Scheduler
|
||||
}
|
||||
|
||||
|
||||
\author{
|
||||
Curtis L. Olson\\
|
||||
(\texttt{curt@me.umn.edu})
|
||||
}
|
||||
|
||||
|
||||
\maketitle
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
Many tasks within the simulator need to only run periodically. These
|
||||
are typically tasks that calculate values that don't change
|
||||
significantly in 1/60th of a second, but instead change noticeably on
|
||||
the order of seconds, minutes, or hours.
|
||||
|
||||
Running these tasks every iteration would needless degrade
|
||||
performance. Instead, we would like to spread these out over time to
|
||||
minimize the impact they might have on frame rates, and minimize the
|
||||
chance of pauses and hesitations.
|
||||
|
||||
\section{Overview}
|
||||
|
||||
The goal of the event manager is to provide a way for events to be run
|
||||
periodically, and to spread this load out so that the processing time
|
||||
spent at any particular iteration is minimized.
|
||||
|
||||
The scheduler consists of two parts. The first part is simply a list
|
||||
of registered events along with any management information associated
|
||||
with that event. The second part is a run queue. When events are
|
||||
triggered, they are placed in the run queue. The system executes only
|
||||
one pending event per iteration in order to balance the load.
|
||||
|
||||
\section{The Events List}
|
||||
|
||||
\subsection{Event List Structure}
|
||||
|
||||
All registered events are maintained in a list. Currently, this list
|
||||
is simply an array of event structures. Each event structure stores
|
||||
the following information.
|
||||
|
||||
\begin{itemize}
|
||||
\item An ASCII description or event identifier. This is used when
|
||||
outputting event statistics.
|
||||
|
||||
\item A pointer to the event function.
|
||||
|
||||
\item An event status flag. The flag marks the process as ready to
|
||||
run, queued in the run queue, or suspended from eligibility to
|
||||
run.
|
||||
|
||||
\item A time interval specifying how often to schedule and run this
|
||||
event.
|
||||
|
||||
\item The absolute time this event was last run.
|
||||
|
||||
\item The next absolute time this event is scheduled to run.
|
||||
|
||||
\item The cumulative run time for this process (in ms.)
|
||||
|
||||
\item The least time consumed by a single run of this event (in ms.)
|
||||
|
||||
\item The most time consumed by a single run of this event (in ms.)
|
||||
|
||||
\item The number of times this event has been run.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Event List Operation}
|
||||
|
||||
To use the event list, you must first initialize it by calling
|
||||
\texttt{fgEventInit()}.
|
||||
|
||||
Once the list has been initialized, you can register events by calling
|
||||
\texttt{fgEventRegister()}. A typical usage might be:
|
||||
\texttt{fgEventRegister(``fgUpdateWeather()'', fgUpdateWeather,
|
||||
FG\_EVENT\_READY, 60000)}. This tells the event manager to schedule
|
||||
and run the event, \texttt{fgUpdateWeather()}, every 60 seconds. The
|
||||
first field is an ASCII description of the function, the second field
|
||||
is a pointer to the function, the third field is the status flag, and
|
||||
the last field is the time interval. Event functions should return
|
||||
\texttt{void} and accept no parameters. The status flag can set to
|
||||
either \texttt{FG\_EVENT\_SUSP}, \texttt{FG\_EVENT\_READY}, or
|
||||
\texttt{FG\_EVENT\_QUEUED}. \texttt{FG\_EVENT\_SUSP} means register
|
||||
the event, but never schedule it to run. \texttt{FG\_EVENT\_READY}
|
||||
means register the event and schedule and run it normally.
|
||||
\texttt{FG\_EVENT\_QUEUED} is mostly used internally so that an event
|
||||
will never have more than one entry in the run queue.
|
||||
|
||||
Finally, in your main loop, you must add a call to
|
||||
\texttt{fgEventProcess()} to run it every iteration. This routine
|
||||
will schedule all pending events (push them onto the run queue) and
|
||||
then execute the first thing in the run queue.
|
||||
|
||||
\section{The Run Queue}
|
||||
|
||||
The run queue is a very simple queue who's elements are just a pointer
|
||||
to an event list element. When an event needs to be scheduled, a
|
||||
pointer to that event is pushed onto the back of the queue. Each time
|
||||
\texttt{fgEventProcess()} is called, the first element on the run
|
||||
queue will be executed.
|
||||
|
||||
\section{Profiling Events}
|
||||
|
||||
As stated before, each event record contains simple event statistics
|
||||
such as the total time spent running this event, the quickest run, the
|
||||
slowest run, and the total number of times run. We can output the
|
||||
list of events along with these statistics in order to determine if any of
|
||||
them are consuming an excessive amount of time, or if there is any
|
||||
chance that a particular event could run slow enough to be responsible
|
||||
for a perceived hesitation or pause in the flow of the simulation.
|
||||
|
||||
\end{document}
|
||||
|
||||
|
||||
%------------------------------------------------------------------------
|
||||
% $Log$
|
||||
% Revision 1.1 1999/04/05 21:32:34 curt
|
||||
% Initial revision
|
||||
%
|
||||
306
Hints/aaa
Normal file
306
Hints/aaa
Normal file
|
|
@ -0,0 +1,306 @@
|
|||
From fatcity!root@news.cts.com Wed Aug 20 16:34:24 1997
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["3412" "Wed" "20" "August" "1997" "14:14:39" "-0800" "Steve Baker" "steve@mred.bgm.link.com" nil "83" "Re: culling with view frustrum before view transformation" "^From:" nil nil "8" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mailhub.cts.com (mailhub.cts.com [204.216.216.130])
|
||||
by meserv.me.umn.edu (8.8.6/8.8.6) with SMTP id QAA04291
|
||||
for <curt@me.umn.edu>; Wed, 20 Aug 1997 16:34:23 -0500 (CDT)
|
||||
Received: from donews.cts.com(really [192.188.72.21]) by mailhub.cts.com
|
||||
via smail with smtp
|
||||
id <m0x1IGC-000Y2Ba@mailhub.cts.com>
|
||||
for <curt@me.umn.edu>; Wed, 20 Aug 97 14:25:48 -0700 (PDT)
|
||||
(Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0x1IG4-000007a; Wed, 20 Aug 97 14:25 PDT
|
||||
Received: by fatcity.com (06-Aug-97/v1.0d-b55/bab) via UUCP id 0C90BB6D; Wed, 20 Aug 1997 14:14:39 -0800
|
||||
Message-ID: <F001.0C90BB6D.19970820141439@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: steve@mred.bgm.link.com (Steve Baker)
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Mime-Version: 1.0
|
||||
Content-Type: text/plain; charset="us-ascii"
|
||||
Content-Transfer-Encoding: 7bit
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0d, build 55; ListGuru (c) 1996-1997 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
From: steve@mred.bgm.link.com (Steve Baker)
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: culling with view frustrum before view transformation
|
||||
Date: Wed, 20 Aug 1997 14:14:39 -0800
|
||||
|
||||
> >Brian Hook wrote:
|
||||
> >> You can do bounding spheres,
|
||||
> >> bounding boxes, or a combination of both (sphere first, then box).
|
||||
> >
|
||||
> >Which is faster to test for being completely inside, outside, or
|
||||
> >partial, of the view frustrum?
|
||||
>
|
||||
> Obviously bounding sphere will be the fastest, but since it's, well, a
|
||||
> sphere, it's not going to be particularly accurate (since it's rotationally
|
||||
> invariant).
|
||||
>
|
||||
> if ( distance( obj.position, plane ) >= obj_sphere.radius )
|
||||
> trivial_reject = true;
|
||||
>
|
||||
> (I assume you also check the sign of the distance)
|
||||
|
||||
I echo your sentiments that bounding spheres are the fastest approach to
|
||||
culling to FOV frustum - also for some kinds of collision detection.
|
||||
|
||||
The most important thing to bear in mind about culling is that the first
|
||||
trivial-reject test you apply is by far the most time-critical. This test
|
||||
is always applied to more nodes than any of the subsequent tests.
|
||||
|
||||
So, do the cheapest test first.
|
||||
|
||||
This is typically the NEAR plane test. Everything behind the viewers head
|
||||
gets chopped out - and it's an especially cheap test.
|
||||
|
||||
if ( obj_sphere.center.z < near_plane - obj_sphere.radius )
|
||||
REJECT!!
|
||||
|
||||
...next do the second cheapest test (assuming you know that your database
|
||||
could possibly beyond the far clip plane)...
|
||||
|
||||
if ( obj_sphere.center.z - obj_sphere.radius > far_plane )
|
||||
REJECT!!
|
||||
|
||||
...and *then* do...
|
||||
|
||||
if ( distance( obj.position, plane ) >= obj_sphere.radius )
|
||||
REJECT!!
|
||||
|
||||
It's also useful to know that in many applications, you cull more objects from
|
||||
the left and right faces of the frustum than you do from the top and bottom - so
|
||||
test left, then right, then bottom then top.
|
||||
|
||||
Also, with bounding sphere tests, you shouldn't forget to do total-accept
|
||||
as well as total-reject tests. Once you know that an object's sphere is
|
||||
TOTALLY on screen, you don't have to descend into the daughter objects to
|
||||
cull-test them...you *know* they are all on-screen.
|
||||
|
||||
Another way to look at that it to remember which of the six possible plane tests
|
||||
didn't even touch the sphere - as you work your way down the object hierarchy,
|
||||
you can accumulate those flags and avoid even testing those planes that a parent
|
||||
sphere has already cleanly passed. If you do this then a vast percentage of
|
||||
your spheres will only need to be tested against one plane.
|
||||
|
||||
Sphere-based culling can be extremely cost-effective. It's so cheap that even if
|
||||
you feel the need to use a bounding cubeoid (or even a yet more complex shape),
|
||||
it's still worth doing a sphere-based cull first just to get rid of the trivial
|
||||
accept and reject cases.
|
||||
|
||||
|
||||
Steve Baker 817-619-1361 (Vox-Lab)
|
||||
Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
|
||||
2200 Arlington Downs Road 817-619-4028 (Fax)
|
||||
Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail)
|
||||
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
|
||||
|
||||
** Beware of Geeks bearing GIF's. **
|
||||
|
||||
|
||||
--
|
||||
Author: Steve Baker
|
||||
INET: steve@mred.bgm.link.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5030
|
||||
San Diego, California -- Public Internet Access
|
||||
-------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from).
|
||||
|
||||
From fatcity!root@news.cts.com Thu Aug 21 09:19:20 1997
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["2834" "Thu" "21" "August" "1997" "07:00:54" "-0800" "Steve Baker" "steve@mred.bgm.link.com" nil "77" "Re: culling with view FRUSTUM before view transformation" "^From:" nil nil "8" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mailhub.cts.com (mailhub.cts.com [204.216.216.130])
|
||||
by meserv.me.umn.edu (8.8.6/8.8.6) with SMTP id JAA02567
|
||||
for <curt@me.umn.edu>; Thu, 21 Aug 1997 09:19:20 -0500 (CDT)
|
||||
Received: from donews.cts.com(really [192.188.72.21]) by mailhub.cts.com
|
||||
via smail with smtp
|
||||
id <m0x1Y1o-000Wd7a@mailhub.cts.com>
|
||||
for <curt@me.umn.edu>; Thu, 21 Aug 97 07:16:00 -0700 (PDT)
|
||||
(Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0x1Y1f-0000Qaa; Thu, 21 Aug 97 07:15 PDT
|
||||
Received: by fatcity.com (06-Aug-97/v1.0d-b55/bab) via UUCP id 0C90BDD1; Thu, 21 Aug 1997 07:00:54 -0800
|
||||
Message-ID: <F001.0C90BDD1.19970821070054@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: steve@mred.bgm.link.com (Steve Baker)
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Mime-Version: 1.0
|
||||
Content-Type: text/plain; charset="us-ascii"
|
||||
Content-Transfer-Encoding: 7bit
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0d, build 55; ListGuru (c) 1996-1997 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
From: steve@mred.bgm.link.com (Steve Baker)
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: culling with view FRUSTUM before view transformation
|
||||
Date: Thu, 21 Aug 1997 07:00:54 -0800
|
||||
|
||||
> OK, this is probably explained in books etc., but what is the fastest way
|
||||
> to find the distance between a point and a plane?
|
||||
|
||||
A plane can be represented by the equation
|
||||
|
||||
Ax + By + Cz + D = 0 ;
|
||||
|
||||
A,B,C is just the surface normal of the plane and D is the shortest
|
||||
distance from the origin to the plane.
|
||||
|
||||
So, if you need to find the distance of a point from the plane, just
|
||||
imagine a new plane that goes through your test point and is parallel
|
||||
to the plane you want to test. The plane equation of that new plane would be:
|
||||
|
||||
A'x + B'y + C'z + D' = 0 ;
|
||||
|
||||
Since the two planes are parallel, their surface normals are the same, so
|
||||
|
||||
A' == A
|
||||
B' == B
|
||||
C' == C
|
||||
D' == D + distance_between_the_two_planes
|
||||
|
||||
...the only thing that's different is their D values - which differ by the
|
||||
distance of your test point from the original plane.
|
||||
|
||||
So, for a point (x,y,z), the distance from the plane (A,B,C,D) is
|
||||
|
||||
dist = D' - D
|
||||
= -A'x - B'y - C'z - D
|
||||
= -Ax - By - Cz - D
|
||||
= -( [ABC]dot[xyz] + D )
|
||||
|
||||
That's the general result - but culling to the view frustum is a very
|
||||
special case...if you are working in eye-relative coordinates (IMHO this
|
||||
is best), then since all top,bot,left,right planes of the frustum meet
|
||||
at the eye - and since the eye is at the origin (by definition), then
|
||||
D is always zero for those plane and that saves you a subtract.
|
||||
|
||||
If you are feeling even more in need of optimisation - then you can save one
|
||||
multiply per plane by realising that (for rectangular screens) one of the
|
||||
three components of the plane equation will always be zero.
|
||||
|
||||
eg for the LEFT clip plane, the Y component of the normal of the plane
|
||||
is zero, so the distance to the left or right plane is just
|
||||
|
||||
- ( A x' + C z' )
|
||||
|
||||
and to the top or bottom plane it's just:
|
||||
|
||||
- ( A x' + B y' )
|
||||
|
||||
Since you are only using this for culling, you don't need the minus sign
|
||||
so the cost of a test can be as little as two multiplies and one add
|
||||
per plane.
|
||||
|
||||
|
||||
Steve Baker 817-619-1361 (Vox-Lab)
|
||||
Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
|
||||
2200 Arlington Downs Road 817-619-4028 (Fax)
|
||||
Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail)
|
||||
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
|
||||
|
||||
** Beware of Geeks bearing GIF's. **
|
||||
|
||||
|
||||
--
|
||||
Author: Steve Baker
|
||||
INET: steve@mred.bgm.link.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5030
|
||||
San Diego, California -- Public Internet Access
|
||||
-------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from).
|
||||
|
||||
From fatcity!root@news.cts.com Fri Aug 22 08:51:10 1997
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["2087" "Fri" "22" "August" "1997" "06:31:24" "-0800" "Steve Baker" "steve@mred.bgm.link.com" nil "47" "Re: culling with view FRUSTUM before view transformation" "^From:" nil nil "8" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mailhub.cts.com (mailhub.cts.com [204.216.216.130])
|
||||
by meserv.me.umn.edu (8.8.6/8.8.6) with SMTP id IAA21767
|
||||
for <curt@me.umn.edu>; Fri, 22 Aug 1997 08:51:09 -0500 (CDT)
|
||||
Received: from donews.cts.com(really [192.188.72.21]) by mailhub.cts.com
|
||||
via smail with smtp
|
||||
id <m0x1u2d-000Wk7a@mailhub.cts.com>
|
||||
for <curt@me.umn.edu>; Fri, 22 Aug 97 06:46:19 -0700 (PDT)
|
||||
(Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0x1u2a-0000PHa; Fri, 22 Aug 97 06:46 PDT
|
||||
Received: by fatcity.com (06-Aug-97/v1.0d-b55/bab) via UUCP id 0C90C1C4; Fri, 22 Aug 1997 06:31:24 -0800
|
||||
Message-ID: <F001.0C90C1C4.19970822063124@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: steve@mred.bgm.link.com (Steve Baker)
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Mime-Version: 1.0
|
||||
Content-Type: text/plain; charset="us-ascii"
|
||||
Content-Transfer-Encoding: 7bit
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0d, build 55; ListGuru (c) 1996-1997 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
From: steve@mred.bgm.link.com (Steve Baker)
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: culling with view FRUSTUM before view transformation
|
||||
Date: Fri, 22 Aug 1997 06:31:24 -0800
|
||||
|
||||
> > > Actually, I find it easier to scale the whole such that D = 1, then you
|
||||
> > > only need to store the non-degenerate (A', B', C') vector (i.e., A' =
|
||||
> > > A/D, etc...). Storing a already-normalized (A, B, C) + D quadruple is
|
||||
> > > worth it only if you know before hand that the planes will never be
|
||||
> > > scaled before their normals are used. In the general case where a
|
||||
> > > scaling is possible, you'll have to renormalize anyway.
|
||||
> >
|
||||
> > Normally, I might agree with you - but in the case of Frustum clipping,
|
||||
> > scaling the normal by dividing by 'D' is a bad move since D==0 in the
|
||||
> > case of all four 'interesting' planes. :-)
|
||||
>
|
||||
> Interesting point. This is of course only true when the eyepoint is in
|
||||
> the origin, which brings us back to the issue of clipping before or
|
||||
> after the modelview transformation.
|
||||
|
||||
Well - that's a dangerous thing to assume - I mean, the eye might just happen
|
||||
to move to the true world coordinate origin (by flook) and crash your program
|
||||
with a bunch of divide by zero errors.
|
||||
|
||||
In any case, you are going to run into nasty precision problems as your eye
|
||||
approaches the origin - even if it doesn't reach it.
|
||||
|
||||
> Learn something new every day.... :-)
|
||||
|
||||
...Forget something important every night... :-)
|
||||
|
||||
|
||||
Steve Baker 817-619-1361 (Vox-Lab)
|
||||
Hughes Training Inc. 817-619-8776 (Vox-Office/Vox-Mail)
|
||||
2200 Arlington Downs Road 817-619-4028 (Fax)
|
||||
Arlington, Texas. TX 76005-6171 Steve@MrEd.bgm.link.com (eMail)
|
||||
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
|
||||
|
||||
** Beware of Geeks bearing GIF's. **
|
||||
|
||||
|
||||
--
|
||||
Author: Steve Baker
|
||||
INET: steve@mred.bgm.link.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5030
|
||||
San Diego, California -- Public Internet Access
|
||||
-------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from).
|
||||
|
||||
71
Hints/endian-ness
Normal file
71
Hints/endian-ness
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
From fatcity!root@news.cts.com Fri May 15 08:52:18 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["1426" "Fri" "15" "May" "1998" "06:30:53" "-0800" "Steve Baker" "sbaker@link.com" nil "39" "Re: Endian swapping" "^From:" nil nil "5" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id IAA18883
|
||||
for <curt@me.umn.edu>; Fri, 15 May 1998 08:52:18 -0500 (CDT)
|
||||
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id GAA12800; Fri, 15 May 1998 06:52:14 -0700 (PDT)
|
||||
Received: from donews.cts.com (root@donews.cts.com [192.188.72.21])
|
||||
by king.cts.com (8.8.7/8.8.7) with SMTP id GAA18786;
|
||||
Fri, 15 May 1998 06:52:13 -0700 (PDT)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0yaKtA-00001sa; Fri, 15 May 98 06:51 PDT
|
||||
Received: by fatcity.com (10-Feb-1998/v1.0f-b64/bab) via UUCP id 00027B2C; Fri, 15 May 1998 06:30:53 -0800
|
||||
Message-ID: <F001.00027B2C.19980515063053@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: Steve Baker <sbaker@link.com>
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0f, build 64; ListGuru (c) 1996-1998 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
Mime-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 7bit
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: Endian swapping
|
||||
Date: Fri, 15 May 1998 06:30:53 -0800
|
||||
|
||||
On Fri, 15 May 1998, Sean L. Palmer wrote:
|
||||
|
||||
> I'm trying to make this library as cross-platform as humanly possible with
|
||||
> my limited resources, so if anyone has any code to detect whether the target
|
||||
> is Big- or Little-endian, please e-mail it my way.
|
||||
|
||||
/*
|
||||
Return TRUE if this machine is little endian,
|
||||
FALSE otherwise.
|
||||
*/
|
||||
|
||||
int is_little_endian ()
|
||||
{
|
||||
int i = 1 ;
|
||||
|
||||
return *((char *) &i) ;
|
||||
}
|
||||
|
||||
...this works because the address of an integer on a little-endian machine is
|
||||
the address of the low order byte (whose value is 1) and on a big-endian machine,
|
||||
it's the address of the high order byte (whose value is 0).
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
--
|
||||
Author: Steve Baker
|
||||
INET: sbaker@link.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5051 FAX: (619) 538-5051
|
||||
San Diego, California -- Public Internet access / Mailing Lists
|
||||
--------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from). You may
|
||||
also send the HELP command for other information (like subscribing).
|
||||
|
||||
186
Hints/gamma
Normal file
186
Hints/gamma
Normal file
|
|
@ -0,0 +1,186 @@
|
|||
From owner-flight-gear@me.umn.edu Thu Apr 23 08:45:16 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["7258" "Thu" "23" "April" "1998" "09:44:56" "-0500" "Steve Baker" "sbaker@link.com" nil "158" "Re: [FGFS] lighting question" "^From:" nil nil "4" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: (from majordom@localhost)
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) id IAA05148
|
||||
for flight-gear-outgoing; Thu, 23 Apr 1998 08:45:16 -0500 (CDT)
|
||||
X-Authentication-Warning: meserv.me.umn.edu: majordom set sender to owner-flight-gear@me.umn.edu using -f
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id IAA05144
|
||||
for <flight-gear@me.umn.edu>; Thu, 23 Apr 1998 08:45:10 -0500 (CDT)
|
||||
Received: from sutcliffe.bgm.link.com (sutcliffe.bgm.link.com [130.210.236.18])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id IAA29813 for <flight-gear@me.umn.edu>; Thu, 23 Apr 1998 08:44:39 -0500 (CDT)
|
||||
X-Sender: steve@sutcliffe.bgm.link.com
|
||||
In-Reply-To: <199804230119.UAA13239@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980423090051.6888D-100000@sutcliffe.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Precedence: bulk
|
||||
Reply-To: flight-gear@me.umn.edu
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
Sender: owner-flight-gear@me.umn.edu
|
||||
To: flight-gear@me.umn.edu
|
||||
Subject: Re: [FGFS] lighting question
|
||||
Date: Thu, 23 Apr 1998 09:44:56 -0500 (CDT)
|
||||
|
||||
On Wed, 22 Apr 1998, Curtis L. Olson wrote:
|
||||
|
||||
> Here's a lighting question for someone.
|
||||
>
|
||||
> Let's say it's noon-ish. If I set the ambient light component to
|
||||
> about 0.3 and the diffuse light component to about 1.0 I get a
|
||||
> reasonably bright scene with good contrast in the shadowy areas.
|
||||
>
|
||||
> Now, I'm running into problems when the sun is low in the sky. Even
|
||||
> with a high diffuse lighting component (1.0) the angle the sun light
|
||||
> makes with the horizontal ground is very small so the diffuse lighting
|
||||
> component ends up being virtually nothing. I'm fiddling around with
|
||||
> trying to increase the ambient component to 1.0, but I still get a
|
||||
> very dark scene.
|
||||
|
||||
...simple question - long answer - sorry...
|
||||
|
||||
First the "Why does this look bad?" answer...
|
||||
|
||||
Well, when the sun is low in the sky, that is exactly what really
|
||||
does happen - the angle between sun and (flattish) ground gets small
|
||||
and it gets dark.
|
||||
|
||||
The problem is that our eyes have automatic gain control. When the
|
||||
world gets darker, we increase our pupil apartures to increase the
|
||||
amount of light we allow in. That only works when the whole world
|
||||
goes darker - and not in a room in normal daylight containing a
|
||||
small, dim CRT.
|
||||
|
||||
Also, in the real world, the sun lights things much more brightly
|
||||
than a CRT phosphor can reproduce. When you drop that brightness
|
||||
by (say) a factor of ten because it's dusk then the sun is still
|
||||
pretty bright - but 1/10th the brightness on a CRT phosphor is pretty
|
||||
dim.
|
||||
|
||||
If you watch your sunset scenes in a darkened room, they'll look
|
||||
much better. However, for a desktop simulation, that may not help.
|
||||
|
||||
The other reason there is a problem is that the CRT phosphor is
|
||||
not a linear device - if you double the number for the pixel
|
||||
brightness - you don't get twice the brightness coming out the
|
||||
other side. This non-linearity is *supposed* to be corrected
|
||||
by a process called 'gamma correction' which works by boosting
|
||||
the contrast of the dark pixels and reducing the contrast of
|
||||
the bright ones.
|
||||
|
||||
Fixing the gamma will help noon-time scenes as well as dusk
|
||||
and dawn since the amount of stuff you can see in shadowed
|
||||
areas will be better if the gamma is set right.
|
||||
|
||||
The required amount of gamma modification changes with the
|
||||
age of the CRT and which particular choice of phosphor layer
|
||||
the CRT manufacturer made. You may also need more gamma correction
|
||||
in (say) the BLUE channel than in RED or GREEN.
|
||||
|
||||
Fancy machines like SGI ONYX's have hardware gamma tables on
|
||||
the output of the machine to do this correction - I doubt that
|
||||
all the PC-based 'toy' 3D cards have this feature.
|
||||
|
||||
Now, the "What can we do to improve matters?" answer...
|
||||
|
||||
Well, you seem to be on the right track - you basically have to increase
|
||||
the ambient light to make up for the missing light on the horizontal
|
||||
surfaces. However, this tends to reduce the amount of contrast between
|
||||
the dark regions and the vertical surfaces that are being brightly lit
|
||||
just as the sun goes down. That is the opposite of the real world since
|
||||
the shadows are much more contrasty late in the day than they are at noon.
|
||||
(That is a subjective thing - I could be wrong about that)
|
||||
|
||||
You said:
|
||||
|
||||
> I'm fiddling around with trying to increase the ambient component to 1.0,
|
||||
> but I still get a very dark scene.
|
||||
|
||||
...that suprises me - you ought to be getting a very bright scene
|
||||
with ambient==1.0 since all surfaces are being lit with a very bright
|
||||
light that is ignoring their orientation. The scene should be brighter
|
||||
than at noon.
|
||||
|
||||
Perhaps you don't have the ambient component of the glMaterial set
|
||||
up right?
|
||||
|
||||
On the gamma front, there are two experiments you can try:
|
||||
|
||||
Curt: I know you have access to an SGI RE2 machine - and that
|
||||
you can run FGFS on it. So, run FGFS up and set the time of
|
||||
day to dusk - so you have the too-dark scene. Now open another
|
||||
shell window and try running 'gamma 1.0' then 'gamma 1.5' then
|
||||
'gamma 2.0'. If I'm right about the gamma setting being the problem
|
||||
then gamma 1.0 should look just like it does on the PC, and
|
||||
(depending on the age of your CRT), 1.5 or 2.0 (or something like
|
||||
that) should make it look much better.
|
||||
|
||||
If you can't get to an SGI machine then do a screen dump of your
|
||||
image into a file, then load that file into Xview (under Linux)
|
||||
or something like photoshop. Image processing programs like this
|
||||
usually let you change the gamma for an image interactively by
|
||||
recomputing the pixels (this eliminates the need for gamma hardware).
|
||||
In XView, pick the colour editor window and click on the gamma
|
||||
button next to the intensity graph. Type in 2.0 (or whatever) and
|
||||
you'll notice that the curve in the window looks like this:
|
||||
|
||||
|
||||
****
|
||||
**
|
||||
*
|
||||
*
|
||||
*
|
||||
*
|
||||
*
|
||||
*
|
||||
*
|
||||
|
||||
(pardon the ASCII art)
|
||||
|
||||
....which means that the dark areas have been increased in contrast
|
||||
and the light areas reduced in contrast.
|
||||
|
||||
If either of these tests shows that gamma is indeed your problem then
|
||||
you need to think about how to set the gamma on your hardware.
|
||||
|
||||
For software OpenGL with Mesa - I think Mesa has a gamma setting
|
||||
extension (or an environment variable or something) - the 3Dfx
|
||||
card (IIRC) has a way to set the gamma too - although I don't
|
||||
know how. The general way to set the gamma is not through OpenGL,
|
||||
so doing this in a portable way from inside FGFS is going to be hard.
|
||||
You may have to rely on the user setting it up in some external
|
||||
tool (a windoze control panel most likely).
|
||||
|
||||
> I may have something fouled up, or may not understand something
|
||||
> correctly, but does anyone have any suggestions as to what the ambient
|
||||
> and diffuse lighting components ought to be set to in order for the
|
||||
> scenery to be "realistically" lit when the sun is low in the sky?
|
||||
|
||||
Well, 'realistically' is a hard thing - the human eye can discern detail
|
||||
in a scene lit at a gazillion candelas - all the way down to a gazillionth
|
||||
of a candela, lots of orders of magnitude. A CRT can only display the
|
||||
number of brightness levels provided in the frame buffer (256 if you are
|
||||
lucky - a mere 2.5 orders of magnitude) - and is VERY dim in any case.
|
||||
|
||||
Getting 'realistic' brightnesses just isn't going to happen on a desktop
|
||||
display system - so it's all a matter of compromise.
|
||||
|
||||
On 'real' flight simulators, the fight for better contrast and brightness
|
||||
and more orders of magnitude of brightness variation is a continual battle
|
||||
that results in some pretty exotic display technologies. (Things like
|
||||
shining an arc-lamp onto a million tiny mirrors that are tilted using
|
||||
pizo-electric effects to modulate the brightness...ugh!)
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
-------------------------------------
|
||||
Please visit the FGFS web page: http://www.menet.umn.edu/~curt/fgfs/
|
||||
For help on using this list (especially unsubscribing), send a message to
|
||||
"flight-gear-request@me.umn.edu" with a single line of text: "help".
|
||||
|
||||
73
Hints/joystick
Normal file
73
Hints/joystick
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
From owner-fgfs-devel@flightgear.org Mon Sep 14 10:44:02 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["1542" "Mon" "14" "September" "1998" "10:41:38" "-0500" "Steve Baker" "sbaker@link.com" nil "42" "Re: FGFS: Windows Joystick support" "^From:" nil nil "9" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mailhub.woodsoup.org (IDENT:root@anduin.physics.iastate.edu [129.186.82.1])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id KAA21095
|
||||
for <curt@me.umn.edu>; Mon, 14 Sep 1998 10:44:00 -0500 (CDT)
|
||||
Received: from majordom by mailhub.woodsoup.org with local (Exim 1.92 #1)
|
||||
for fgfs-devel-outgoing@flightgear.org
|
||||
id 0zIamX-0005os-00; Mon, 14 Sep 1998 10:43:13 -0500
|
||||
Received: from bgm.link.com ([130.210.2.10] helo=lfkw10.bgm.link.com)
|
||||
by mailhub.woodsoup.org with esmtp (Exim 1.92 #1)
|
||||
for fgfs-devel@flightgear.org
|
||||
id 0zIamW-0005ok-00; Mon, 14 Sep 1998 10:43:12 -0500
|
||||
Received: from samantha.bgm.link.com (samantha.bgm.link.com [130.210.65.19])
|
||||
by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
|
||||
id KAA21757; Mon, 14 Sep 1998 10:42:23 -0500 (CDT)
|
||||
X-Sender: steve@samantha.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <3.0.5.32.19980913154136.007e8440@umr.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980914103259.11905A-100000@samantha.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Precedence: bulk
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
Sender: owner-fgfs-devel@flightgear.org
|
||||
To: William Riley <riley@technologist.com>
|
||||
cc: fgfs-devel@flightgear.org
|
||||
Subject: Re: FGFS: Windows Joystick support
|
||||
Date: Mon, 14 Sep 1998 10:41:38 -0500 (CDT)
|
||||
|
||||
On Sun, 13 Sep 1998, William Riley wrote:
|
||||
|
||||
> Is anyone working on joystick support for Win9x/NT? I'm a fledgling
|
||||
> programmer and was thinking about tacking this task. If anyone has started
|
||||
> (or finished) please email me directly or through the list. Thanks.
|
||||
|
||||
There is basic joystick support in GLUT - I presume the simplest thing
|
||||
to do to start with is to use that since the result will be portable to
|
||||
all of our target systems.
|
||||
|
||||
The downside is that IIRC, GLUT only supports a very simple joystick
|
||||
setup (single stick, two axes, two buttons).
|
||||
|
||||
Whatever API we finally choose needs to consider the portability issues.
|
||||
|
||||
IMHO, it would be better to extend GLUT and offer any improvements back
|
||||
into the general Freeware community rather than to settle on an ad'hoc
|
||||
FGFS-specific solution.
|
||||
|
||||
Joystick info for Linux can be found here:
|
||||
|
||||
http://atrey.karlin.mff.cuni.cz/~vojtech/joystick/
|
||||
|
||||
Joystick programming info for Windoze is here:
|
||||
|
||||
http://www.hut.fi/Misc/Electronics/docs/joystick/pc_joystick.html#programming
|
||||
|
||||
That same site has a TON of interesting joystick info:
|
||||
|
||||
http://www.hut.fi/Misc/Electronics/docs/joystick/
|
||||
|
||||
GLUT's joystick support is not documented yet since it's only present in the
|
||||
very latest GLUT 3.7 beta. However, if you check the source code for that
|
||||
release of GLUT, you'll see how it's done there.
|
||||
|
||||
|
||||
Steve Baker (817)619-2657 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
|
||||
288
Hints/lights.c
Normal file
288
Hints/lights.c
Normal file
|
|
@ -0,0 +1,288 @@
|
|||
From curt@infoplane.com Fri Nov 13 06:10:29 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["6615" "Fri" "13" "November" "1998" "06:10:23" "-0600" "curt@infoplane.com" "curt@infoplane.com" nil "271" "fuzzy-light-effect" "^From:" nil nil "11" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from dorthy.state.net (dorthy.state.net [209.234.62.254])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id GAA15847
|
||||
for <curt@me.umn.edu>; Fri, 13 Nov 1998 06:10:28 -0600 (CST)
|
||||
Received: from sledge.infoplane.com (curt@sledge.infoplane.com [204.120.151.21]) by dorthy.state.net (8.8.8/8.7.2) with ESMTP id GAA25998 for <curt@me.umn.edu>; Fri, 13 Nov 1998 06:10:08 -0600 (CST)
|
||||
Received: (from curt@localhost)
|
||||
by sledge.infoplane.com (8.8.8/8.8.8/Debian/GNU) id GAA24798
|
||||
for curt@me.umn.edu; Fri, 13 Nov 1998 06:10:23 -0600
|
||||
Message-Id: <199811131210.GAA24798@sledge.infoplane.com>
|
||||
From: curt@infoplane.com
|
||||
To: curt@me.umn.edu
|
||||
Subject: fuzzy-light-effect
|
||||
Date: Fri, 13 Nov 1998 06:10:23 -0600
|
||||
|
||||
/* stars - draws a twisting sphere of eerie lights
|
||||
Copyright (C) 1998 James Bowman
|
||||
|
||||
stars is free software; you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation; either version 2, or (at your option)
|
||||
any later version.
|
||||
|
||||
gpasm is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with gpasm; see the file COPYING. If not, write to
|
||||
the Free Software Foundation, 59 Temple Place - Suite 330,
|
||||
Boston, MA 02111-1307, USA. */
|
||||
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
#include <math.h> /* for cos(), sin(), and sqrt() */
|
||||
#include <assert.h>
|
||||
#ifdef WIN32
|
||||
#include <time.h>
|
||||
#else
|
||||
#include <sys/time.h>
|
||||
#endif
|
||||
#include <GL/glut.h>
|
||||
|
||||
static int phi; /* Global clock */
|
||||
static int texWidth = 64; /* 64x64 is plenty */
|
||||
|
||||
/************************************************************************/
|
||||
|
||||
/* Generate a pleasing, light-shaped texture. */
|
||||
|
||||
static void
|
||||
setTexture(void)
|
||||
{
|
||||
int texSize;
|
||||
void *textureBuf;
|
||||
GLubyte *p;
|
||||
int i,j;
|
||||
double radius;
|
||||
|
||||
texSize = texWidth*texWidth;
|
||||
|
||||
textureBuf = malloc(texSize);
|
||||
if (NULL == textureBuf) return;
|
||||
|
||||
p = (GLubyte *)textureBuf;
|
||||
|
||||
radius = (double)(texWidth / 2);
|
||||
|
||||
for (i=0; i < texWidth; i++) {
|
||||
for (j=0; j < texWidth; j++) {
|
||||
double x, y, d;
|
||||
|
||||
x = fabs((double)(i - (texWidth / 2)));
|
||||
y = fabs((double)(j - (texWidth / 2)));
|
||||
|
||||
d = sqrt((x * x) + (y * y));
|
||||
if (d < radius) {
|
||||
double t = 1.0 - (d / radius); /* t is 1.0 at center,
|
||||
0.0 at edge */
|
||||
|
||||
/* inverse square looks nice */
|
||||
*p = (int)((double)0xff * (t * t));
|
||||
} else
|
||||
*p = 0x00;
|
||||
p++;
|
||||
}
|
||||
}
|
||||
|
||||
gluBuild2DMipmaps(GL_TEXTURE_2D, 1, texWidth, texWidth,
|
||||
GL_LUMINANCE,
|
||||
GL_UNSIGNED_BYTE, textureBuf);
|
||||
free(textureBuf);
|
||||
}
|
||||
|
||||
/************************************************************************/
|
||||
|
||||
static int W, H;
|
||||
|
||||
#define NUM_STARS 100
|
||||
|
||||
#define frand() ((float)(rand() & 0xfff) / (float)0x1000) /* 0.0 - 1.0 */
|
||||
#define frand2() (1.0f - (2.0f * frand())) /* -1 - +1 */
|
||||
|
||||
/* Normalise the input vector */
|
||||
static void vecNormalise(float *vv)
|
||||
{
|
||||
double mag;
|
||||
|
||||
mag = sqrt((vv[0] * vv[0]) + (vv[1] * vv[1]) + (vv[2] * vv[2]));
|
||||
vv[0] /= mag;
|
||||
vv[1] /= mag;
|
||||
vv[2] /= mag;
|
||||
}
|
||||
|
||||
void
|
||||
redraw_viewing(void)
|
||||
{
|
||||
static int cold = 1;
|
||||
static float stars[NUM_STARS * 3];
|
||||
GLfloat fb_buffer[NUM_STARS * 4];
|
||||
int i;
|
||||
|
||||
if (cold) {
|
||||
/* Position all the stars more-or-less randomly on the surface
|
||||
* of a unit sphere. */
|
||||
for (i = 0; i < NUM_STARS; i++) {
|
||||
stars[3 * i + 0] = frand2();
|
||||
stars[3 * i + 1] = frand2();
|
||||
stars[3 * i + 2] = frand2();
|
||||
vecNormalise(&stars[3 * i]);
|
||||
}
|
||||
cold = 0;
|
||||
}
|
||||
|
||||
glClear(GL_COLOR_BUFFER_BIT);
|
||||
|
||||
/* First use feedback to determine the screen positions of the
|
||||
stars. */
|
||||
glFeedbackBuffer(NUM_STARS * 4, GL_3D, fb_buffer);
|
||||
glRenderMode(GL_FEEDBACK);
|
||||
|
||||
glMatrixMode(GL_MODELVIEW);
|
||||
glPushMatrix();
|
||||
glRotatef(phi % 360, 0.0f, 1.0f, 0.0f); /* Constant spin */
|
||||
glRotatef(sin((double)phi / 300.0) * 150.0, /* Periodic twist */
|
||||
0.1f, 0.6f, -0.5f);
|
||||
glBegin(GL_POINTS);
|
||||
for (i = 0; i < NUM_STARS; i++)
|
||||
glVertex3fv(&stars[3 * i]);
|
||||
glEnd();
|
||||
glPopMatrix();
|
||||
glRenderMode(GL_RENDER); /* No more feedback */
|
||||
|
||||
/* Now draw the stars as sprites. */
|
||||
glEnable(GL_TEXTURE_2D);
|
||||
glEnable(GL_BLEND); /* Simple additive blend is fine */
|
||||
glBlendFunc(GL_ONE, GL_ONE);
|
||||
|
||||
/* Choose a color triple like this so that when the sprites overlap
|
||||
* and the color saturates, red will clamp first, then green, then
|
||||
* blue. */
|
||||
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
|
||||
glColor3f(1.0f, 0.75f, 0.5f);
|
||||
|
||||
/* Set up projection and modelview matrix that gives us a 1:1
|
||||
* mapping to screen coordinates. */
|
||||
glMatrixMode(GL_PROJECTION);
|
||||
glPushMatrix();
|
||||
glLoadIdentity();
|
||||
glMatrixMode(GL_MODELVIEW);
|
||||
glPushMatrix();
|
||||
glLoadIdentity();
|
||||
glScalef(2.0f / (GLfloat)W, 2.0f / (GLfloat)H, 1.0f);
|
||||
glTranslatef(0.5f * -(GLfloat)W, 0.5f * -(GLfloat)H, 0.0f);
|
||||
|
||||
{
|
||||
float width;
|
||||
float x, y, z;
|
||||
int i;
|
||||
|
||||
glBegin(GL_QUADS);
|
||||
|
||||
for (i = 0; i < NUM_STARS; i++) {
|
||||
/* Skip the GL_POINT_TOKEN */
|
||||
x = fb_buffer[4 * i + 1];
|
||||
y = fb_buffer[4 * i + 2];
|
||||
z = fb_buffer[4 * i + 3];
|
||||
|
||||
width = 10.0 * (2.0 - z); /* Arbitrary distance attenuation */
|
||||
|
||||
glTexCoord2f(0.0f, 0.0f);
|
||||
glVertex2f(x - width, y - width);
|
||||
|
||||
glTexCoord2f(1.0f, 0.0f);
|
||||
glVertex2f(x + width, y - width);
|
||||
|
||||
glTexCoord2f(1.0f, 1.0f);
|
||||
glVertex2f(x + width, y + width);
|
||||
|
||||
glTexCoord2f(0.0f, 1.0f);
|
||||
glVertex2f(x - width, y + width);
|
||||
}
|
||||
|
||||
glEnd();
|
||||
}
|
||||
|
||||
glMatrixMode(GL_MODELVIEW);
|
||||
glPopMatrix();
|
||||
glMatrixMode(GL_PROJECTION);
|
||||
glPopMatrix();
|
||||
|
||||
glutSwapBuffers();
|
||||
}
|
||||
|
||||
void
|
||||
reshape_viewing(int w, int h)
|
||||
{
|
||||
glViewport(0, 0, w, h);
|
||||
W = w;
|
||||
H = h;
|
||||
}
|
||||
|
||||
/************************************************************************/
|
||||
|
||||
void
|
||||
animate(void)
|
||||
{
|
||||
phi++;
|
||||
redraw_viewing();
|
||||
}
|
||||
|
||||
void
|
||||
key(unsigned char key, int x, int y)
|
||||
{
|
||||
switch (key) {
|
||||
case 27:
|
||||
case 'q':
|
||||
exit(0);
|
||||
}
|
||||
}
|
||||
|
||||
int
|
||||
main(int argc, char **argv)
|
||||
{
|
||||
glutInit(&argc, argv);
|
||||
|
||||
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE);
|
||||
glutInitWindowSize(640, 480);
|
||||
|
||||
glutCreateWindow("stars");
|
||||
glutReshapeFunc(reshape_viewing);
|
||||
glutDisplayFunc(redraw_viewing);
|
||||
|
||||
glutIdleFunc(animate);
|
||||
glutKeyboardFunc(key);
|
||||
|
||||
glDisable(GL_DEPTH_TEST);
|
||||
glDisable(GL_LIGHTING);
|
||||
|
||||
glMatrixMode(GL_MODELVIEW);
|
||||
|
||||
setTexture();
|
||||
glTexParameteri(GL_TEXTURE_2D,
|
||||
GL_TEXTURE_MIN_FILTER,
|
||||
GL_LINEAR_MIPMAP_NEAREST);
|
||||
glTexParameteri(GL_TEXTURE_2D,
|
||||
GL_TEXTURE_MAG_FILTER,
|
||||
GL_LINEAR);
|
||||
|
||||
glMatrixMode(GL_PROJECTION);
|
||||
gluPerspective( /* field of view in degree */ 40.0f,
|
||||
/* aspect ratio */ 1.0f,
|
||||
/* Z near */ 3.0f,
|
||||
/* Z far */ 5.0f);
|
||||
glMatrixMode(GL_MODELVIEW);
|
||||
gluLookAt(0.0f, 0.0f, 4.0f, /* eye position */
|
||||
0.0f, 0.0f, 0.0f, /* looking at */
|
||||
0.0f, 1.0f, 0.0f); /* up vector */
|
||||
|
||||
glutMainLoop();
|
||||
return 0; /* ANSI C requires main to return int. */
|
||||
}
|
||||
|
||||
118
Hints/mip-mapping
Normal file
118
Hints/mip-mapping
Normal file
|
|
@ -0,0 +1,118 @@
|
|||
From sbaker@link.com Thu Mar 12 22:51:27 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["4342" "Thu" "12" "March" "1998" "22:50:07" "-0600" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980312222643.15355F-100000@lechter.bgm.link.com>" "95" "Re: Texturing (finally)" "^From:" nil nil "3" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id WAA13969
|
||||
for <curt@me.umn.edu>; Thu, 12 Mar 1998 22:51:26 -0600 (CST)
|
||||
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id WAA25775 for <curt@me.umn.edu>; Thu, 12 Mar 1998 22:50:51 -0600 (CST)
|
||||
X-Sender: steve@lechter.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199803121856.MAA05616@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980312222643.15355F-100000@lechter.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Status: RO
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: Texturing (finally)
|
||||
Date: Thu, 12 Mar 1998 22:50:07 -0600 (CST)
|
||||
|
||||
On Thu, 12 Mar 1998, Curtis L. Olson wrote:
|
||||
|
||||
> Steve Baker writes:
|
||||
> > So you have the texture into OpenGL using glGenTextures /
|
||||
> > glBindTexture and you have a number for each texture? Does the
|
||||
> > routine generate the MIPmaps for you?
|
||||
>
|
||||
> I found some code that looks like it might do the mipmapping ... I'll
|
||||
> fiddle around with that a bit if I get a chance.
|
||||
|
||||
Once you have an image in memory, the code in the RedBook is all you need.
|
||||
|
||||
There is a glu function for generating the MIPmaps. It works OK for
|
||||
starters - but eventually you'll want to rewrite it. Since the sources
|
||||
for glu are provided with Mesa (and they work with ANY OpenGL), you
|
||||
can easily take the standard glu code and hack it yourself later.
|
||||
|
||||
The main thing that I find I need to do with MIPmapping is to control
|
||||
the final alpha value of MIPmapped transparency textures. Simply averaging
|
||||
all the high level texel Alpha's together to get the lowest LOD doesn't
|
||||
work very well in some applications for translucent texture.
|
||||
|
||||
However, that won't matter to you for a LONG while yet - so just steal
|
||||
the RedBook examples.
|
||||
|
||||
> > As a starter (just to get something going), you could simply divide
|
||||
> > the latitude and longitude of each terrain vertex by some suitable
|
||||
> > constant and use that as the texture coordinate. Alternatively, you
|
||||
> > could let OpenGL do the work using glTexGenf.
|
||||
>
|
||||
> Tell me more about glTexGenf().
|
||||
|
||||
I have to come clean here and mention that I have never actually used
|
||||
glTexGenf.
|
||||
|
||||
Basically, it provides a mechanism where OpenGL will generate the
|
||||
texture coordinates for you automatically using other vertex information.
|
||||
I forget all the modes it has - but IIRC, one of them allows you to specify
|
||||
the equation of a plane (A,B,C,D where: Ax+By+Cz+D==0) - and the texture
|
||||
coordinates are computed by projecting each vertex (x,y,z) onto that
|
||||
plane.
|
||||
|
||||
If you set that plane to be a plane that is tangential to the earth
|
||||
at the center of the terrain tile that you are rendering, then the
|
||||
texture would 'drape' itself nicely over the terrain - but there would
|
||||
be seams at the edge of each tile.
|
||||
|
||||
> All my coordinates come off the disk
|
||||
> in (X, Y, Z) so it would take some computational effort to convert
|
||||
> back to lon/lat ...
|
||||
|
||||
Yes - you'd need to store (X,Y,Z,S,T) for each vertex on disk and compute
|
||||
the texture coordinates in the terrain tool. You'd need to do that
|
||||
eventually anyway since the number you use to multiply the lat/long
|
||||
to convert to S,T will be different for each kind of texture map - and
|
||||
for databases at different latitudes (otherwise the texture gets all
|
||||
squashed up near the poles).
|
||||
|
||||
I guess if you don't want to change your file format that much, you
|
||||
could store a matrix at the top of the file that could be used to
|
||||
transform (X,Y,Z) into (S,T,garbage). But that's really the same
|
||||
thing as using glTexGen to do the work - and you'll still get seams
|
||||
at the edge of every terrain tile whenever the matrix changes.
|
||||
|
||||
Since OpenGL supports the idea of a texture matrix, you could simply
|
||||
load your per-tile matrix onto the OpenGL texture matrix stack and
|
||||
use glTexCoord3f(x,y,z) [where (x,y,z) is the same vertex coordinate
|
||||
that you pass to glVertex3f()].
|
||||
|
||||
However, in your quest to DO THE RIGHT THING, there is little choice
|
||||
but to store the texture S,T in the file along with the other vertex
|
||||
information - any other approach is going to produce seams in the texture
|
||||
and sooner or later, you'll get dissatisfied with that.
|
||||
|
||||
I suggest that in the short term, you use the texture matrix approach
|
||||
since that gets you a textured image *quickly*. It will also let you
|
||||
debug the texture loader, the MIPmapping, the glTexBind, etc stuff
|
||||
and so on. You'll be able to find some nice textures and make some
|
||||
new (and v.cool) screen shots. Switching to stored (S,T) coords is
|
||||
something you can attack later when the seams get too annoying.
|
||||
|
||||
> Right now I'm using fg_random() to specify
|
||||
> texture coordinates :-) It seems to work, but has some strange
|
||||
> effects. :-)
|
||||
|
||||
Strange!!...I'm not suprised!
|
||||
|
||||
Steve Baker 817-619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. 817-619-4028 (Fax)
|
||||
2200 Arlington Downs Road SBaker@link.com (eMail)
|
||||
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
|
||||
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
|
||||
|
||||
** Beware of Geeks bearing GIF's. **
|
||||
|
||||
|
||||
101
Hints/nmea
Normal file
101
Hints/nmea
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
From curt@me.umn.edu Fri Nov 13 17:02:31 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["209" "Fri" "13" "November" "1998" "17:02:29" "-0600" "Curtis L. Olson" "curt@me.umn.edu" nil "6" "nmea stuff 3" "^From:" nil nil "11" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from kenai.me.umn.edu (curt@kenai.me.umn.edu [134.84.18.22])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id RAA29774
|
||||
for <curt@me.umn.edu>; Fri, 13 Nov 1998 17:02:31 -0600 (CST)
|
||||
Received: (from curt@localhost)
|
||||
by kenai.me.umn.edu (8.9.1/8.9.1) id RAA32468;
|
||||
Fri, 13 Nov 1998 17:02:30 -0600
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=us-ascii
|
||||
Content-Transfer-Encoding: 7bit
|
||||
Message-ID: <13900.47749.734021.549964@kenai.me.umn.edu>
|
||||
X-Mailer: VM 6.61 under Emacs 19.34.1
|
||||
From: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
To: curt@me.umn.edu
|
||||
Subject: nmea stuff 3
|
||||
Date: Fri, 13 Nov 1998 17:02:29 -0600 (CST)
|
||||
|
||||
http://www.marinesoft.com/Navigation/Technical/index.htm
|
||||
--
|
||||
Curtis Olson University of MN, ME Dept.
|
||||
curt@me.umn.edu
|
||||
http://www.menet.umn.edu/~curt Try Linux!
|
||||
|
||||
From curt@me.umn.edu Fri Nov 13 16:41:49 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["730" "Fri" "13" "November" "1998" "16:41:47" "-0600" "Curtis L. Olson" "curt@me.umn.edu" nil "21" "nmea stuff 2" "^From:" nil nil "11" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from kenai.me.umn.edu (curt@kenai.me.umn.edu [134.84.18.22])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id QAA29467
|
||||
for <curt@me.umn.edu>; Fri, 13 Nov 1998 16:41:48 -0600 (CST)
|
||||
Received: (from curt@localhost)
|
||||
by kenai.me.umn.edu (8.9.1/8.9.1) id QAA32325;
|
||||
Fri, 13 Nov 1998 16:41:47 -0600
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=us-ascii
|
||||
Content-Transfer-Encoding: 7bit
|
||||
Message-ID: <13900.46507.212248.131431@kenai.me.umn.edu>
|
||||
X-Mailer: VM 6.61 under Emacs 19.34.1
|
||||
From: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
To: curt@me.umn.edu
|
||||
Subject: nmea stuff 2
|
||||
Date: Fri, 13 Nov 1998 16:41:47 -0600 (CST)
|
||||
|
||||
http://www.fet.uni-hannover.de/~purnhage/gps/gps.html
|
||||
|
||||
garman hacking project
|
||||
http://www.abnormal.com/~thogard/gps/grmnhack.html
|
||||
|
||||
nmea code documents
|
||||
http://www.oce.orst.edu/Wecoma/Docs/Computing/XMidas/Formatter_ID.html
|
||||
http://www.oce.orst.edu/Wecoma/Docs/Computing/XMidas/NMEA_0183_Format.html
|
||||
|
||||
http://www.cl.cam.ac.uk/users/ijl20/nmea.txt
|
||||
|
||||
http://www.cl.cam.ac.uk/users/ijl20/gps_file.html
|
||||
|
||||
(*) http://vancouver-webpages.com/pub/peter/index.html
|
||||
http://vancouver-webpages.com/pub/peter/idx_nmeadoc.html
|
||||
http://vancouver-webpages.com/pub/peter/nmeafaq.txt
|
||||
--
|
||||
Curtis Olson University of MN, ME Dept.
|
||||
curt@me.umn.edu
|
||||
http://www.menet.umn.edu/~curt Try Linux!
|
||||
|
||||
From curt@me.umn.edu Fri Nov 13 15:10:29 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["376" "Fri" "13" "November" "1998" "15:10:27" "-0600" "Curtis L. Olson" "curt@me.umn.edu" nil "14" "nmea stuff" "^From:" nil nil "11" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from kenai.me.umn.edu (curt@kenai.me.umn.edu [134.84.18.22])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id PAA27473
|
||||
for <curt@me.umn.edu>; Fri, 13 Nov 1998 15:10:28 -0600 (CST)
|
||||
Received: (from curt@localhost)
|
||||
by kenai.me.umn.edu (8.9.1/8.9.1) id PAA31952;
|
||||
Fri, 13 Nov 1998 15:10:27 -0600
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=us-ascii
|
||||
Content-Transfer-Encoding: 7bit
|
||||
Message-ID: <13900.41027.169267.293790@kenai.me.umn.edu>
|
||||
X-Mailer: VM 6.61 under Emacs 19.34.1
|
||||
From: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
To: curt@me.umn.edu
|
||||
Subject: nmea stuff
|
||||
Date: Fri, 13 Nov 1998 15:10:27 -0600 (CST)
|
||||
|
||||
http://pfranc.com/projects/g45contr/assemb.htm
|
||||
http://pfranc.com/ - gps connector
|
||||
http://pfranc.com/projects/g45contr/beans.htm
|
||||
|
||||
http://www.thecapn.com/
|
||||
http://www.thecapn.com/nmea.htm
|
||||
http://vancouver-webpages.com/peter/
|
||||
|
||||
|
||||
--
|
||||
Curtis Olson University of MN, ME Dept.
|
||||
curt@me.umn.edu
|
||||
http://www.menet.umn.edu/~curt Try Linux!
|
||||
|
||||
60
Hints/opengl-optimization
Normal file
60
Hints/opengl-optimization
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
Original Article: http://www.egroups.com/list/opengl-gamedev-l/?start=11533
|
||||
Ben Carter writes:
|
||||
>
|
||||
> Hmm.. Here's a question - is it worth optimising out redundant state
|
||||
> changes? In other words, if I do :
|
||||
>
|
||||
> glEnable(GL_TEXTURE_2D);
|
||||
> <something>
|
||||
> glEnable(GL_TEXTURE_2D);
|
||||
> <something else>
|
||||
|
||||
Generally, yes. There's usually a validation step that's scheduled
|
||||
after a call to glEnable(). It updates the internals caches and what
|
||||
not based on state that was set prior to the enable call. Its difficult
|
||||
to estimate what every driver does, but there's still internal updating
|
||||
that probably occurs.
|
||||
|
||||
Additionally, its much better to write, for example:
|
||||
|
||||
glLightfv( GL_LIGHT0, ... );
|
||||
glLightfv( GL_LIGHT0, ... );
|
||||
glLightfv( GL_LIGHT0, ... );
|
||||
glEnable( GL_LIGHT0 );
|
||||
glEnable( GL_LIGHTING );
|
||||
|
||||
than the opposite. Its less important to do this in initialization, but
|
||||
if you're dynamically changing things like lighting or texturing, you'll
|
||||
only validate on the glEnable(), as compared to each glLight() call if
|
||||
you glEnable() first.
|
||||
|
||||
> Is there going to be a performance hit from the second glEnable call?
|
||||
> Would it be worthwhile writing a wrapper around the state system that
|
||||
> kept the current state somewhere and only made calls that were
|
||||
> necessary, or are the drivers smart enough to do that?
|
||||
|
||||
Some drivers might be smart enough, but I think the underlying
|
||||
assumption is that its easier to just reprocess like something's
|
||||
changed, than actually try to keep track of which state's changed, and
|
||||
localize that validation.
|
||||
|
||||
The wrapper idea could be useful; I guess it depends if the apps
|
||||
design can't guard against it. FWIW.
|
||||
|
||||
Thanx,
|
||||
Dave
|
||||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
Dave Shreiner <shreiner@sgi.com>
|
||||
Silicon Graphics, Inc. (650) 933-4899
|
||||
-----
|
||||
FAQ and OpenGL Resources at:
|
||||
http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
|
||||
|
||||
--
|
||||
Author: Dave Shreiner
|
||||
INET: shreiner@sgi.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5051 FAX: (619) 538-5051
|
||||
San Diego, California -- Public Internet access / Mailing Lists
|
||||
269
Hints/polygon-offset
Normal file
269
Hints/polygon-offset
Normal file
|
|
@ -0,0 +1,269 @@
|
|||
From fatcity!root@news.cts.com Thu Mar 26 17:57:48 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["8204" "Thu" "26" "March" "1998" "15:32:55" "-0800" "akin@pobox.com" "akin@pobox.com" nil "162" "Re: poly offset " "^From:" nil nil "3" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id RAA07001
|
||||
for <curt@me.umn.edu>; Thu, 26 Mar 1998 17:57:43 -0600 (CST)
|
||||
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id PAA05457; Thu, 26 Mar 1998 15:55:40 -0800 (PST)
|
||||
Received: from donews.cts.com (root@donews.cts.com [192.188.72.21])
|
||||
by king.cts.com (8.8.7/8.8.7) with SMTP id PAA21507;
|
||||
Thu, 26 Mar 1998 15:55:38 -0800 (PST)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0yIMSJ-0000NEa; Thu, 26 Mar 98 15:53 PST
|
||||
Received: by fatcity.com (10-Feb-1998/v1.0f-b64/bab) via UUCP id 00016F4B; Thu, 26 Mar 1998 15:32:55 -0800
|
||||
Message-ID: <F001.00016F4B.19980326153255@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: akin@pobox.com
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0f, build 64; ListGuru (c) 1996-1998 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
Mime-Version: 1.0
|
||||
Content-Type: text/plain; charset="us-ascii"
|
||||
Content-Transfer-Encoding: 7bit
|
||||
From: akin@pobox.com
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: poly offset
|
||||
Date: Thu, 26 Mar 1998 15:32:55 -0800
|
||||
|
||||
|
||||
Bryan Gibson-Winge wrote:
|
||||
| I was curious to see if anyone would describe a method of using poly offset
|
||||
| that didn't eventually conclude with "and mess with the numbers 'till it
|
||||
| works".
|
||||
|
||||
There is such a method, but since it's not in any of the usual OpenGL
|
||||
literature it's not widely discussed. I'll try to summarize it; maybe
|
||||
the result could go into the FAQ.
|
||||
|
||||
The purpose of polygon offset is to separate two or more primitives
|
||||
by just enough distance in Z that they can be depth-buffered without
|
||||
artifacts caused by depth computation roundoff errors, differences in
|
||||
sampling algorithms for different types of primitives, etc.
|
||||
|
||||
The ``factor'' argument provides separation in the case where the
|
||||
primitives are not parallel. The factor value to use depends on the
|
||||
screen sizes of the primitives involved.
|
||||
|
||||
The canonical example is highlighting the edge of a triangle
|
||||
by drawing a line between the two associated triangle vertices.
|
||||
The depth value for each pixel on the line depends only on the
|
||||
depth values at the two vertices of the triangle edge. However,
|
||||
the depth value for each pixel in the triangle depends on all
|
||||
three of the triangle's vertices. Since lines and triangles are
|
||||
sampled differently (e.g. diamond-exit rule for lines vs. point
|
||||
sampling for triangles), at a given pixel the depth computed
|
||||
for the edge line usually differs from the depth computed
|
||||
for the underlying triangle. This can cause ``stitching'' or
|
||||
other unpleasant artifacts in the image, because depth buffering
|
||||
sometimes places the line in front of the triangle and sometimes
|
||||
behind it.
|
||||
|
||||
How much separation is needed to ensure that the line is always
|
||||
in front of the triangle? If you look at the rasterization
|
||||
arithmetic or play with a few diagrams, you can see that at some
|
||||
pixels the depth value for the triangle is computed at a point
|
||||
almost one pixel away from the ideal edge (which produces the
|
||||
depth values for the line). Since the triangle can have an almost
|
||||
arbitrarily large depth slope, there is no fixed offset that will
|
||||
guarantee separation between the two primitives in all cases.
|
||||
However, a (variable) separation of 1.0 times the depth slope of
|
||||
the triangle is always sufficient. (For the purposes of this
|
||||
discussion, the depth slope is max(|dz/dx|,|dz/dy|). The spec
|
||||
has additional information.) It's sometimes more than you need,
|
||||
but it's always large enough to work.
|
||||
|
||||
If the line were two pixels wide rather than one, then 1.0
|
||||
times the depth slope wouldn't be enough separation, because
|
||||
some pixels on the line might have depth values derived from an
|
||||
edge point more than one pixel away from the underlying point
|
||||
on the triangle. 2.0 would be sufficient, though.
|
||||
|
||||
So now you understand the factor argument. It should be
|
||||
nonzero when you're attempting to separate two primitives that
|
||||
aren't parallel, and its value should be roughly the size of
|
||||
the screen-space overlap (measured in pixels) between the two
|
||||
primitives. For any given triangle, the factor is multiplied
|
||||
by the triangle's depth slope to compute the amount of separation.
|
||||
|
||||
The ``units'' or ``bias'' argument provides separation in the case
|
||||
where the primitives are roughly parallel. The value to use
|
||||
depends on how many primitives you're trying to stack up.
|
||||
|
||||
Consider the edged-triangle case again. What happens when the
|
||||
depth slope of the triangle is zero? Since the depth slope is
|
||||
zero, no matter what the factor argument is, you won't get any
|
||||
separation between the triangle and the edge line. However,
|
||||
you still want some separation between the two primitives,
|
||||
so that you get a consistent result (i.e., one that doesn't
|
||||
depend on the order in which you draw things or on whether the
|
||||
depth-comparison function tests for equality).
|
||||
|
||||
The bias argument guarantees a little separation even in the case
|
||||
where the depth slope is zero. Furthermore, it generalizes to
|
||||
the case where the depth slopes of the primitives are nonzero,
|
||||
but the primitives are roughly parallel (for example, when using
|
||||
one polygon as a decal on another).
|
||||
|
||||
The original version of polygon offset allowed you to specify
|
||||
a bias that was simply added to the depth value at each pixel.
|
||||
However, it was quite difficult to choose an appropriate value,
|
||||
because the choice depends not only on the number of bits in the
|
||||
depth buffer (offsets smaller than the depth buffer precision
|
||||
don't do you much good!) but also on the precision of various
|
||||
computations inside the OpenGL driver and the hardware.
|
||||
Perspective projection can also make a difference, since
|
||||
resolution is better at the near clipping plane than it is at
|
||||
the far clipping plane.
|
||||
|
||||
The current version of polygon offset specifies the bias in
|
||||
multiples of a ``minimum resolvable difference,'' which is some
|
||||
value determined by the driver developer. The minimum resolvable
|
||||
difference is sufficient to separate two parallel primitives,
|
||||
taking into account the perspective projection, size of the
|
||||
depth buffer, hardware precision, etc.
|
||||
|
||||
Since one unit is sufficient to separate two primitives, you
|
||||
can use more than one unit to separate additional primitives.
|
||||
For example, by using bias values of 1, 2, 3, ... you can stack
|
||||
up an arbitrary set of polygons on a base polygon.
|
||||
|
||||
Since some OpenGL implementations add the bias before the
|
||||
perspective divide, a bias of 1.0 unit might be much larger
|
||||
than is needed for primitives close to the near clipping plane.
|
||||
If your app is smart enough to know exactly how the driver
|
||||
behaves, and roughly where in the view volume the primitives
|
||||
will fall, then it can use a bias of less than 1.0 to separate
|
||||
primitives close to the near clipping plane. Most of the time
|
||||
this is *not* worth the effort, though.
|
||||
|
||||
Some practical examples:
|
||||
|
||||
Drawing lines of width 1.0 pixel on the edge of a triangle
|
||||
should use a factor of 1.0 (to guarantee separation when the
|
||||
triangle depth slope is nonzero) and a bias of 1.0 (to guarantee
|
||||
separation when the triangle depth slope is zero).
|
||||
|
||||
Drawing wider lines requires larger factors. A good rule of
|
||||
thumb might be to use a factor equal to ceil(lineWidth/2 + 0.5).
|
||||
|
||||
Drawing decal polygons needs a zero factor and a nonzero bias,
|
||||
provided that you can guarantee that all of the vertices of
|
||||
the decal polygons are on the same side of the plane of the
|
||||
base polygon, and not on that plane. (If intersections occur,
|
||||
you might need a nonzero factor, because the depth slopes of
|
||||
the primitives might be different.) Use a bias of 1.0 for the
|
||||
lowest-level decal (the one closest to the base), 2.0 for the
|
||||
next-highest, and so on.
|
||||
|
||||
Positive factors and biases push primitives in one direction;
|
||||
negative factors and biases push primitives in the other
|
||||
direction. Sometimes it makes a difference (for example, if you
|
||||
want to use the values in the depth buffer for a subsequent pass).
|
||||
|
||||
If you run into trouble, the most likely cause is that the driver
|
||||
developer underestimated the value of the minimum resolvable difference.
|
||||
(I know of no way to predict this value; I think you just have to
|
||||
measure it. The basic idea is to binary-search across the range of depth
|
||||
values, drawing two parallel polygons at each stage and determining if
|
||||
depth-buffering artifacts occur. Do this once at the near plane, and
|
||||
once at the far plane, and take the largest result. Repeat for extreme
|
||||
depthrange values.) Tweaking the bias argument is probably the only
|
||||
way to resolve this. :-)
|
||||
|
||||
Finally, as Steve Baker and I have discussed in the past, the
|
||||
reference_plane extension is often a cleaner solution than polygon offset,
|
||||
if your OpenGL implementation supports it.
|
||||
|
||||
Allen
|
||||
--
|
||||
Author:
|
||||
INET: akin@pobox.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5051 FAX: (619) 538-5051
|
||||
San Diego, California -- Public Internet access / Mailing Lists
|
||||
--------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from). You may
|
||||
also send the HELP command for other information (like subscribing).
|
||||
|
||||
From fatcity!root@news.cts.com Fri Jan 16 04:45:15 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["1385" "Fri" "16" "January" "1998" "02:06:11" "-0800" "Mark Kilgard" "mjk@fangio.engr.sgi.com" nil "43" "Re: glPolygonOffset" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id EAA19075
|
||||
for <curt@me.umn.edu>; Fri, 16 Jan 1998 04:45:14 -0600 (CST)
|
||||
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id CAA19264; Fri, 16 Jan 1998 02:39:16 -0800 (PST)
|
||||
Received: from donews.cts.com (root@donews.cts.com [192.188.72.21])
|
||||
by king.cts.com (8.8.7/8.8.7) with SMTP id CAA07365;
|
||||
Fri, 16 Jan 1998 02:39:07 -0800 (PST)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0xt8sd-00008Sa; Fri, 16 Jan 98 02:20 PST
|
||||
Received: by fatcity.com (02-Jan-98/v1.0f-b63/bab) via UUCP id 0C92BDFF; Fri, 16 Jan 1998 02:06:11 -0800
|
||||
Message-ID: <F001.0C92BDFF.19980116020611@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: mjk@fangio.engr.sgi.com (Mark Kilgard)
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0f, build 63; ListGuru (c) 1996-1998 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
Mime-Version: 1.0
|
||||
Content-Type: text/plain; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 7bit
|
||||
From: mjk@fangio.engr.sgi.com (Mark Kilgard)
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: glPolygonOffset
|
||||
Date: Fri, 16 Jan 1998 02:06:11 -0800
|
||||
|
||||
opengl-gamedev,
|
||||
|
||||
> At one time I came across web site with example for glPolygonOffset, but I
|
||||
> can not find it again. Does anybody know web site.
|
||||
|
||||
Polygon offset is used to "lift" the projected planar shadows off of
|
||||
the floor to avoid Z fighting in my dinoshade.c example. See:
|
||||
|
||||
http://reality.sgi.com/mjk/tips/TexShadowReflectLight.html
|
||||
|
||||
Other cool OpenGL rendering techniques are shown at:
|
||||
|
||||
http://reality.sgi.com/mjk/tips/
|
||||
|
||||
There are also several polygon offset examples in the GLUT 3.6 source
|
||||
code distribution. See:
|
||||
|
||||
http://reality.sgi.com/mjk/glut3/glut3.html
|
||||
|
||||
In particular, look at:
|
||||
|
||||
progs/examples/origami.c
|
||||
progs/examples/surfgrid.c
|
||||
progs/examples/dinoshade.c
|
||||
progs/examples/halomagic.c
|
||||
progs/redbook/polyoff.c
|
||||
progs/advanced/haloed.c
|
||||
|
||||
I hope this helps.
|
||||
|
||||
- Mark
|
||||
--
|
||||
Author: Mark Kilgard
|
||||
INET: mjk@fangio.engr.sgi.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5030 FAX: (619) 538-5051
|
||||
San Diego, California -- Public Internet Access
|
||||
--------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from). You may
|
||||
also send the HELP command for other information (like subscribing).
|
||||
|
||||
331
Hints/portable-sound
Normal file
331
Hints/portable-sound
Normal file
|
|
@ -0,0 +1,331 @@
|
|||
From fatcity!root@news.cts.com Mon Jan 5 14:50:59 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["1623" "Mon" "5" "January" "1998" "12:03:38" "-0800" "Chris Schoeneman" "crs@millpond.engr.sgi.com" "<F001.0C927564.19980105120338@fatcity.com>" "41" "Re: [Q] OpenGL + Arbitrary display mode in Win32" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id OAA05604
|
||||
for <curt@me.umn.edu>; Mon, 5 Jan 1998 14:50:58 -0600 (CST)
|
||||
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id MAA20781; Mon, 5 Jan 1998 12:43:38 -0800 (PST)
|
||||
Received: from donews.cts.com (root@donews.cts.com [192.188.72.21])
|
||||
by king.cts.com (8.8.7/8.8.7) with SMTP id MAA01273;
|
||||
Mon, 5 Jan 1998 12:41:39 -0800 (PST)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0xpJ0S-0000Hga; Mon, 5 Jan 98 12:20 PST
|
||||
Received: by fatcity.com (02-Jan-98/v1.0f-b63/bab) via UUCP id 0C927564; Mon, 05 Jan 1998 12:03:38 -0800
|
||||
Message-ID: <F001.0C927564.19980105120338@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: crs@millpond.engr.sgi.com (Chris Schoeneman)
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0f, build 63; ListGuru (c) 1996-1998 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
Mime-Version: 1.0
|
||||
Content-Type: text/plain; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 8bit
|
||||
From: crs@millpond.engr.sgi.com (Chris Schoeneman)
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: [Q] OpenGL + Arbitrary display mode in Win32
|
||||
Date: Mon, 05 Jan 1998 12:03:38 -0800
|
||||
|
||||
Doty, Lee wrote:
|
||||
>
|
||||
> Any sound gurus out there? I agree that if we could get 3d sound in
|
||||
> there, life would get exponentially happier.
|
||||
|
||||
I'm willing to donate the sound code from bzflag. It's supports:
|
||||
|
||||
arbitrary number of simultaneous sounds (limited by CPU speed)
|
||||
attenuation with distance
|
||||
propagation delay
|
||||
doppler effects
|
||||
stereo panning
|
||||
|
||||
It runs in a separate thread and has a very simple interface. I have
|
||||
it running on Windows 95/NT and Irix, and Daryll Strauss ported it to
|
||||
Linux. The Windows version would work better if DirectSound didn't
|
||||
suck so bad, but it works reasonably well now.
|
||||
|
||||
A drawback is that it can suck up a lot of CPU time since it has to
|
||||
do its own filtering and mixing. It also needs support for a better
|
||||
HRTF, reverb with distance, high-frequency rolloff with distance, and
|
||||
a way to set the volume on individual sounds. That last one is trivial
|
||||
but the others are more involved.
|
||||
|
||||
Mark, you interested? I've also got fullscreen and resolution changing
|
||||
code for Irix.
|
||||
|
||||
Cheers,
|
||||
-chris
|
||||
--
|
||||
Author: Chris Schoeneman
|
||||
INET: crs@millpond.engr.sgi.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5030 FAX: (619) 538-5051
|
||||
San Diego, California -- Public Internet Access
|
||||
--------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from). You may
|
||||
also send the HELP command for other information (like subscribing).
|
||||
|
||||
From crs@millpond.engr.sgi.com Mon Jan 5 15:36:10 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["1034" "Mon" "5" "January" "1998" "13:35:59" "-0800" "Chris Schoeneman" "crs@millpond.engr.sgi.com" "<199801052135.NAA21198@millpond.engr.sgi.com>" "23" "Re: bzflag sound playing code" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from sgi.sgi.com (SGI.COM [192.48.153.1])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with SMTP id PAA07002
|
||||
for <curt@me.umn.edu>; Mon, 5 Jan 1998 15:36:07 -0600 (CST)
|
||||
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id NAA08189
|
||||
for <@sgi.engr.sgi.com:curt@me.umn.edu>; Mon, 5 Jan 1998 13:36:04 -0800
|
||||
env-from (crs@millpond.engr.sgi.com)
|
||||
Received: from millpond.engr.sgi.com (millpond.engr.sgi.com [150.166.55.67]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id NAA07557 for <@cthulhu.engr.sgi.com:curt@me.umn.edu>; Mon, 5 Jan 1998 13:36:00 -0800
|
||||
Received: (from crs@localhost) by millpond.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id NAA21198 for curt@me.umn.edu; Mon, 5 Jan 1998 13:35:59 -0800
|
||||
Message-Id: <199801052135.NAA21198@millpond.engr.sgi.com>
|
||||
In-Reply-To: <199801052103.PAA30512@kenai.me.umn.edu> from "Curtis L. Olson" at Jan 5, 98 03:03:52 pm
|
||||
X-Mailer: ELM [version 2.4 PL23]
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 8bit
|
||||
From: crs@millpond.engr.sgi.com (Chris Schoeneman)
|
||||
To: curt@me.umn.edu (Curtis L. Olson)
|
||||
Subject: Re: bzflag sound playing code
|
||||
Date: Mon, 5 Jan 1998 13:35:59 -0800 (PST)
|
||||
|
||||
Curtis L. Olson wrote:
|
||||
>
|
||||
> Is the licensing of the bzflag sound code such that I could use it to
|
||||
> build in sounds support for our project? We would want to have a
|
||||
> continuously looping engine sound (plus wind sound, and maybe rain
|
||||
> hitting the windshield sound.) Then we'd need to intersperse the
|
||||
> other sounds such as flaps, stall horn, landing gear, thunder, crash,
|
||||
> etc. It sounds like it might be exactly the sort of thing we need.
|
||||
|
||||
Hmm, it's not a perfect match. Most of your sounds are purely local,
|
||||
so you don't need the stereo panning, propagation delay, and doppler
|
||||
effect. However, that's no reason not to try it!
|
||||
|
||||
Ripping my sound code out from bzflag shouldn't be too much work
|
||||
but I'm really busy at the moment. Could you wait about a week?
|
||||
|
||||
BTW, as far as licensing goes I'd just want the copyright notice to
|
||||
stay on the source files (we'll have to tweek the legal notice) and
|
||||
a mention in the credits, if you have a credits list. A right to
|
||||
use enhancements to the code would be cool, too.
|
||||
|
||||
Cheers,
|
||||
-chris
|
||||
|
||||
From crs@millpond.engr.sgi.com Mon Jan 5 16:22:27 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["1125" "Mon" "5" "January" "1998" "14:22:22" "-0800" "Chris Schoeneman" "crs@millpond.engr.sgi.com" "<199801052222.OAA21481@millpond.engr.sgi.com>" "27" "Re: bzflag sound playing code" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from sgi.sgi.com (SGI.COM [192.48.153.1])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with SMTP id QAA08463
|
||||
for <curt@me.umn.edu>; Mon, 5 Jan 1998 16:22:26 -0600 (CST)
|
||||
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id OAA22876
|
||||
for <@sgi.engr.sgi.com:curt@me.umn.edu>; Mon, 5 Jan 1998 14:22:25 -0800
|
||||
env-from (crs@millpond.engr.sgi.com)
|
||||
Received: from millpond.engr.sgi.com (millpond.engr.sgi.com [150.166.55.67]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA25764 for <@cthulhu.engr.sgi.com:curt@me.umn.edu>; Mon, 5 Jan 1998 14:22:22 -0800
|
||||
Received: (from crs@localhost) by millpond.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id OAA21481 for curt@me.umn.edu; Mon, 5 Jan 1998 14:22:22 -0800
|
||||
Message-Id: <199801052222.OAA21481@millpond.engr.sgi.com>
|
||||
In-Reply-To: <199801052204.QAA31163@kenai.me.umn.edu> from "Curtis L. Olson" at Jan 5, 98 04:04:44 pm
|
||||
X-Mailer: ELM [version 2.4 PL23]
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 8bit
|
||||
From: crs@millpond.engr.sgi.com (Chris Schoeneman)
|
||||
To: curt@me.umn.edu (Curtis L. Olson)
|
||||
Subject: Re: bzflag sound playing code
|
||||
Date: Mon, 5 Jan 1998 14:22:22 -0800 (PST)
|
||||
|
||||
Curtis L. Olson wrote:
|
||||
>
|
||||
> Does your code support continuously looping sounds? Or would this be
|
||||
> fairly straight forward to implement? I've done virtually nothing
|
||||
> with sound in my life other than listen to it. :-)
|
||||
|
||||
It does/should. bzflag doesn't use this code though so it may suffer
|
||||
from bit rot. I used it to test the Doppler effect.
|
||||
|
||||
There may also be some issues around having a very large world. Imagine
|
||||
the sound as a spherical shell. Outside the shell, sound hasn't reached
|
||||
you yet; inside the shell, the sound has passed by. In bzflag I need
|
||||
to keep sounds around for as long as any part of the shell is inside the
|
||||
world because it's possible to move from one place to another instantly.
|
||||
Seems to me you have this same situation if you want external views.
|
||||
|
||||
The sound engine is clever enough not to process sounds unless you're in
|
||||
the shell, so a large world probably won't cause any problems. I'm just
|
||||
not sure at the moment.
|
||||
|
||||
|
||||
> This all sounds completely reasonable. All our stuff is released
|
||||
> under the basic "GPL".
|
||||
|
||||
Should be fine. I've no problem releasing my code under the GPL.
|
||||
Cheers,
|
||||
-chris
|
||||
|
||||
From crs@millpond.engr.sgi.com Mon Jan 5 17:33:03 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["660" "Mon" "5" "January" "1998" "15:32:53" "-0800" "Chris Schoeneman" "crs@millpond.engr.sgi.com" "<199801052332.PAA21873@millpond.engr.sgi.com>" "18" "Re: bzflag sound playing code" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
X-VM-Message-Order:
|
||||
(1 2 3 4 6 5 7 8 9 10 11 12 13 14 15
|
||||
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
|
||||
31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
|
||||
46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
|
||||
61 62 63 64)
|
||||
X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n"
|
||||
X-VM-Labels: ("r")
|
||||
X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil
|
||||
X-VM-Bookmark: 57
|
||||
Received: from sgi.sgi.com (SGI.COM [192.48.153.1])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with SMTP id RAA10765
|
||||
for <curt@me.umn.edu>; Mon, 5 Jan 1998 17:33:01 -0600 (CST)
|
||||
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id PAA14176
|
||||
for <@sgi.engr.sgi.com:curt@me.umn.edu>; Mon, 5 Jan 1998 15:33:00 -0800
|
||||
env-from (crs@millpond.engr.sgi.com)
|
||||
Received: from millpond.engr.sgi.com (millpond.engr.sgi.com [150.166.55.67]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA19353 for <@cthulhu.engr.sgi.com:curt@me.umn.edu>; Mon, 5 Jan 1998 15:32:53 -0800
|
||||
Received: (from crs@localhost) by millpond.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id PAA21873 for curt@me.umn.edu; Mon, 5 Jan 1998 15:32:53 -0800
|
||||
Message-Id: <199801052332.PAA21873@millpond.engr.sgi.com>
|
||||
In-Reply-To: <199801052322.RAA32525@kenai.me.umn.edu> from "Curtis L. Olson" at Jan 5, 98 05:22:08 pm
|
||||
X-Mailer: ELM [version 2.4 PL23]
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 8bit
|
||||
From: crs@millpond.engr.sgi.com (Chris Schoeneman)
|
||||
To: curt@me.umn.edu (Curtis L. Olson)
|
||||
Subject: Re: bzflag sound playing code
|
||||
Date: Mon, 5 Jan 1998 15:32:53 -0800 (PST)
|
||||
|
||||
Curtis L. Olson wrote:
|
||||
>
|
||||
> Our code is all GPL'd, so if you can keep within those license
|
||||
> restrictions feel free to borrow code. (Or does bzflag take place a
|
||||
> long time ago in a galaxy far, far away ... I haven't tried running it
|
||||
> yet myself.) :-)
|
||||
|
||||
Actually, it's already got accurate sun, moon, and stars. The star
|
||||
magnitudes are relatively okay (there's not enough dynamic range on
|
||||
a monitor anyway). You can specify any position on the earth, and
|
||||
the positions are accurately based on the time and date. Great minds
|
||||
think alike, eh?
|
||||
|
||||
I don't have the planets as I thought I'd gone overboard myself. Guess
|
||||
I hadn't gone far enough!
|
||||
|
||||
Cheers,
|
||||
-chris
|
||||
|
||||
From curt@me.umn.edu Thu Apr 30 09:02:28 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["3542" "" "30" "April" "1998" "09:02:26" "-0500" "Curtis L. Olson" "curt@me.umn.edu" nil "88" "[comp.os.linux.announce] Enlightened Sound Daemon version 0.2" "^From:" nil nil "4" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from kenai.me.umn.edu (curt@kenai.me.umn.edu [134.84.18.22])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id JAA10406
|
||||
for <curt@me.umn.edu>; Thu, 30 Apr 1998 09:02:28 -0500 (CDT)
|
||||
Received: (from curt@localhost)
|
||||
by kenai.me.umn.edu (8.8.5/8.8.5) id JAA19157;
|
||||
Thu, 30 Apr 1998 09:02:27 -0500
|
||||
Message-ID: <u87m47v24t.fsf@kenai.me.umn.edu>
|
||||
Lines: 88
|
||||
X-Mailer: Gnus v5.3/Emacs 19.34
|
||||
From: curt@me.umn.edu (Curtis L. Olson)
|
||||
Sender: curt@me.umn.edu
|
||||
To: curt@me.umn.edu
|
||||
Subject: [comp.os.linux.announce] Enlightened Sound Daemon version 0.2
|
||||
Date: 30 Apr 1998 09:02:26 -0500
|
||||
|
||||
|
||||
--
|
||||
Curtis Olson University of MN, ME Dept.
|
||||
curt@me.umn.edu
|
||||
http://www.menet.umn.edu/~curt Try Linux!
|
||||
------- Start of forwarded message -------
|
||||
From: "Eric B. Mitchell" <emitchell@altaira.com>
|
||||
Newsgroups: comp.os.linux.announce
|
||||
Subject: Enlightened Sound Daemon version 0.2
|
||||
Followup-To: comp.os.linux.misc
|
||||
Date: Thu, 30 Apr 1998 08:25:43 GMT
|
||||
Organization: Altair Aerospace Corporation
|
||||
Message-ID: <pycola.893924743.30806@laulujoutsen.pc.helsinki.fi>
|
||||
Reply-To: emitchell@altaira.com
|
||||
|
||||
-----BEGIN PGP SIGNED MESSAGE-----
|
||||
|
||||
|
||||
I am pleased to announce the preliminary release of the
|
||||
Enlightened Sound Daemon (EsounD version 0.2) for Linux.
|
||||
More details at <URL:http://www.netcom.com/~ericmit/EsounD.html>.
|
||||
This program is designed to mix together several digitized
|
||||
audio streams for playback by a single device. The current
|
||||
list of features includes the following functionality:
|
||||
|
||||
o A simple authentication scheme is implemented. The first
|
||||
process to present a 16 byte key to the daemon determines
|
||||
the ownership of the daemon. The owner of the daemon may
|
||||
allow or disallow connections from other keys. If a HUP
|
||||
signal is received, ownership of the daemon is reset.
|
||||
|
||||
o Playback of multiple digital samples simultaneously is
|
||||
supported. The daemon uses a raw sample format which
|
||||
is easily generated by the SOX utility from many other
|
||||
data formats.
|
||||
|
||||
o The mixed audio data may be output from the daemon as a
|
||||
"monitor" stream.
|
||||
|
||||
o Recording from the current input of the sound device is
|
||||
supported. Full duplex operation (simultaneous recording
|
||||
and playback) is supported.
|
||||
|
||||
o Client connections may cache samples for playback by an
|
||||
assigned identification number. For example, a window
|
||||
manager may cache samples in the server for playback on
|
||||
various events, and play them back without replaying the
|
||||
full audio stream for the sample. Samples may be looped
|
||||
until the server receives a "stop sample" message.
|
||||
|
||||
Currently, the only platform supported is Linux. It is intended
|
||||
that this program support multiple platforms. I have limited
|
||||
access to other Unix platforms, so any help in porting the
|
||||
Enlightened Sound Daemon to other platforms is appreciated.
|
||||
The amp program, by Tomislav Uzelac may be a good reference
|
||||
for porting the audio interface to other platforms.
|
||||
|
||||
This is to be considered an alpha release, as functionality
|
||||
remains to be implemented.
|
||||
|
||||
- -- ebm
|
||||
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
|
||||
| __ a.k.a. Eric B. Mitchell |
|
||||
| |_) . _ _| _| _ ericmit@ix.netcom.com |
|
||||
| | \ ( (_ (_| (_| (_| (/_ www.netcom.com/~ericmit |
|
||||
| How's My Programming? Call: 1 - 800 - DEV - NULL |
|
||||
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
|
||||
|
||||
|
||||
|
||||
- --
|
||||
This article has been digitally signed by the moderator, using PGP.
|
||||
http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature.
|
||||
Send submissions for comp.os.linux.announce to: linux-announce@news.ornl.gov
|
||||
PLEASE remember a short description of the software and the LOCATION.
|
||||
This group is archived at http://www.iki.fi/mjr/linux/cola.html
|
||||
|
||||
-----BEGIN PGP SIGNATURE-----
|
||||
Version: 2.6.3ia
|
||||
Charset: latin1
|
||||
|
||||
iQCVAgUBNUg1h1rUI/eHXJZ5AQHjSwP/aGb9U1fIgnUA6qMaD6x/JeTM2IJVRLDa
|
||||
YxXoZ9EbENIKCbV9lV0PcGogW0+eA2zAZq3tQFu9P9B+eFX6jcVD2FhDekvFI5ZS
|
||||
j44u74PbNU45LIuw2xxiaBAgfZcnZ9XZ3uy6Z9Yu3Xd+xkZ5k9nxafP1+tkPztmA
|
||||
y5okM7m4rEs=
|
||||
=Y1B3
|
||||
-----END PGP SIGNATURE-----
|
||||
------- End of forwarded message -------
|
||||
|
||||
85
Hints/scene-graph
Normal file
85
Hints/scene-graph
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
From owner-fgfs-devel@flightgear.org Fri Mar 12 12:57:31 1999
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["1824" "Fri" "12" "March" "1999" "12:55:14" "-0600" "Stephen J Baker" "sjbaker@hti.com" "<Pine.SGI.3.96.990312123905.8630A-100000@samantha.bgm.link.com>" "53" "[FGFS-Devel] Scene graph API." "^From:" nil nil "3" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mailhub.woodsoup.org (IDENT:root@anduin.physics.iastate.edu [129.186.82.1])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id MAA10391
|
||||
for <curt@me.umn.edu>; Fri, 12 Mar 1999 12:57:30 -0600 (CST)
|
||||
Received: from majordom by mailhub.woodsoup.org with local (Exim 1.92 #1)
|
||||
for fgfs-devel-outgoing@flightgear.org
|
||||
id 10LX6P-0003CG-00; Fri, 12 Mar 1999 12:56:09 -0600
|
||||
Received: from sunmgr.hti.com ([130.210.206.69] helo=issun6.hti.com)
|
||||
by mailhub.woodsoup.org with esmtp (Exim 1.92 #1)
|
||||
for fgfs-devel@flightgear.org
|
||||
id 10LX6O-0003C8-00; Fri, 12 Mar 1999 12:56:08 -0600
|
||||
Received: from issun5.hti.com ([130.210.202.3]) by issun6.hti.com
|
||||
(Netscape Messaging Server 3.6) with ESMTP id AAAEEB
|
||||
for <fgfs-devel@flightgear.org>; Fri, 12 Mar 1999 12:55:26 -0600
|
||||
Received: from samantha.bgm.link.com ([130.210.65.19]) by issun5.hti.com
|
||||
(Netscape Messaging Server 3.6) with SMTP id AAA6D20
|
||||
for <fgfs-devel@flightgear.org>; Fri, 12 Mar 1999 12:55:25 -0600
|
||||
X-Sender: steve@samantha.bgm.link.com
|
||||
Message-ID: <Pine.SGI.3.96.990312123905.8630A-100000@samantha.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Precedence: bulk
|
||||
Reply-To: fgfs-devel@flightgear.org
|
||||
From: "Stephen J Baker" <sjbaker@hti.com>
|
||||
Sender: owner-fgfs-devel@flightgear.org
|
||||
To: Flight Gear Mailing List <fgfs-devel@flightgear.org>
|
||||
Subject: [FGFS-Devel] Scene graph API.
|
||||
Date: Fri, 12 Mar 1999 12:55:14 -0600 (CST)
|
||||
|
||||
|
||||
I have just posted an early (pre-alpha - whatever) version of my
|
||||
new Scene Graph API and simple matrix/vector math library onto my
|
||||
web site:
|
||||
|
||||
http://www.woodsoup.org/~sbaker/ssg
|
||||
|
||||
...and...
|
||||
|
||||
http://www.woodsoup.org/~sbaker/sg
|
||||
|
||||
...these are the libraries that I'm using in my Tux-the-Penguin
|
||||
game - so they *work* pretty well - but may not be as complete
|
||||
or well-structured as they should be. There are also no example
|
||||
programs (apart from the game itself) and the only file loader
|
||||
is for an obscure ASCII format that nobody is likely to want
|
||||
as a standard. I hope to fix that somewhat over then next few
|
||||
weeks - but I'm on vacation next week.
|
||||
|
||||
I think these libraries could be applicable to FGFS in several
|
||||
areas:
|
||||
|
||||
1) 3D instrument panels.
|
||||
|
||||
2) BUildings and other hand-created features like airfields,
|
||||
detailed city areas and so forth.
|
||||
|
||||
3) Other aircraft.
|
||||
|
||||
There are some issues about how this would all integrate into
|
||||
Curts terrain rendering scheme - but I think it's do-able.
|
||||
|
||||
Anyway, it would be nice if people would read the manuals
|
||||
and email me some comments, criticisms, suggestions, etc.
|
||||
Like I said though - these are really early cuts so don't
|
||||
go out and write 100,000 lines of code that depend on
|
||||
them - OK?
|
||||
|
||||
Since I'm going to be out in the wilds of Arkansas for the
|
||||
next week (Do they have email out there? I *think* they
|
||||
have phones), don't expect a quick answer to any questions.
|
||||
|
||||
Steve Baker (817)619-2657 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-2466 (Fax)
|
||||
Work: sjbaker@hti.com http://www.hti.com
|
||||
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
|
||||
--
|
||||
Please visit the FGFS web page: http://www.flightgear.org
|
||||
For help on using this list (especially unsubscribing), send a message to
|
||||
"fgfs-devel-request@flightgear.org" with a single line of text: "help".
|
||||
|
||||
153
Hints/stl-gcc-redhat
Normal file
153
Hints/stl-gcc-redhat
Normal file
|
|
@ -0,0 +1,153 @@
|
|||
From: Bernie Bright <bbright@c031.aone.net.au>
|
||||
Sender: owner-fgfs-devel@flightgear.org
|
||||
To: fgfs-devel@flightgear.org
|
||||
Subject: Re: [FGFS-Devel] Another problem compiling Flightgear 0.55
|
||||
Date: Mon, 02 Nov 1998 14:31:05 +1100
|
||||
|
||||
Arno Dabekaussen wrote:
|
||||
>
|
||||
> Hi Curt,
|
||||
>
|
||||
> Thanks for answerring my former post, but unfortunately the compilation
|
||||
> blew up again.
|
||||
> Here is the relevant information.
|
||||
>
|
||||
> With kind regards,
|
||||
>
|
||||
> Arno Dabekaussen
|
||||
>
|
||||
> Making all in Time
|
||||
> make[2]: Entering directory
|
||||
> `/home/arno/applications/FlightGear-0.55/Simulator/Time'
|
||||
> c++ -DHAVE_CONFIG_H -I. -I../../././Simulator/Time -I../../Include
|
||||
> -DHAVE_DAYLIGHT -DHAVE_TIMEZONE -I../.. -I../../Lib -I../../Simulator
|
||||
> -I/usr/local/include -I/usr/X11R6/include -g -O2 -c event.cxx
|
||||
> In file included from /usr/include/g++/std/bastring.h:571,
|
||||
> from /usr/include/g++/std/string.h:6,
|
||||
> from /usr/include/g++/string:5,
|
||||
> from event.hxx:42,
|
||||
> from event.cxx:48:
|
||||
> /usr/include/g++/std/sinst.h:60: ambiguous template instantiation for
|
||||
> `operator !=(const char *, const
|
||||
> basic_string<char,string_char_traits<char> > &)' requested
|
||||
|
||||
[snip]
|
||||
|
||||
This is a known problem with the string class in g++ 2.7.x and is not
|
||||
limited to FG. I've attached an unofficial patch to that fixes the
|
||||
problem. Note, you'll need root access to apply the patch.
|
||||
|
||||
Cheers
|
||||
Bernie.>From khan@xraylith.wisc.edu Wed Mar 05 02:21:24 1997
|
||||
Path: news.mel.aone.net.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!newsfeeds.sol.net!uwm.edu!newsspool.doit.wisc.edu!news.doit.wisc.edu!khan
|
||||
From: khan@xraylith.wisc.edu (Mumit Khan)
|
||||
Newsgroups: gnu.g++.help
|
||||
Subject: Re: Compiling with strings & vectors
|
||||
Date: 4 Mar 1997 16:21:24 GMT
|
||||
Organization: Center for X-ray Lithography, UW-Madison
|
||||
Lines: 100
|
||||
Message-ID: <5fhi64$lsa@news.doit.wisc.edu>
|
||||
References: <5ffoh9$v2a$1@quartz.inquo.net>
|
||||
NNTP-Posting-Host: modi.xraylith.wisc.edu
|
||||
|
||||
In article <5ffoh9$v2a$1@quartz.inquo.net>,
|
||||
Travis Jensen <taj@viewpoint.com> wrote:
|
||||
>I am trying to use a 'string' in a program compiled with 2.7.2.2
|
||||
>and libg++ 2.7.2. If I just
|
||||
>
|
||||
> #include <string>
|
||||
>
|
||||
>and use it, I have no problems. However, if I
|
||||
>
|
||||
> #include <vector.h>
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
should be
|
||||
#include <vector>
|
||||
|
||||
> #include <string>
|
||||
>
|
||||
>Is there something special I have to do to use strings and vectors
|
||||
>together?
|
||||
>
|
||||
|
||||
I've posted an unofficial patch to libstdc++ headers (no re-compilation
|
||||
necessary, so it's easy!) something like 19 times so far. Here is a copy
|
||||
of an old posting:
|
||||
|
||||
=====================================================================
|
||||
|
||||
If you're using GNU STL that comes with libg++-2.7.1, must apply the
|
||||
following patch (no recompilation necessary):
|
||||
|
||||
% cd /usr/local/lib/g++-include/std
|
||||
% patch -s -p0 < /tmp/libg++-2.7.1-patch
|
||||
|
||||
==== LIBG++ patch
|
||||
|
||||
*** bastring.h.org Sun Dec 3 10:51:44 1995
|
||||
--- bastring.h Sun Dec 3 10:51:43 1995
|
||||
***************
|
||||
*** 523,529 ****
|
||||
}
|
||||
|
||||
// Kludge this until g++ supports the new template overloading semantics.
|
||||
! #if !defined(FUNCTION_H)
|
||||
template <class charT, class traits>
|
||||
inline bool
|
||||
operator!= (const basic_string <charT, traits>& lhs,
|
||||
--- 523,529 ----
|
||||
}
|
||||
|
||||
// Kludge this until g++ supports the new template overloading semantics.
|
||||
! #if !defined(FUNCTION_H) && !defined(OS_STL_FUNCTION_H)
|
||||
template <class charT, class traits>
|
||||
inline bool
|
||||
operator!= (const basic_string <charT, traits>& lhs,
|
||||
*** cinst.h.org Sun Dec 3 10:51:48 1995
|
||||
--- cinst.h Sun Dec 3 10:51:47 1995
|
||||
***************
|
||||
*** 84,92 ****
|
||||
--- 84,94 ----
|
||||
__DO2(operator==,__B,__CCR,__CCR)
|
||||
__DO2(operator==,__B,__CCR,__F)
|
||||
__DO2(operator==,__B,__F,__CCR)
|
||||
+ #if !defined(FUNCTION_H) && !defined(OS_STL_FUNCTION_H)
|
||||
__DO2(operator!=,__B,__CCR,__CCR)
|
||||
__DO2(operator!=,__B,__CCR,__F)
|
||||
__DO2(operator!=,__B,__F,__CCR)
|
||||
+ #endif
|
||||
__DO1(abs,__F,__CCR)
|
||||
__DO1(arg,__F,__CCR)
|
||||
__DO2(polar,__C,__F,__F)
|
||||
*** sinst.h.org Thu Feb 29 11:20:52 1996
|
||||
--- sinst.h Thu Feb 29 11:21:22 1996
|
||||
***************
|
||||
*** 57,67 ****
|
||||
--- 57,71 ----
|
||||
// __DOPR (op, bool, wchar_t, __W)
|
||||
|
||||
__DOB (==)
|
||||
+ #if !defined(FUNCTION_H) && !defined(OS_STL_FUNCTION_H)
|
||||
__DOB (!=)
|
||||
+ #endif
|
||||
__DOB (<)
|
||||
+ #if !defined(FUNCTION_H) && !defined(OS_STL_FUNCTION_H)
|
||||
__DOB (>)
|
||||
__DOB (<=)
|
||||
__DOB (>=)
|
||||
+ #endif
|
||||
|
||||
#undef __S
|
||||
//#undef __W
|
||||
|
||||
|
||||
==== END LIBG++ patch
|
||||
|
||||
Enjoy
|
||||
Mumit -- khan@xraylith.wisc.edu
|
||||
http://www.xraylith.wisc.edu/~khan/
|
||||
|
||||
Cc: gnu.g++.help,
|
||||
Travis Jensen <taj@viewpoint.com>
|
||||
|
||||
251
Hints/strips-vs-fans
Normal file
251
Hints/strips-vs-fans
Normal file
|
|
@ -0,0 +1,251 @@
|
|||
From fatcity!root@news.cts.com Sun Apr 12 22:32:55 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["2122" "Sun" "12" "April" "1998" "19:50:31" "-0800" "Steve Baker" "sbaker@link.com" nil "47" "Re: Strips vs Fans ..." "^From:" nil nil "4" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id WAA20847
|
||||
for <curt@me.umn.edu>; Sun, 12 Apr 1998 22:32:52 -0500 (CDT)
|
||||
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id UAA22193; Sun, 12 Apr 1998 20:31:45 -0700 (PDT)
|
||||
Received: from donews.cts.com (root@donews.cts.com [192.188.72.21])
|
||||
by king.cts.com (8.8.7/8.8.7) with SMTP id UAA00319;
|
||||
Sun, 12 Apr 1998 20:31:43 -0700 (PDT)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0yOZX9-00000Wa; Sun, 12 Apr 98 20:03 PDT
|
||||
Received: by fatcity.com (10-Feb-1998/v1.0f-b64/bab) via UUCP id 0001C21E; Sun, 12 Apr 1998 19:50:31 -0800
|
||||
Message-ID: <F001.0001C21E.19980412195031@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: Steve Baker <sbaker@link.com>
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0f, build 64; ListGuru (c) 1996-1998 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
Mime-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 7bit
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: Strips vs Fans ...
|
||||
Date: Sun, 12 Apr 1998 19:50:31 -0800
|
||||
|
||||
On Sat, 11 Apr 1998, Edward M Povazan wrote:
|
||||
|
||||
> I've been following threads here about auto strip generation, and am
|
||||
> starting to wonder, why not do fans. I did a small paper test ... a regular
|
||||
> triangle grid.
|
||||
> case : transforms per case : percentage less than seperate triangles
|
||||
> seperate triangles : 144 : 0
|
||||
> fans : 77 : 53%
|
||||
> strips : 56 : 39%
|
||||
>
|
||||
> OK so strips win here. But on a general mesh (especially one optimized for
|
||||
> rt3d) the strip runs are not as long. In fact, there are cases when fans
|
||||
> produce less transforms than strips (this is the case in my landscape
|
||||
> engine).
|
||||
|
||||
The other thing that leads me to get more excited about fans than
|
||||
strips is that they tend to be more compact - spatially that is -
|
||||
becuase they are all sharing that one vertex.
|
||||
|
||||
This is useful for pre-OpenGL culling since it greatly increases the
|
||||
probablility that a fan will cleanly come out wither entirely inside
|
||||
or entirely outside the view frustum. If (like me) you are using a
|
||||
bounding sphere test to accept or reject entire strip/fan primitives
|
||||
then it's easy to visualise how fans fit better into a neat sphere
|
||||
than those long wandering strips.
|
||||
|
||||
I'm still struggling to convert an old terrain system which was based
|
||||
around IRISGL primitives (alas, no fans) - and the wins for fans
|
||||
seem pretty significant.
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
--
|
||||
Author: Steve Baker
|
||||
INET: sbaker@link.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5051 FAX: (619) 538-5051
|
||||
San Diego, California -- Public Internet access / Mailing Lists
|
||||
--------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from). You may
|
||||
also send the HELP command for other information (like subscribing).
|
||||
|
||||
From sbaker@link.com Sun Aug 16 00:55:44 1998
|
||||
X-VM-v5-Data: ([nil nil nil t t nil nil nil nil]
|
||||
["1920" "Sun" "16" "August" "1998" "00:52:12" "-0500" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980816003848.24029A-100000@lechter.bgm.link.com>" "41" "Re: strips vs. fans" "^From:" nil nil "8" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id AAA14434
|
||||
for <curt@me.umn.edu>; Sun, 16 Aug 1998 00:55:43 -0500 (CDT)
|
||||
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.63.22])
|
||||
by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
|
||||
id AAA05219 for <curt@me.umn.edu>; Sun, 16 Aug 1998 00:55:12 -0500 (CDT)
|
||||
X-Sender: steve@lechter.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199808152138.QAA27557@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980816003848.24029A-100000@lechter.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: strips vs. fans
|
||||
Date: Sun, 16 Aug 1998 00:52:12 -0500 (CDT)
|
||||
|
||||
On Sat, 15 Aug 1998, Curtis L. Olson wrote:
|
||||
|
||||
> At one point did you suggest that I might have comperable performance
|
||||
> with fans vs. tri-strips?
|
||||
|
||||
Yes. We went down the path of changing our terrain tools to use
|
||||
fans - the performance was essentially unchanged.
|
||||
|
||||
In the end, it depends on the average number of vertices per triangle.
|
||||
For very long tristrips, or for very large fans, the average tends
|
||||
towards 1 vertex per triangle. In this respect, there is no performance
|
||||
difference between strips and fans. However, there are two reasons
|
||||
to prefer strips and one reason to prefer fans:
|
||||
|
||||
1) Strips are allegedly implemented in hardware for Voodoo-2, and
|
||||
when Mesa supports that, there could be some savings to be had
|
||||
in triangle setup times. I have not heard that the same is true
|
||||
for tri-fans - but it's possible.
|
||||
|
||||
2) Strips can potentially contain more triangles than fans because
|
||||
they are not limited to having all their triangles share that
|
||||
one start vertex. If you can actually make your strips longer
|
||||
for practical data then strips should win. However, it's quite
|
||||
hard to get an average strip strip length more than four or
|
||||
five when your terrain has features like lakes, rivers, forest,
|
||||
etc embedded in it.
|
||||
|
||||
3) Fans have one theoretical advantage - since all the triangles
|
||||
share that first vertex, fans tend to be spatially compact.
|
||||
This means that crude bounding sphere culling will be more
|
||||
effective at reducing the number of triangles sent to OpenGL
|
||||
than it might be with tri-strips.
|
||||
|
||||
My practical experience so far seems to suggest that these
|
||||
various effects are either so tiny as to make no difference - or
|
||||
somehow cancel out. However, it's work-in-progress.
|
||||
|
||||
Steve Baker (817)619-2657 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
From sbaker@link.com Tue Aug 18 08:57:29 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["4108" "Tue" "18" "August" "1998" "08:56:05" "-0500" "Steve Baker" "sbaker@link.com" nil "87" "Re: strips vs. fans" "^From:" nil nil "8" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.9.1a/8.9.1) with ESMTP id IAA10259
|
||||
for <curt@me.umn.edu>; Tue, 18 Aug 1998 08:57:27 -0500 (CDT)
|
||||
Received: from samantha.bgm.link.com (samantha.bgm.link.com [130.210.65.19])
|
||||
by lfkw10.bgm.link.com (8.8.6/RSC-RTI-1.0) with SMTP
|
||||
id IAA11753 for <curt@me.umn.edu>; Tue, 18 Aug 1998 08:56:48 -0500 (CDT)
|
||||
X-Sender: steve@samantha.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199808172109.QAA25296@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980818074747.24918A-100000@samantha.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: strips vs. fans
|
||||
Date: Tue, 18 Aug 1998 08:56:05 -0500 (CDT)
|
||||
|
||||
On Mon, 17 Aug 1998, Curtis L. Olson wrote:
|
||||
|
||||
> So do just use a "greedy" algorithm to build fans, or do you do
|
||||
> something more sophisticated?
|
||||
|
||||
Well, we have to consider the larger issues.
|
||||
|
||||
* From the point of view of OpenGL, the more triangles in the strip/fan
|
||||
the better.
|
||||
* From the point of view of FOV culling, the more compact the strip/fan
|
||||
the better.
|
||||
* From the point of view of intersection testing, the shorter the strip/fan
|
||||
the better.
|
||||
|
||||
We use a variety of stripping algorithms depending on the cicumstance.
|
||||
Sometimes we just do the 'greedy' algorithm, sometimes we impose a limit
|
||||
on the maximum strip length which tends to cut down on the number of
|
||||
single triangles (which are especially costly on SGI hardware for some
|
||||
reason). Sometimes we use an algorithm that has an estimate of the
|
||||
relative costs of transforming strips of length 1, 2, 3, 4, ... which
|
||||
tries many different ways to strip/fan until it finds one with a cost
|
||||
per-triangle that is less than some user-specified limit - and the
|
||||
ultimate algorithm simply does a totally exhaustive search for the cheapest
|
||||
overall set of strips.
|
||||
|
||||
The last few algorithms can take days to run on even relatively simple
|
||||
objects - and we use those only for the simplest of objects when that object
|
||||
is re-used a gazillion times in the database. For example, we did a
|
||||
model of Yellowstone national park where the customer needed the highest
|
||||
possible density of single, individual trees. We built a set of tree
|
||||
cluster models and ran the tri-stripper at maximum optimisation on them
|
||||
all to get down the cost of transforming all those thousands of trees to
|
||||
the absolute minimum.
|
||||
|
||||
However, when we have the whole of North America to tstrip, we can't
|
||||
afford the CPU hours to do anything much more than the very basic
|
||||
limited-length-greedy algorithm.
|
||||
|
||||
Limiting the maximum strip length helps the FOV culling so much that
|
||||
we pretty much always limit the length to a dozen of so triangles.
|
||||
That's principally due to SGI hardware which gains performance as the
|
||||
strip length increases - up to about 10 triangles - beyond which it
|
||||
doesn't really help any.
|
||||
|
||||
It's MUCH better (on SGI ONYX hardware) to generate two strips of 5
|
||||
triangles each than it is to generate one strip of 9 and one single
|
||||
triangle.
|
||||
|
||||
For us, there are yet other considerations. We don't currently drive
|
||||
OpenGL directly - we use the Performer scene graph API as a layer on
|
||||
top. Performer can optimise the case where all the triangles in the
|
||||
strip share the same surface normal and/or colour. In that case, it
|
||||
generates just one glNormal and glColor command for each strip. These
|
||||
are called 'Flat-Tri-strips'. For man-made objects, we can often win
|
||||
by having shorter strips that are flat rather than longer strips that
|
||||
are non-flat because the cost of transforming the normals is not
|
||||
negligable.
|
||||
|
||||
Some of the SGI machines also optimise for the case when there is only
|
||||
a single, infinite light source by only doing illumination per-normal
|
||||
rather than per-vertex - this also makes flat strips worth having.
|
||||
|
||||
Some of these optimisations are actually pessimisations on some machines,
|
||||
so you have to optimise the database for the hardware.
|
||||
|
||||
As you can see, this is another incredibly complicated issue if you
|
||||
want to get absolutely *ALL* the performance you can.
|
||||
|
||||
It's unreasonable to expect FGFS to do this with the limited effort
|
||||
available. We have two or three full-time staff thinking about
|
||||
database tools - and we have been working with OpenGL for five
|
||||
years now.
|
||||
|
||||
> > 1) Strips are allegedly implemented in hardware for Voodoo-2, and
|
||||
> > when Mesa supports that, there could be some savings to be had in
|
||||
> > triangle setup times. I have not heard that the same is true for
|
||||
> > tri-fans - but it's possible.
|
||||
>
|
||||
> I would think that if they did strips, they could easily do fans ...
|
||||
|
||||
I just asked the question on the 3Dfx newsgroup - we'll get a definitive
|
||||
answer there.
|
||||
|
||||
Steve Baker (817)619-2657 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
1073
Hints/texturing
Normal file
1073
Hints/texturing
Normal file
File diff suppressed because it is too large
Load diff
72
Hints/tile-gaps
Normal file
72
Hints/tile-gaps
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
From sbaker@link.com Tue May 26 07:55:03 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["1540" "Tue" "26" "May" "1998" "07:54:04" "-0500" "Steve Baker" "sbaker@link.com" nil "40" "Re: Question" "^From:" nil nil "5" nil nil nil nil nil]
|
||||
nil)
|
||||
X-VM-Last-Modified: (13793 54640 649954)
|
||||
X-VM-IMAP-Retrieved: nil
|
||||
X-VM-POP-Retrieved: nil
|
||||
X-VM-Message-Order:
|
||||
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
|
||||
16 17 18 19 20 21 22 23 24 25 26)
|
||||
X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n"
|
||||
X-VM-Labels: ("r")
|
||||
X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil
|
||||
X-VM-Bookmark: 20
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id HAA28563
|
||||
for <curt@me.umn.edu>; Tue, 26 May 1998 07:55:02 -0500 (CDT)
|
||||
Received: from borgus.bgm.link.com (borgus.bgm.link.com [130.210.236.13])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id HAA00068 for <curt@me.umn.edu>; Tue, 26 May 1998 07:54:55 -0500 (CDT)
|
||||
X-Sender: steve@borgus.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199805230429.XAA10965@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980526074643.2282C-100000@borgus.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: Question
|
||||
Date: Tue, 26 May 1998 07:54:04 -0500 (CDT)
|
||||
|
||||
On Fri, 22 May 1998, Curtis L. Olson wrote:
|
||||
|
||||
> I'm running into floating point problems again where my scenery tiles
|
||||
> sometimes have a pixel gap between them. I was wondering if you had
|
||||
> any ideas ...
|
||||
|
||||
It's a problem that plagues us too.
|
||||
|
||||
I can't say that I have a magic solution.
|
||||
|
||||
One thing I have *considered* is to do everything in integers (for
|
||||
the terrain skin at least).
|
||||
|
||||
This sounds counter-intuitive - but the source data for your
|
||||
terrain is certainly not accurate to better than a meter - and
|
||||
integers have the huge advantage that they don't suffer from
|
||||
roundoff error providing all you do is add and subtract them.
|
||||
|
||||
However, I havn't had the nerve to try this yet - right now, we
|
||||
kludge the edges of each terrain tile to make it a teeny-tiny bit
|
||||
too big. The resulting overlap is very small - but enough to get
|
||||
rid of the cracks.
|
||||
|
||||
> Anyways, what this forces me to do is for each tile I must
|
||||
> glTranslate() by center_of_tile_to_be_drawn - center_of_tile_I'm_in.
|
||||
> But, up until this point everything was done in double's so I was
|
||||
> hoping the final translate about which is on the order of 20,000 -
|
||||
> 30,000 meters would be ok.
|
||||
|
||||
But that translate could be done in integer meters.
|
||||
|
||||
> Anyways, I just thought I'd see if you had any brilliant thoughts on
|
||||
> the subject.
|
||||
|
||||
Nope - it's a continual problem for me too.
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
67
Hints/timezone
Normal file
67
Hints/timezone
Normal file
|
|
@ -0,0 +1,67 @@
|
|||
>-----Original Message-----
|
||||
>From: Antoine Leca [mailto:Antoine.Leca@renault.fr]
|
||||
>Sent: Thursday, April 01, 1999 4:51 AM
|
||||
>To: Lee Geoff
|
||||
>Cc: tz@elsie.nci.nih.gov
|
||||
>Subject: Re: storing timestamp data
|
||||
>
|
||||
>
|
||||
>Lee Geoff wrote:
|
||||
>>
|
||||
>> I'm interested in storing date/time data in Ingres
|
||||
>> databases which are running on Unix servers. We are
|
||||
>recording timed events
|
||||
>> on Unix servers as well as Windows 3.1 and NT PCs. I have
|
||||
>had problems with
|
||||
>> the apparent miss-handling of data when viewed before or after a DST
|
||||
>> transition.
|
||||
>
|
||||
>We had this kind of problems when setting up a Internet
|
||||
>standard for exchanging
|
||||
>calendars, agendas and schedules (it ends up in RFC2245, if you mind).
|
||||
>
|
||||
>The net result was: either use UTC, or local time + offset from UTC.
|
||||
>Do not use local time without UTC offset, as no reliable method can be
|
||||
>set up to correctly retrieve the exact point of time
|
||||
>afterwards (as you may
|
||||
>have experienced).
|
||||
>
|
||||
>Using UTC times is native on Unix and NT (AFAIK), so this is
|
||||
>the basic choice
|
||||
>there. The problem comes with Windows non-NT PCs, since they
|
||||
>run local clocks.
|
||||
>IMHO, and to be consistent with the above, no data that are
|
||||
>not tagged with
|
||||
>the (best approximation of) UTC offset should leave the PC.
|
||||
>
|
||||
>Traditional way of finding the best approximation are (in order):
|
||||
> - search for an (up to date) Olson's package to interpret the
|
||||
>information,
|
||||
> perhaps by searching $(DJDIR)/zoneinfo/localtime in addition to
|
||||
> $(TZDIR)/localtime
|
||||
> - if running on Windows 95/98, search the information in the registry
|
||||
> - setting a mechanism dedicated to it (but it will end with one more
|
||||
> mechanism, which tends to upset users)
|
||||
> - ask the TZ environment variable
|
||||
> - search the information on related softwares that may be
|
||||
>present on the PCs
|
||||
> (examples are mailing systems, e.g. Notes, and IP
|
||||
>connectivity packages)
|
||||
>
|
||||
>Do not use:
|
||||
> - tzset and timezone, as it defaults to PST8PDT or EST5EDT on
|
||||
>most compilers,
|
||||
> without being reliably accurate on most workstations by lack of TZ
|
||||
> - if your users are not Americans, do not rely on US-based
|
||||
>rules; they are
|
||||
> almost correct for Europeans (except that for example, this
|
||||
>week, my UTC
|
||||
> offset is wrong because my mail software is brocken on this
|
||||
>respect...)
|
||||
>
|
||||
>
|
||||
>Hope it helps,
|
||||
>
|
||||
>Antoine
|
||||
>
|
||||
>
|
||||
986
Hints/view-frustum-culling
Normal file
986
Hints/view-frustum-culling
Normal file
|
|
@ -0,0 +1,986 @@
|
|||
From sbaker@link.com Thu Jan 29 23:16:07 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["5377" "Thu" "29" "January" "1998" "23:16:36" "-0600" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980129224404.29062A-100000@lechter.bgm.link.com>" "139" "Re: View frustum culling" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id XAA03024
|
||||
for <curt@me.umn.edu>; Thu, 29 Jan 1998 23:16:06 -0600 (CST)
|
||||
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id XAA18220 for <curt@me.umn.edu>; Thu, 29 Jan 1998 23:15:35 -0600 (CST)
|
||||
X-Sender: steve@lechter.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199801292145.PAA04212@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980129224404.29062A-100000@lechter.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: View frustum culling
|
||||
Date: Thu, 29 Jan 1998 23:16:36 -0600 (CST)
|
||||
|
||||
On Thu, 29 Jan 1998, Curtis L. Olson wrote:
|
||||
|
||||
> Questions ...
|
||||
>
|
||||
> Let's say I know the following:
|
||||
>
|
||||
> Eye pt. = (0, 0, 0)
|
||||
> "look at" vector
|
||||
> "view up" vector
|
||||
> field of view angle
|
||||
> Assume a "square" view volume cross section (i.e. the far clip plane
|
||||
> would be a square)
|
||||
|
||||
(That is almost never the case since you want the image to fit the
|
||||
screen shape - but OK - for argument's sake, same HFOV as VFOV).
|
||||
|
||||
> I can calcuation the near and far clip planes pretty easily with this
|
||||
> info.
|
||||
|
||||
Assuming you know the near and far clip ranges - yes.
|
||||
|
||||
> Now, to calculate the left and right planes I could rotate the look at
|
||||
> vector about the view up vector by -1/2 * fov and +1/2 * fov
|
||||
> respectively. The view up vector already lies in both these planes,
|
||||
> so then I'd have two vectors in each plane and then I could calculate
|
||||
> the normals to get the equations of these planes
|
||||
|
||||
Yes, that would work.
|
||||
|
||||
> Then to calculate the top and bottom planes I could rotate the view up
|
||||
> vector by 90 degrees about the look at vector to get a vector in both
|
||||
> these planes, then I could rotate the look at vector about this new
|
||||
> vector by -1/2 * fov and +1/2 * fov to get the second vector in each
|
||||
> of these planes, and crunch the math just like I did for the left and
|
||||
> right planes.
|
||||
|
||||
...or you could just rotate the left or right plane normal by 90 degrees
|
||||
about the lookat vector (but only for your hypothetical square FOV).
|
||||
|
||||
> Does this sound reasonable, or am I missing some obvious tricks?
|
||||
|
||||
It's *reasonable* if you want the view planes in the coordinate system
|
||||
of the world. However, I'd argue about that premise.
|
||||
|
||||
I did the opposite - I keep the view frustum in the coordinate system
|
||||
of the eye and rotate the world into that coordinate system. This
|
||||
costs at most one extra transform (by the inverse of the eye-rel-world
|
||||
matrix) per frame (at the root of the database tree).
|
||||
|
||||
The advantages are *huge* in the clipping code (which is where I
|
||||
assume you are going with this question) since the plane equations
|
||||
for the near and far planes (in eye coordinates) are trivial:
|
||||
|
||||
General Equation of a Plane:
|
||||
|
||||
Ax + By + Cz + D == 0
|
||||
|
||||
Far clip plane:
|
||||
|
||||
A == 0 ;
|
||||
B == 0 ;
|
||||
C == -1 ;
|
||||
D == far_clip_range ;
|
||||
|
||||
Near clip plane:
|
||||
|
||||
A == 0 ;
|
||||
B == 0 ;
|
||||
C == 1 ;
|
||||
D == -near_clip_range ;
|
||||
|
||||
Also, since the left and right clip planes are now vertical, we
|
||||
know that B==0 and for the top and bottom planes, A==0.
|
||||
|
||||
In addition, because of symmetry about the Z axis, the A of
|
||||
the left plane is equal to -A for the right, and the B of
|
||||
the top plane is equal to -B of the bottom.
|
||||
|
||||
Furthermore, since D is just the distance of the closest
|
||||
point of the plane to the origin - and all four planes
|
||||
go through the eyepoint - and that *is* the origin - that
|
||||
means that the 'D' component of all four edge equations is
|
||||
always zero.
|
||||
|
||||
Notice that since the frustum is in eye coordinates,
|
||||
there is no need to worry about lookat or viewup vectors
|
||||
since these are 0,0,1 and 0,1,0 respectively - and the
|
||||
eye point is always at 0,0,0 by definition. This also
|
||||
means that you only need to calculate those plane equations
|
||||
once - rather than once per frame as with your scheme.
|
||||
|
||||
When you come to ask the question: "Is this bounding sphere
|
||||
cleanly inside the frustum, cleanly outside the frustum or
|
||||
(annoyingly) straddling it?", you will want to insert the
|
||||
x,y,z of the center of the sphere (relative to the eye
|
||||
in the 'eye' coordinate system) into each of the
|
||||
six plane equations in turn to compute the distance from the
|
||||
sphere center to the plane - and compare that to the radius
|
||||
of the sphere. When you write out the math for this, using
|
||||
the full plane equations (as you would have to do with your
|
||||
scheme), you find that all those zeros and symmetry effects
|
||||
result in some pretty amazing optimisations.
|
||||
|
||||
Additionally, this is the OpenGL way. You stuff your frustum
|
||||
matrix into the 'PROJECTION_MATRIX', put the inverse of
|
||||
your eyepoint transform into the MODELVIEW_MATRIX and proceed
|
||||
to push/multiply/pop the transforms of each of the models onto
|
||||
that same matrix. Notice that the frustum is never transformed
|
||||
into world space.
|
||||
|
||||
I suggest you go back and re-read the last L-O-N-G email I
|
||||
sent about clipping, I explain my suggested method there
|
||||
in more detail.
|
||||
|
||||
Note that I'm not saying that what you propose is wrong -
|
||||
just that IMHO (and *only* IMHO), my way is going to be
|
||||
a lot simpler and cheaper to implement. However, there may
|
||||
be other reasons to want to do it your way.
|
||||
|
||||
The complexity of MANY 3D graphics problems often depends
|
||||
critically on your choice of coordinate system. For
|
||||
clipping, doing the math in the eye coordinate system
|
||||
results in a *tiny* amount of math per sphere tested.
|
||||
|
||||
If you ever need to do lighting calculations, then
|
||||
carrying them out in a coordinate system with the
|
||||
light source at the origin makes life a gazillion
|
||||
times easier too. The same kinds of things will also
|
||||
crop up in collision detection as well.
|
||||
|
||||
|
||||
Steve Baker 817-619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. 817-619-4028 (Fax)
|
||||
2200 Arlington Downs Road SBaker@link.com (eMail)
|
||||
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
|
||||
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
|
||||
|
||||
** Beware of Geeks bearing GIF's. **
|
||||
|
||||
|
||||
From sbaker@link.com Fri Jan 30 14:08:05 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["4594" "Fri" "30" "January" "1998" "14:08:27" "-0600" "Steve Baker" "sbaker@link.com" "<Pine.SGI.3.96.980130135437.20130B-100000@lechter.bgm.link.com>" "120" "Re: View frustum culling" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id OAA21393
|
||||
for <curt@me.umn.edu>; Fri, 30 Jan 1998 14:08:03 -0600 (CST)
|
||||
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id OAA10811 for <curt@me.umn.edu>; Fri, 30 Jan 1998 14:07:27 -0600 (CST)
|
||||
X-Sender: steve@lechter.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199801301948.NAA25718@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980130135437.20130B-100000@lechter.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: View frustum culling
|
||||
Date: Fri, 30 Jan 1998 14:08:27 -0600 (CST)
|
||||
|
||||
On Fri, 30 Jan 1998, Curtis L. Olson wrote:
|
||||
|
||||
> Steve Baker writes:
|
||||
> > I did the opposite - I keep the view frustum in the coordinate
|
||||
> > system of the eye and rotate the world into that coordinate
|
||||
> > system. This costs at most one extra transform (by the inverse of
|
||||
> > the eye-rel-world matrix) per frame (at the root of the database
|
||||
> > tree).
|
||||
> >
|
||||
> > I suggest you go back and re-read the last L-O-N-G email I sent
|
||||
> > about clipping, I explain my suggested method there in more detail.
|
||||
>
|
||||
> Yes I have that in front of me. I guess it wasn't clear to me that
|
||||
> you were using this greatly simplifed view frustum specially placed in
|
||||
> eye coordinates.
|
||||
|
||||
That's the key to doing this stuff *quickly*.
|
||||
|
||||
> > The complexity of MANY 3D graphics problems often depends critically
|
||||
> > on your choice of coordinate system. For clipping, doing the math in
|
||||
> > the eye coordinate system results in a *tiny* amount of math per
|
||||
> > sphere tested.
|
||||
>
|
||||
> Yes ... your description all makes sense and looks like it makes view
|
||||
> frustum culling very simple to implement.
|
||||
>
|
||||
> Ok, so now I'm going to try to zero in a bit more on the source of my
|
||||
> confusion, which involves getting from my world to your eye
|
||||
> coordinates.
|
||||
|
||||
Let's adopt a naming convention for matrices here:
|
||||
|
||||
A_rel_B
|
||||
|
||||
means the matrix that positions objects in A relative to
|
||||
the object B.
|
||||
|
||||
Some facts:
|
||||
|
||||
B_rel_A is just the inverse of A_rel_B.
|
||||
|
||||
A_rel_B * B_rel_C == A_rel_C
|
||||
|
||||
Hence: (for a flat-earth world - just for the moment)
|
||||
|
||||
If the eyepoint is 10km east of the origin (eyepoint.x == 10,000)
|
||||
then:
|
||||
|
||||
eye_rel_world is a matrix that translates by 10000m in the X
|
||||
direction.
|
||||
|
||||
world_rel_eye is the inverse of eye_rel_world - which in this
|
||||
case is just a matrix that translates by -10000m in X.
|
||||
|
||||
Taking the inverse of a general matrix isn't nice - but for simple
|
||||
rotate/translate matrices it isn't too bad - and you only do it
|
||||
once per frame anyway.
|
||||
|
||||
> Lets say that I have a bunch of scenery tiles that are properly
|
||||
> oriented, but translated to near (0, 0, 0) to avoid problems with
|
||||
> "float" precision.
|
||||
>
|
||||
> I assume based on your previous message that you define your view
|
||||
> frustum once at the beginning of your program in eye coordinates to
|
||||
> simplify all this math.
|
||||
|
||||
Yep - you *might* want to allow the user to change it sometimes - but
|
||||
basically, it's always the same number unless you resize the window,
|
||||
zoom the image, etc.
|
||||
|
||||
> This moves the "hard" part to generating a transformation matrix that
|
||||
> maps world coordinates into eye coordinates.
|
||||
|
||||
But world_rel_eye is just the inverse of eye_rel_world - and that's
|
||||
just the rotation/translation of the eyepoint relative to some
|
||||
arbitary point.
|
||||
|
||||
> You say ...
|
||||
>
|
||||
> > Additionally, this is the OpenGL way. You stuff your frustum matrix
|
||||
> > into the 'PROJECTION_MATRIX', put the inverse of your eyepoint
|
||||
> > transform into the MODELVIEW_MATRIX and proceed to push/multiply/pop
|
||||
> > the transforms of each of the models onto that same matrix. Notice
|
||||
> > that the frustum is never transformed into world space.
|
||||
>
|
||||
> Ok, so does this mean that every iteration I have to generate the
|
||||
> world -> eye transformation matrix by hand ... i.e. calculate the
|
||||
> first translation matrix, calculate the rotation matrix, calculate the
|
||||
> second translation matrix, calculate the shear matrix, calculate the
|
||||
> scaling matrix, and then combine all these together, then invert it
|
||||
> and stuff it on the MODELVIEW stack?
|
||||
|
||||
Yes - except that the eye_rel_world isn't usually scaled or sheared or
|
||||
anything. Just heading/pitch/roll/x/y/z.
|
||||
|
||||
> Or is there a way to get OpenGL to do this work for me?
|
||||
|
||||
No - not really - there is no glInvertMatrix (AFAIK) - and in any
|
||||
case, on machines with geometry accelleration doing a glGetMatrix
|
||||
is *death* to performance.
|
||||
|
||||
> If not, can I at least use OpenGL's rotates,
|
||||
> and transformations to avoid spending two weeks debugging picky math
|
||||
> routines?
|
||||
|
||||
No - don't debug new math routines either - let me find some out on the
|
||||
web for you. I'm sure I know of a good set. I'll email you from home
|
||||
tonight - I'm a bit busy right now.
|
||||
|
||||
Flight Gear will definitely need a good, robust set of math routines -
|
||||
better to have a solid library than to try to kludge something in OpenGL.
|
||||
|
||||
Steve Baker 817-619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. 817-619-4028 (Fax)
|
||||
2200 Arlington Downs Road SBaker@link.com (eMail)
|
||||
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
|
||||
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
|
||||
|
||||
** Beware of Geeks bearing GIF's. **
|
||||
|
||||
|
||||
From sbaker@link.com Fri Jan 30 22:51:59 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["4301" "Fri" "30" "January" "1998" "22:52:31" "-0600" "Steve Baker" "sbaker@link.com" nil "103" "Re: View frustum culling" "^From:" nil nil "1" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.6) with ESMTP id WAA03743
|
||||
for <curt@me.umn.edu>; Fri, 30 Jan 1998 22:51:58 -0600 (CST)
|
||||
Received: from lechter.bgm.link.com (lechter.bgm.link.com [130.210.239.45])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id WAA08997 for <curt@me.umn.edu>; Fri, 30 Jan 1998 22:51:26 -0600 (CST)
|
||||
X-Sender: steve@lechter.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199801302035.OAA26234@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980130223546.27307A-100000@lechter.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: View frustum culling
|
||||
Date: Fri, 30 Jan 1998 22:52:31 -0600 (CST)
|
||||
|
||||
On Fri, 30 Jan 1998, Curtis L. Olson wrote:
|
||||
|
||||
> Steve Baker writes:
|
||||
> > But world_rel_eye is just the inverse of eye_rel_world - and that's
|
||||
> > just the rotation/translation of the eyepoint relative to some
|
||||
> > arbitary point.
|
||||
>
|
||||
> Ok, from what you are saying, if I think about it, I've probably
|
||||
> already got a suitable matrix or something close to it laying around
|
||||
> someplace. I have a matrix that does the proper rotations to align
|
||||
> world coordinates with the local "up" for the aircraft. I'd probably
|
||||
> just need to pre-multiply the proper translation matrix with that
|
||||
> rotate matrix, then invert it, and stuff it onto the MODELVIEW stack.
|
||||
|
||||
You *must* be doing the right thing at the start of the frame - or
|
||||
how else would the graphics be coming out right? (Oh - unless you
|
||||
are using that weird OpenGL 'lookat' function or something).
|
||||
|
||||
> > No - don't debug new math routines either - let me find some out on
|
||||
> > the web for you. I'm sure I know of a good set. I'll email you from
|
||||
> > home tonight - I'm a bit busy right now.
|
||||
> >
|
||||
> > Flight Gear will definitely need a good, robust set of math routines
|
||||
> > - better to have a solid library than to try to kludge something in
|
||||
> > OpenGL.
|
||||
>
|
||||
> You may scream when you hear this, or not, I'm not sure ... but I've
|
||||
> been using the matrix and vector routines from SRGP and SPHIGS.
|
||||
|
||||
I don't know these - but it's hard to imagine how anyone could screw
|
||||
up the implementation of a matrix math library - so they are probably OK.
|
||||
|
||||
I have accumulated by own matrix/quaternion library that I've used
|
||||
for the last 10 years - every new project starts with it - and adds to
|
||||
it, so now I don't even have to think about how to drive it. That's
|
||||
a very liberating thing.
|
||||
|
||||
Another good source for a matrix lib is inside the Mesa sources. These
|
||||
are particularly interesting because the latest Beta release has
|
||||
super-optimised machine code for Intel CPU's under Linux as a conditional
|
||||
compiled option. You'd need to copy and change the names of the routines
|
||||
though to avoid the names clashing with the real Mesa routines.
|
||||
|
||||
One *IMPORTANT* thing is that when you invert the eye_rel_world matrix
|
||||
to get world_rel_eye, don't use a general purpose matrix invert routine
|
||||
since those are *REALLY* inefficient bits of code for matrices that
|
||||
are guaranteed to be pure rotate/translate. Instead, just do this:
|
||||
|
||||
/*
|
||||
This definition of a matrix is
|
||||
easier to deal with than a float[16] -
|
||||
but you can safely pass this kind
|
||||
of matrix directly to OpenGL routines
|
||||
like glMultMatrix and glLoadMatrix.
|
||||
*/
|
||||
|
||||
typedef float fgMat [ 4 ][ 4 ] ;
|
||||
|
||||
/*
|
||||
Transpose/Negate is a poor man's invert.
|
||||
It can *only* be used when matrix is a
|
||||
simple rotate-translate - but it's a
|
||||
gazillion times faster than a full-blown
|
||||
invert.
|
||||
*/
|
||||
|
||||
void fgTransposeNegateMat( fgMat dst, fgMat src )
|
||||
{
|
||||
/* Transpose the 3x3 rotation sub-matrix */
|
||||
|
||||
dst[0][0] = src[0][0] ; dst[0][1] = src[1][0] ; dst[0][2] = src[2][0] ;
|
||||
dst[1][0] = src[0][1] ; dst[1][1] = src[1][1] ; dst[1][2] = src[2][1] ;
|
||||
dst[2][0] = src[0][2] ; dst[2][1] = src[1][2] ; dst[2][2] = src[2][2] ;
|
||||
|
||||
/* Negate the translate part */
|
||||
|
||||
dst[3][0] = -src[3][0] ; dst[3][1] = -src[3][1] ; dst[3][2] = -src[3][2] ;
|
||||
|
||||
/* Populate the rest */
|
||||
|
||||
dst[0][3] = dst[1][3] = dst[2][3] = 0.0f ; dst[3][3] = 1.0f ;
|
||||
}
|
||||
|
||||
> Debugging the low level routines, though, is sometimes the easy part,
|
||||
> debugging the usage of them is where it can often get hairy ... :-)
|
||||
|
||||
I agree - matrices are truly horrible to get your head around. Have
|
||||
you looked into Quaternions yet? They are v.interesting for the
|
||||
flight dynamics people because they don't suffer from 'gymbal lock'
|
||||
like H,P,R angles and are easier to renormalize than matrices.
|
||||
|
||||
You don't want to use Quaternions for the main graphics code - but
|
||||
it's easy to form a Matrix from a Quaternion - and Quaternions are
|
||||
a much better way to represent rotation than the usual three angles.
|
||||
|
||||
Steve Baker 817-619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. 817-619-4028 (Fax)
|
||||
2200 Arlington Downs Road SBaker@link.com (eMail)
|
||||
Arlington, Texas. TX 76005-6171 SJBaker1@airmail.net (Personal eMail)
|
||||
http://www.hti.com http://web2.airmail.net/sjbaker1 (personal)
|
||||
|
||||
** Beware of Geeks bearing GIF's. **
|
||||
|
||||
|
||||
From owner-flight-gear@me.umn.edu Tue May 19 07:45:59 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["4413" "Tue" "19" "May" "1998" "07:44:47" "-0500" "Steve Baker" "sbaker@link.com" nil "116" "Re: [FGFS] View Frustum Culling" "^From:" nil nil "5" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: (from majordom@localhost)
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) id HAA04944
|
||||
for flight-gear-outgoing; Tue, 19 May 1998 07:45:59 -0500 (CDT)
|
||||
X-Authentication-Warning: meserv.me.umn.edu: majordom set sender to owner-flight-gear@me.umn.edu using -f
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id HAA04940
|
||||
for <flight-gear@me.umn.edu>; Tue, 19 May 1998 07:45:55 -0500 (CDT)
|
||||
Received: from borgus.bgm.link.com (borgus.bgm.link.com [130.210.236.13])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id HAA29586 for <flight-gear@me.umn.edu>; Tue, 19 May 1998 07:45:23 -0500 (CDT)
|
||||
X-Sender: steve@borgus.bgm.link.com
|
||||
In-Reply-To: <199805182119.QAA04388@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980519070916.5720B-100000@borgus.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Precedence: bulk
|
||||
Reply-To: flight-gear@me.umn.edu
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
Sender: owner-flight-gear@me.umn.edu
|
||||
To: flight-gear@me.umn.edu
|
||||
Subject: Re: [FGFS] View Frustum Culling
|
||||
Date: Tue, 19 May 1998 07:44:47 -0500 (CDT)
|
||||
|
||||
On Mon, 18 May 1998, Curtis L. Olson wrote:
|
||||
|
||||
> Steve Baker writes:
|
||||
> > Are you only planning to cull at the tile level? You probably ought
|
||||
> > to cull at the triangle strip level (at least on machines without
|
||||
> > geometry hardware).
|
||||
>
|
||||
> You are always trying to make things more complicated ... :-)
|
||||
|
||||
It's my experience that things are perfectly capable of getting
|
||||
more complicated without any help from me :-)
|
||||
|
||||
> > You can check a bounding sphere against the view frustum in about 4
|
||||
> > multiplies and four additions - and you only need to do that for
|
||||
> > spheres inside tiles that straddle the frustum. Each test that
|
||||
> > excludes a tstrip will save a bunch of vertex transforms - so you
|
||||
> > should get another big win in doing that.
|
||||
>
|
||||
> Ok, a couple of questions. Do you recommend pre-calculating and
|
||||
> storing the bounding sphere info for each tri-strip in the data file,
|
||||
> or should I calculate it at load time?
|
||||
|
||||
Well, since you only have one CPU to use for both rendering and
|
||||
realtime database paging, you'll want to minimise the amount of
|
||||
calculations when loading. The bounding sphere calculation
|
||||
that most people do is very simple - you probably would want to do it
|
||||
offline eventually - but you can probably do it on loading the database
|
||||
for now just so you can get the culling stuff finished. So long as you
|
||||
don't do it every frame you'll be OK in the short term.
|
||||
|
||||
The basic bounding sphere algorithm that most people (including me)
|
||||
use is v.simple. Just find the maximum and minimum x, y and z values
|
||||
in the data set, position the center of the sphere halfway between
|
||||
the minimum and maximum in each axis - then go through the points
|
||||
to find the one thats furthest from that center point - that distance
|
||||
is the radius. (You can compare the square of the ranges to get the
|
||||
longest range - so you only need to do one sqrt per sphere when you
|
||||
need to compute the actual radius).
|
||||
|
||||
There has been some discussion of 'better' algorithms that (presumable)
|
||||
produce tighter spheres than the simple method described above. On
|
||||
my 'to do' list here at work is to evaluate these various algorithms to
|
||||
see which actually produces the tightest spheres.
|
||||
|
||||
tighter spheres == better culling == lower polygon counts.
|
||||
|
||||
I'm pretty sceptical about these algorithms being *significantly*
|
||||
better than the simple one - but even a few percent improvement
|
||||
is worth having if I can do it offline and steal the code from
|
||||
someone who can do 'math'.
|
||||
|
||||
This one looks interesting:
|
||||
|
||||
http://vision.ucsd.edu/~dwhite/ball.html
|
||||
|
||||
...although being iterative, I wouldn't want to do it in my
|
||||
database loader code.
|
||||
|
||||
Same applies to this one:
|
||||
|
||||
http://cm.bell-labs.com/who/clarkson/center.html
|
||||
|
||||
Both have source code - which is just as well since I can't understand
|
||||
the math behind either of them!
|
||||
|
||||
If your culling math starts to take too much time then you'll want to
|
||||
do a hierarchical cull. If I were you though I'd probably just
|
||||
do this:
|
||||
|
||||
for each terrain tile
|
||||
{
|
||||
if ( outside the frustum )
|
||||
continue ;
|
||||
|
||||
if ( inside the frustum )
|
||||
draw all the tristrips
|
||||
else /* straddling the frustum */
|
||||
{
|
||||
for each tristrip
|
||||
if ( inside or straddling the frustum )
|
||||
draw the tristrip
|
||||
}
|
||||
}
|
||||
|
||||
(Of course 'draw the tristrip' might actually mean 'add the tristrip to
|
||||
the appropriate bucket so we can draw it later')
|
||||
|
||||
> To impliment this sort of
|
||||
> scheme I suppose I would need to keep each tri-strip in it's own
|
||||
> display list.
|
||||
|
||||
Yep - but you need to do that so that you can....
|
||||
|
||||
> ...sort the objects into buckets by material properties.
|
||||
|
||||
Definitely. Switching material properties (especially texture map)
|
||||
is very costly on most hardware OpenGL's. Sorting is an absolute
|
||||
must once you start you use more than one kind of texture on the
|
||||
terrain skin.
|
||||
|
||||
> I suppose this would entail defining material properties in the data
|
||||
> file and otherwise sprucing up the data file format (and internal data
|
||||
> structures) a bit.
|
||||
|
||||
Eventually.
|
||||
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
-------------------------------------
|
||||
Please visit the FGFS web page: http://www.menet.umn.edu/~curt/fgfs/
|
||||
For help on using this list (especially unsubscribing), send a message to
|
||||
"flight-gear-request@me.umn.edu" with a single line of text: "help".
|
||||
|
||||
From sbaker@link.com Mon May 18 07:39:58 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["10518" "Mon" "18" "May" "1998" "07:39:06" "-0500" "Steve Baker" "sbaker@link.com" nil "295" "Re: view frustum culling" "^From:" nil nil "5" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id HAA01318
|
||||
for <curt@me.umn.edu>; Mon, 18 May 1998 07:39:57 -0500 (CDT)
|
||||
Received: from sutcliffe.bgm.link.com (sutcliffe.bgm.link.com [130.210.236.18])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id HAA03232 for <curt@me.umn.edu>; Mon, 18 May 1998 07:39:26 -0500 (CDT)
|
||||
X-Sender: steve@sutcliffe.bgm.link.com
|
||||
Reply-To: Steve Baker <sbaker@link.com>
|
||||
In-Reply-To: <199805152113.QAA12303@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980518071249.21179A-100000@sutcliffe.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
To: "Curtis L. Olson" <curt@me.umn.edu>
|
||||
Subject: Re: view frustum culling
|
||||
Date: Mon, 18 May 1998 07:39:06 -0500 (CDT)
|
||||
|
||||
On Fri, 15 May 1998, Curtis L. Olson wrote:
|
||||
|
||||
> I was just planning to work out the math myself, but it's not coming
|
||||
> out nearly as simple as what you had. The near/far clipping plane is
|
||||
> trivial, but I was working through the sides and started to see a few
|
||||
> sqrt()'s and such start to creep in, and I don't remember seeing this
|
||||
> with your pseudo-code.
|
||||
|
||||
Certainly shouldn't need sqrt's.
|
||||
|
||||
How about this:
|
||||
|
||||
You said:
|
||||
|
||||
> Anyone know anything about view frustum culling?
|
||||
|
||||
Yep.
|
||||
|
||||
Two issues:
|
||||
|
||||
1) Scene hierarchy generation (offline).
|
||||
|
||||
2) Runtime culling.
|
||||
|
||||
Hierarchy:
|
||||
==========
|
||||
|
||||
There are lots of ways to do this. I usually build an heirerchical description
|
||||
of each terrain tile. I typically build a tree structure that's organized
|
||||
as follows:
|
||||
|
||||
| The World.
|
||||
|
|
||||
___________________|___
|
||||
| | | | | | |
|
||||
* * * * * * * Terrain tiles currently loaded
|
||||
| | | | | | |
|
||||
|
|
||||
|
|
||||
_____|_____
|
||||
| | | |
|
||||
* * * * Quarter-tiles
|
||||
| | | |
|
||||
|
|
||||
|
|
||||
_____|_____
|
||||
| | | |
|
||||
* * * * Sixteenth-tiles
|
||||
| | | |
|
||||
|
||||
...and so on down until the number of polygons in each 'object' gets 'small enough'.
|
||||
|
||||
When you do this, don't try to split polygons when they cross a quarter or a
|
||||
sixteenth tile boundary - just dump each polygon into the nearest 'bucket' to
|
||||
it's centroid.
|
||||
|
||||
Do your tri-stripping on the leaf nodes of this tree - so that each tristrip
|
||||
is contained entirely within one bucket.
|
||||
|
||||
Eventually, you will need to include buildings, roads, rivers, etc. Since these
|
||||
need to be culled by level of detail, it is often useful to put them into a separate
|
||||
tree structure that parallels the terrain 'skin' structure.
|
||||
|
||||
Finally, compute a bounding sphere around each leaf node, find the best fit
|
||||
sphere by finding the maximum and minimim x, y and z of the tristrips in that
|
||||
leaf node, taking the mid-point and then finding the vertex that is furthest
|
||||
from that center point and using it as the radius.
|
||||
|
||||
Compute the bounding sphere for each level in the tree (everywhere where there is
|
||||
a '*' in my diagram).
|
||||
|
||||
Runtime:
|
||||
========
|
||||
|
||||
At runtime, you walk that tree every frame, testing the bounding sphere against
|
||||
the view frustum.
|
||||
|
||||
* If the sphere lies entirely outside the view frustum then stop traversal
|
||||
for that node. There is no need to test any of the nodes beneath this one
|
||||
(we know that none of their leaf tristrips are visible).
|
||||
|
||||
* If the sphere lies entirely inside the view frustum then traverse immediately
|
||||
to all of the leaves below this node without doing any more sphere testing
|
||||
on them - draw all of the tristrips that are there. (We know they are all visible)
|
||||
|
||||
* If the sphere straddles the view frustum then check each daughter node in
|
||||
turn by applying this algorithm on them recursively. If a leaf node straddles
|
||||
the view frustrum then it's bad luck, you just draw all the tristrips it
|
||||
contains and let OpenGL do the work.
|
||||
|
||||
You might also want to put a 'transition range' onto each node and if it
|
||||
lies beyond that range cull it. You can also use this to conveniently
|
||||
switch levels of detail by having multiple versions of each object in
|
||||
the tree.
|
||||
|
||||
Testing a sphere against the View Frustum:
|
||||
==========================================
|
||||
|
||||
In most cases, we can describe the volume of space that you can see
|
||||
through the little glass window on the front of your CRT using a
|
||||
Frustum (frequently mis-spelled as Frustrum or Fustrum even in some
|
||||
text books).
|
||||
|
||||
A frustum is a truncated pyramid - which typically bounded by six
|
||||
planes called:
|
||||
|
||||
NEAR, FAR, LEFT, RIGHT, TOP, BOTTOM
|
||||
|
||||
There are applications that require additional clipping planes (eg for
|
||||
non-rectangular screens) - extending the work described in this
|
||||
to cater for that is not hard).
|
||||
|
||||
In principal, all six planes can be constructed as general plane
|
||||
equations:
|
||||
|
||||
A x + B y + C z + D == 0
|
||||
|
||||
However, for most applications, NEAR and FAR are parallel to the
|
||||
screen, LEFT, RIGHT,TOP and BOTTOM all meet at the eye and the eye lies
|
||||
along a vector that extends out from the center of the screen and is
|
||||
perpendicular to it. This simplifies the equations considerably for
|
||||
practical applications.
|
||||
|
||||
Transforms.
|
||||
~~~~~~~~~~~
|
||||
|
||||
It is easiest to perform culling in a coordinate system where the
|
||||
eyepoint is at the origin and the line from the eye through the center
|
||||
of the screen lies along one major axis with the edges of the screen
|
||||
parallel to the remaining two axes. This coordinate system is called
|
||||
'Eye Space'.
|
||||
|
||||
Testing a Sphere against a Frustum.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The most important thing to bear in mind about culling is that the
|
||||
first trivial-reject test you apply is by far the most time-critical.
|
||||
This test is always applied to more nodes than any of the subsequent
|
||||
tests.
|
||||
|
||||
So, do the cheapest test first.
|
||||
|
||||
This is typically the NEAR plane test. Everything behind the viewers
|
||||
head gets chopped out - and it's an especially cheap test.
|
||||
|
||||
|
||||
if ( obj_sphere.center.z < near_plane - obj_sphere.radius )
|
||||
REJECT!!
|
||||
|
||||
|
||||
...next do the second cheapest test (assuming you know that your
|
||||
database could possibly extend beyond the far clip plane)...
|
||||
|
||||
|
||||
if ( obj_sphere.center.z - obj_sphere.radius > far_plane )
|
||||
REJECT!!
|
||||
|
||||
|
||||
...and *then* (for each of the other 4 planes) do...
|
||||
|
||||
|
||||
if ( distance( obj.position, plane ) <= obj_sphere.radius )
|
||||
REJECT!!
|
||||
|
||||
|
||||
(The algorithm for computing that 'distance()' function is described
|
||||
below).
|
||||
|
||||
It's also useful to know that in many applications, you cull more
|
||||
objects from the left and right faces of the frustum than you do from
|
||||
the top and bottom - so test left, then right, then bottom then top.
|
||||
|
||||
Also, with bounding sphere tests, you shouldn't forget to do
|
||||
total-accept as well as total-reject tests. Once you know that an
|
||||
object's sphere is TOTALLY on screen, you don't have to descend into
|
||||
the daughter objects to cull-test them...you *know* they are all
|
||||
on-screen.
|
||||
|
||||
Another way to look at that it to remember which of the six possible
|
||||
plane tests didn't even touch the sphere - as you work your way down
|
||||
the object hierarchy, you can accumulate those flags and avoid even
|
||||
testing those planes that a parent sphere has already cleanly passed.
|
||||
If you do this then a vast percentage of your spheres will only need to
|
||||
be tested against one plane. However, for the normal case of a simple
|
||||
frustum - when you examine the fully optimised
|
||||
distance-of-point-from-plane code (below), you may well conclude that
|
||||
this additional logic doesn't justify the paltry amount of additional
|
||||
math that it might save.
|
||||
|
||||
Computing the Distance from Sphere Center to Clipping Plane.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A plane can be represented by the equation
|
||||
|
||||
|
||||
Ax + By + Cz + D = 0 ;
|
||||
|
||||
|
||||
A,B,C is just the surface normal of the plane and D is the shortest
|
||||
distance from the origin to the plane.
|
||||
|
||||
So, if you need to find the distance of a point from the plane, just
|
||||
imagine a new plane that goes through your test point and is parallel
|
||||
to the plane you want to test. The plane equation of that new plane
|
||||
would be:
|
||||
|
||||
|
||||
A'x + B'y + C'z + D' = 0 ;
|
||||
|
||||
|
||||
Since the two planes are parallel, their surface normals are the same,
|
||||
so
|
||||
|
||||
|
||||
A' == A B' == B C' == C D' == D + distance_between_the_two_planes
|
||||
|
||||
|
||||
...the only thing that's different is their D values - which differ by
|
||||
the distance of your test point from the original plane.
|
||||
|
||||
So, for a point (x,y,z), the distance 'd' from the plane (A,B,C,D) is
|
||||
derived as:
|
||||
|
||||
|
||||
d = D' - D
|
||||
= -A'x - B'y - C'z - D
|
||||
= -Ax - By - Cz - D
|
||||
= -( [ABC]dot[xyz] + D )
|
||||
|
||||
|
||||
A dot-product of the point and the surface normal of the plane, plus
|
||||
the distance from the plane to the origin. Three multiplies, three
|
||||
additions and a negation.
|
||||
|
||||
As an aside - if you consider the point (x,y,z) as a FOUR element
|
||||
homogeneous vector (x,y,z,w) then 'w' is 1.0 and you can compute the
|
||||
distance by simply taking the four element dot-product of (A,B,C,D)
|
||||
with (x,y,z,w). If you have fast 4x4 matrix math hardware in your
|
||||
machine then you can use it to compute the distance from a point to all
|
||||
four planes in a single operation!
|
||||
|
||||
That's the general result for an arbitary plane - but culling to the
|
||||
view frustum is a very special case. If you are working in eye-relative
|
||||
coordinates (IMHO this is best), then since all TOP,BOTTOM,LEFT,RIGHT
|
||||
planes of the frustum meet at the eye - and since the eye is at the
|
||||
origin (by definition), then D is always zero for those planes and that
|
||||
saves you a subtract.
|
||||
|
||||
If you are feeling even more in need of optimisation - then you can
|
||||
save one multiply per plane by realising that (for rectangular screens)
|
||||
one of the three components of the plane equation will always be zero.
|
||||
|
||||
So, for the LEFT clip plane, the Y component of the normal of the plane
|
||||
is zero, so the distance to the left or right plane is just
|
||||
|
||||
|
||||
d = -( Ax + Cz )
|
||||
|
||||
|
||||
...and to the top or bottom plane it's just:
|
||||
|
||||
|
||||
d = -( By + Cz )
|
||||
|
||||
|
||||
Furthermore, we know that the A component for the LEFT plane is just
|
||||
the negation of the A component of the RIGHT plane, and the C component
|
||||
is the same for both LEFT and RIGHT (and similarly, the B component of
|
||||
the TOP plane, is the negation of the B component for the BOTTOM plane
|
||||
and the C component is the same for both TOP and BOTTOM). This means
|
||||
that you only need four multiplies and four additions to do the entire
|
||||
job. (Since you are only using this for culling, you don't need the
|
||||
minus sign - just reverse the conditional).
|
||||
|
||||
The NEAR and FAR planes are typically parallel to the X/Y plane. That
|
||||
means that A and B are both zero and C is one (or minus-one) - but D is
|
||||
not zero, so the math boils down to an add and a negate:
|
||||
|
||||
|
||||
d = -(z + D)
|
||||
|
||||
|
||||
Conclusions.
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Sphere-based culling can be extremely cost-effective. It's so cheap
|
||||
that even if you feel the need to use a bounding cubeoid (or even a yet
|
||||
more complex shape), it's still worth doing a sphere-based cull first
|
||||
just to get rid of the trivial accept and reject cases.
|
||||
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
From owner-flight-gear@me.umn.edu Tue May 26 08:43:36 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["2090" "Tue" "26" "May" "1998" "08:42:09" "-0500" "Steve Baker" "sbaker@link.com" nil "69" "Re: [FGFS] View frustum culling" "^From:" nil nil "5" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: (from majordom@localhost)
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) id IAA29744
|
||||
for flight-gear-outgoing; Tue, 26 May 1998 08:43:36 -0500 (CDT)
|
||||
X-Authentication-Warning: meserv.me.umn.edu: majordom set sender to owner-flight-gear@me.umn.edu using -f
|
||||
Received: from lfkw10.bgm.link.com (bgm.link.com [130.210.2.10])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id IAA29740
|
||||
for <flight-gear@me.umn.edu>; Tue, 26 May 1998 08:43:31 -0500 (CDT)
|
||||
Received: from borgus.bgm.link.com (borgus.bgm.link.com [130.210.236.13])
|
||||
by lfkw10.bgm.link.com (8.8.6/HTI-Hack-8.8.4) with SMTP
|
||||
id IAA02170 for <flight-gear@me.umn.edu>; Tue, 26 May 1998 08:43:01 -0500 (CDT)
|
||||
X-Sender: steve@borgus.bgm.link.com
|
||||
In-Reply-To: <199805240245.VAA00603@kenai.me.umn.edu>
|
||||
Message-ID: <Pine.SGI.3.96.980526083427.2282G-100000@borgus.bgm.link.com>
|
||||
MIME-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Precedence: bulk
|
||||
Reply-To: flight-gear@me.umn.edu
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
Sender: owner-flight-gear@me.umn.edu
|
||||
To: flight-gear@me.umn.edu
|
||||
Subject: Re: [FGFS] View frustum culling
|
||||
Date: Tue, 26 May 1998 08:42:09 -0500 (CDT)
|
||||
|
||||
On Sat, 23 May 1998, Curtis L. Olson wrote:
|
||||
|
||||
> Gene Buckle writes:
|
||||
> > If you want to email me a cygnus/mesa binary, I'd be happy to give
|
||||
> > you new speed figures.
|
||||
>
|
||||
> Gene,
|
||||
>
|
||||
> The new binaries expect a modified scenery format. My impression for
|
||||
> now based on culled vs. drawn percentages is that there was a much
|
||||
> bigger jump between no culling and tile culling, than between tile
|
||||
> culling and fragment culling.
|
||||
|
||||
That's to be expected...
|
||||
|
||||
(The eye is in the center of the diagram - looking up:
|
||||
|
||||
No Culling - draw this much:
|
||||
|
||||
________\_____________/________
|
||||
| | \ | / | |
|
||||
| | \ | / | |
|
||||
|_______|___\___|___/___|_______|
|
||||
| | \ | / | |
|
||||
| | \ | / | |
|
||||
|_______|______\|/______|_______|
|
||||
| | | | |
|
||||
| | | | |
|
||||
|_______|_______|_______|_______|
|
||||
| | | | |
|
||||
| | | | |
|
||||
|_______|_______|_______|_______|
|
||||
|
||||
|
||||
Tile culling - draw this much:
|
||||
|
||||
_\_____________/_
|
||||
| \ | / |
|
||||
| \ | / |
|
||||
|___\___|___/___|
|
||||
| \ | / |
|
||||
| \ | / |
|
||||
|______\|/______|
|
||||
|
||||
|
||||
Tile *and* tstrip culling - draw maybe this much:
|
||||
|
||||
\_____________/_
|
||||
|_\ | /_|
|
||||
|_\ | / |
|
||||
|_\___|___/__|
|
||||
|\ | /_|
|
||||
|_\ | /_|
|
||||
|\|/|
|
||||
|
||||
Clearly most of the savings were in the tile culling, but providing the
|
||||
culling itself is done reasonably efficiently, the tstrip culling is
|
||||
still worth-while.
|
||||
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
-------------------------------------
|
||||
Please visit the FGFS web page: http://www.menet.umn.edu/~curt/fgfs/
|
||||
For help on using this list (especially unsubscribing), send a message to
|
||||
"flight-gear-request@me.umn.edu" with a single line of text: "help".
|
||||
|
||||
86
Hints/view-projection
Normal file
86
Hints/view-projection
Normal file
|
|
@ -0,0 +1,86 @@
|
|||
From fatcity!root@news.cts.com Mon Apr 20 10:54:32 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
|
||||
["2073" "Mon" "20" "April" "1998" "07:50:34" "-0800" "Steve Baker" "sbaker@link.com" nil "54" "Re: How To Q: Off-screen object culling." "^From:" nil nil "4" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mh2.cts.com (root@mh2.cts.com [205.163.24.68])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id KAA05163
|
||||
for <curt@me.umn.edu>; Mon, 20 Apr 1998 10:54:29 -0500 (CDT)
|
||||
Received: from king.cts.com (root@king.cts.com [198.68.168.21]) by mh2.cts.com (8.8.7/8.8.5) with ESMTP id IAA15636; Mon, 20 Apr 1998 08:51:20 -0700 (PDT)
|
||||
Received: from donews.cts.com (root@donews.cts.com [192.188.72.21])
|
||||
by king.cts.com (8.8.7/8.8.7) with SMTP id IAA29983;
|
||||
Mon, 20 Apr 1998 08:51:19 -0700 (PDT)
|
||||
Received: from fatcity by donews.cts.com with uucp
|
||||
(Smail3.1.29.1 #5) id m0yRI5D-00000Xa; Mon, 20 Apr 98 08:02 PDT
|
||||
Received: by fatcity.com (10-Feb-1998/v1.0f-b64/bab) via UUCP id 0001F042; Mon, 20 Apr 1998 07:50:34 -0800
|
||||
Message-ID: <F001.0001F042.19980420075034@fatcity.com>
|
||||
X-Comment: OpenGL Game Developers Mailing List
|
||||
X-Sender: Steve Baker <sbaker@link.com>
|
||||
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
|
||||
Errors-To: ML-ERRORS@fatcity.com
|
||||
Organization: Fat City Network Services, San Diego, California
|
||||
X-ListServer: v1.0f, build 64; ListGuru (c) 1996-1998 Bruce A. Bergman
|
||||
Precedence: bulk
|
||||
Mime-Version: 1.0
|
||||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||||
Content-Transfer-Encoding: 7bit
|
||||
From: Steve Baker <sbaker@link.com>
|
||||
Sender: root@fatcity.com
|
||||
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
|
||||
Subject: Re: How To Q: Off-screen object culling.
|
||||
Date: Mon, 20 Apr 1998 07:50:34 -0800
|
||||
|
||||
On Sat, 18 Apr 1998, Jason Maskell wrote:
|
||||
|
||||
> This is probably an FAQ, but I'm to the point now where I need to be
|
||||
> able to tell when one of my objects is offscreen and not even send it
|
||||
> down the pipe. This would be pretty simple if I was using glFrustum,
|
||||
> but I'm not at the moment. I could switch, but I haven't quite got my
|
||||
> head around how to get the same results as I get using glPerspective..
|
||||
> If someone can point me to some code that does some simple pre-culling,
|
||||
> I would be most grateful.. >
|
||||
|
||||
Well, if you can do it with glFrustum then you can do it with
|
||||
gluPerspective. Note that gluPerspective simply calls glFrustum.
|
||||
|
||||
It's like this:
|
||||
|
||||
void APIENTRY gluPerspective( GLdouble fovy, GLdouble aspect,
|
||||
GLdouble zNear, GLdouble zFar )
|
||||
{
|
||||
GLdouble xmin, xmax, ymin, ymax;
|
||||
|
||||
ymax = zNear * tan( fovy * M_PI / 360.0 );
|
||||
ymin = -ymax;
|
||||
|
||||
xmin = ymin * aspect;
|
||||
xmax = ymax * aspect;
|
||||
|
||||
glFrustum( xmin, xmax, ymin, ymax, zNear, zFar );
|
||||
}
|
||||
|
||||
[This is actually the source code for gluPerspective from the Mesa
|
||||
library - but since it only involves regular OpenGL API, it should
|
||||
work on any OpenGL implementation]
|
||||
|
||||
> BTW, I've bought the red book finally...
|
||||
|
||||
Always a good move. I have yet to hear anyone who regretted it.
|
||||
|
||||
Steve Baker (817)619-8776 (Vox/Vox-Mail)
|
||||
Raytheon Systems Inc. (817)619-4028 (Fax)
|
||||
Work: SBaker@link.com http://www.hti.com
|
||||
Home: SJBaker1@airmail.net http://web2.airmail.net/sjbaker1
|
||||
|
||||
--
|
||||
Author: Steve Baker
|
||||
INET: sbaker@link.com
|
||||
|
||||
Fat City Network Services -- (619) 538-5051 FAX: (619) 538-5051
|
||||
San Diego, California -- Public Internet access / Mailing Lists
|
||||
--------------------------------------------------------------------
|
||||
To REMOVE yourself from this mailing list, send an E-Mail message
|
||||
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
|
||||
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
|
||||
(or the name of mailing list you want to be removed from). You may
|
||||
also send the HELP command for other information (like subscribing).
|
||||
|
||||
112
Hints/win32-time-funcs
Normal file
112
Hints/win32-time-funcs
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
From nhv@laserplot.com Mon Mar 16 14:16:34 1998
|
||||
X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil]
|
||||
["1740" "Mon" "16" "March" "1998" "15:11:22" "-0500" "Norman Vine" "nhv@laserplot.com" "<01BD50EE.348AEBC0.nhv@laserplot.com>" "84" "RE: Today's patches" "^From:" nil nil "3" nil nil nil nil nil]
|
||||
nil)
|
||||
Received: from mail-out-0.tiac.net (mail-out-0.tiac.net [199.0.65.247])
|
||||
by meserv.me.umn.edu (8.8.8/8.8.8) with ESMTP id OAA21951
|
||||
for <curt@me.umn.edu>; Mon, 16 Mar 1998 14:16:33 -0600 (CST)
|
||||
Received: from mail-out-2.tiac.net (mail-out-2.tiac.net [199.0.65.13])
|
||||
by mail-out-0.tiac.net (8.8.8/8.8.8) with ESMTP id PAA20462
|
||||
for <curt@me.umn.edu>; Mon, 16 Mar 1998 15:16:26 -0500 (EST)
|
||||
(envelope-from nhv@laserplot.com)
|
||||
Received: from nhv (p1.gw1.mashp.MA.tiac.com [206.119.240.34])
|
||||
by mail-out-2.tiac.net (8.8.7/8.8.7) with SMTP id PAA26460
|
||||
for <curt@me.umn.edu>; Mon, 16 Mar 1998 15:17:02 -0500 (EST)
|
||||
(envelope-from nhv@laserplot.com)
|
||||
Received: by localhost with Microsoft MAPI; Mon, 16 Mar 1998 15:14:25 -0500
|
||||
Message-ID: <01BD50EE.348AEBC0.nhv@laserplot.com>
|
||||
Reply-To: "nhv@laserplot.com" <nhv@laserplot.com>
|
||||
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
|
||||
MIME-Version: 1.0
|
||||
Content-Type: text/plain; charset="us-ascii"
|
||||
Content-Transfer-Encoding: 7bit
|
||||
From: Norman Vine <nhv@laserplot.com>
|
||||
To: "'Curtis L. Olson'" <curt@me.umn.edu>
|
||||
Subject: RE: Today's patches
|
||||
Date: Mon, 16 Mar 1998 15:11:22 -0500
|
||||
|
||||
On Monday, March 16, 1998 2:31 PM, Curtis L. Olson [SMTP:curt@me.umn.edu] wrote:
|
||||
> Norm,
|
||||
>
|
||||
> I got both your patches. Thanks! The first one looks good, I'll
|
||||
> forward that over to the HUD guys.
|
||||
>
|
||||
> For the second one, could you try a little bit different fix? It
|
||||
> seemed to work for me anyways. Somewhere in fg_time.c you'll see the
|
||||
> following four lines:
|
||||
>
|
||||
> #ifdef WIN32
|
||||
> int daylight;
|
||||
> long int timezone;
|
||||
> #endif /* WIN32 */
|
||||
>
|
||||
> Could you just try moving them to the top of the file (outside of any
|
||||
> functions) so they have a "global" scope? I put 'em right before
|
||||
> fgTimeInit().
|
||||
|
||||
Seems to work :-)
|
||||
|
||||
>
|
||||
> I just did a quick test of this and I didn't see the sun jumping
|
||||
> around. I really wish I knew how to get the real daylight savings
|
||||
> time info out of a win32 machine ...
|
||||
|
||||
following time related stuff from CygWin headers
|
||||
|
||||
<Windows32/ Structures.h>
|
||||
|
||||
typedef struct _TIME_ZONE_INFORMATION {
|
||||
LONG Bias;
|
||||
WCHAR StandardName[ 32 ];
|
||||
SYSTEMTIME StandardDate;
|
||||
LONG StandardBias;
|
||||
WCHAR DaylightName[ 32 ];
|
||||
SYSTEMTIME DaylightDate;
|
||||
LONG DaylightBias;
|
||||
} TIME_ZONE_INFORMATION, *LPTIME_ZONE_INFORMATION;
|
||||
|
||||
typedef struct _SYSTEMTIME {
|
||||
WORD wYear;
|
||||
WORD wMonth;
|
||||
WORD wDayOfWeek;
|
||||
WORD wDay;
|
||||
WORD wHour;
|
||||
WORD wMinute;
|
||||
WORD wSecond;
|
||||
WORD wMilliseconds;
|
||||
} SYSTEMTIME, *LPSYSTEMTIME;
|
||||
|
||||
!!!!!!!!!!!!!!!!!!!!!!
|
||||
|
||||
<Windows32/ Functions.h>
|
||||
|
||||
DWORD
|
||||
STDCALL
|
||||
GetTimeZoneInformation(
|
||||
LPTIME_ZONE_INFORMATION lpTimeZoneInformation
|
||||
);
|
||||
|
||||
VOID
|
||||
STDCALL
|
||||
GetSystemTime(
|
||||
LPSYSTEMTIME lpSystemTime
|
||||
);
|
||||
|
||||
VOID
|
||||
STDCALL
|
||||
GetLocalTime(
|
||||
LPSYSTEMTIME lpSystemTime
|
||||
);
|
||||
|
||||
|
||||
DWORD
|
||||
STDCALL
|
||||
GetTickCount(
|
||||
VOID
|
||||
);
|
||||
|
||||
See Ya
|
||||
|
||||
Norman
|
||||
|
||||
|
||||
|
|
@ -89,6 +89,9 @@ public:
|
|||
#endif /* _AUTO_PTR_HXX */
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:41 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.2 1998/09/10 19:07:03 curt
|
||||
// /Simulator/Objects/fragment.hxx
|
||||
// Nested fgFACE inside fgFRAGMENT since its not used anywhere else.
|
||||
|
|
|
|||
|
|
@ -42,6 +42,9 @@ extern const int DefaultViewMode;
|
|||
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:41 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.2 1998/02/16 16:17:36 curt
|
||||
// Minor tweaks.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -301,6 +301,9 @@ inline const_mem_fun_ref_t<_Ret,_Tp> mem_fun_ref(_Ret (_Tp::*__f)() const)
|
|||
#endif // _COMPILER_H
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:40 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.9 1999/03/02 00:36:31 curt
|
||||
// Tweaks for native SGI compilers.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -170,6 +170,9 @@ fgMethodCallback<T>::call0v( void** )
|
|||
#endif // _FG_CALLBACK_HXX
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:41 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.2 1998/09/15 02:09:04 curt
|
||||
// Include/fg_callback.hxx
|
||||
// Moved code inline to stop g++ 2.7 from complaining.
|
||||
|
|
|
|||
|
|
@ -173,6 +173,9 @@
|
|||
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:40 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.13 1999/04/05 02:12:59 curt
|
||||
// Define maximum nodes for a tile here.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -59,6 +59,9 @@
|
|||
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:40 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.2 1998/12/09 18:47:39 curt
|
||||
// Use C++ style comments.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
// Alterations: Copyright C. Hotchkiss 1996
|
||||
//
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:40 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.2 1998/05/13 18:23:46 curt
|
||||
// fg_typedefs.h: updated version by Charlie Hotchkiss
|
||||
// general.h: moved fg_root info to fgOPTIONS structure.
|
||||
|
|
|
|||
|
|
@ -82,7 +82,10 @@
|
|||
|
||||
|
||||
/* $Log$
|
||||
/* Revision 1.1 1998/04/28 21:41:39 curt
|
||||
/* Initial revision of fg_zlib.h
|
||||
/* Revision 1.1 1999/04/05 21:32:41 curt
|
||||
/* Initial revision
|
||||
/*
|
||||
* Revision 1.1 1998/04/28 21:41:39 curt
|
||||
* Initial revision of fg_zlib.h
|
||||
*
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -65,6 +65,9 @@ extern FGGeneral general;
|
|||
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:40 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.1 1999/01/06 21:47:39 curt
|
||||
// renamed general.h to general.hxx
|
||||
// More portability enhancements to compiler.h
|
||||
|
|
|
|||
|
|
@ -1,139 +0,0 @@
|
|||
|
||||
/**********************************************\
|
||||
* *
|
||||
* W A R N I N G *
|
||||
* *
|
||||
* This file is now kept in reverse chronolog- *
|
||||
* ical order so recent changes are now at the *
|
||||
* top. *
|
||||
* *
|
||||
\**********************************************/
|
||||
|
||||
* 28th Sept 1889 -- Fixed a bug associated with exiting the
|
||||
program with sounds still playing.
|
||||
Fixed a bug associated with using the
|
||||
package in the absence of a sound card.
|
||||
Added a new member function "working"
|
||||
which is the opposite of "not_working",
|
||||
(as demanded by a bunch of rabid optimists)!
|
||||
Fixed a couple of typo's in the manual.
|
||||
|
||||
* 23rd Sept 1998 -- The Good News: Finally got around to
|
||||
getting the pitch envelope working. (Hooray)
|
||||
The Bad News: This costs quite a bit in
|
||||
performance - and it was a MAJOR rewrite
|
||||
of significant parts of the internals,
|
||||
so we may need some bug fixes.
|
||||
This version is 0.5
|
||||
|
||||
* 7th July 1998 -- Fixed some error checking in slSample.cxx and
|
||||
a missing declaration in sl.h
|
||||
|
||||
* 6th July 1998 -- Fixed an initialisation problem when
|
||||
slScheduler was not a static/global.
|
||||
|
||||
Tom Knienieder's port to SGI/IRIX is now
|
||||
working, documentation updated to reflect that.
|
||||
|
||||
* 16th June 1998 -- Added some slPortability.h fixes for
|
||||
FreeBSD and the Cygnus WIN32 compiler.
|
||||
Many thanks to Curt.
|
||||
|
||||
* 14th June 1998 -- Tom Knienieder's port to OpenBSD is now
|
||||
working, documentation updated to reflect that.
|
||||
Tom's improved Makefiles included, also some
|
||||
example sound samples that were accidentally
|
||||
left out of the release are now present.
|
||||
A couple of typo's in the WIN32 section
|
||||
have been fixed. The top level Makefile
|
||||
now requires you to type 'make linux',
|
||||
'make win' or 'make openbsd'.
|
||||
|
||||
* 13th June 1998 -- Tom Knienieder's port to WIN32 engine is now
|
||||
working, documentation updated to reflect that
|
||||
revised status. Some default constructor parameters
|
||||
have changed, slDSP no longer supports setRate/setBps/setStereo.
|
||||
You now have to delete the slDSP and recreate it with
|
||||
new parameters. This makes porting a little easier.
|
||||
'sound_test' renamed 'example'.
|
||||
|
||||
* 7th June 1998 -- Volume envelopes (and inverse volume envelopes)
|
||||
now work correctly. Pan envelopes won't work
|
||||
until stereo is implemented. Pitch and filter
|
||||
envelopes turn out to be a major pain to implement
|
||||
with the present slSceduler/slSamplePlayer interface,
|
||||
so some significant internal changes are to be
|
||||
expected.
|
||||
|
||||
Changed the CHANGES file to be in reverse
|
||||
chronological order.
|
||||
|
||||
This version is officially SL v0.3 (beta)
|
||||
|
||||
* 3rd June 1998 -- Moved sample program and it's data files into
|
||||
'example', moved documents into 'doc' and sources
|
||||
into 'src'. Final library goes into 'lib'.
|
||||
|
||||
The entire preempting mechanism was broken -
|
||||
now it's fixed.
|
||||
|
||||
Added a callback mechanism that allows
|
||||
applications to know when a sound
|
||||
loops, finishes playing, is pre-empted, etc.
|
||||
|
||||
New mechanisms added to stop/pause/resume a
|
||||
playing sample.
|
||||
|
||||
All the documentation - and some of the code -
|
||||
for slEnvelopes has been added, they don't
|
||||
work yet - so don't bother with them for now.
|
||||
|
||||
Made some code a little more bullet-proof.
|
||||
slSample's are now reference-counted so you
|
||||
can't accidentally delete one while it's
|
||||
playing without getting a FATAL error.
|
||||
|
||||
* 2nd June 1998 -- Fixed bug in initialisation that prevented SL
|
||||
from functioning correctly in the case were there
|
||||
is no sound card present.
|
||||
|
||||
This version is officially SL v0.2 (beta)
|
||||
|
||||
* 1st June 1998 -- Split library into two parts - libsm and
|
||||
libsl. libsm contains only the Mixer class
|
||||
since it is likely to be hard to port to
|
||||
a lot of non-OSS systems - and most programs
|
||||
won't need it anyway. Hence the documentation
|
||||
has blossomed into three files and all the
|
||||
'slMixer' references have turned into 'smMixer'.
|
||||
Also, I finally got a hold of the OSS documentation,
|
||||
which is a lot more complete - and straightened
|
||||
me out on a few points. slDSP has changed
|
||||
(internally) somewhat as a result and in particular,
|
||||
you can no longer mess with the sampling rate,
|
||||
stereo and bps settings after the slDSP or
|
||||
slScheduler has been created. This also allows the
|
||||
scheduler to enforce it's rule about only mono/8bps
|
||||
operations.
|
||||
|
||||
I also added an 'autoMatch' function to the slSample
|
||||
class to automagically match incoming samples to the
|
||||
current slDSP/slScheduler. This makes using the library
|
||||
a lot less painful and error-prone.
|
||||
|
||||
This version is officially SL v0.1 (beta)
|
||||
|
||||
We need a better name!
|
||||
|
||||
* 30th May 1998 -- Almost total rewrite, library can now
|
||||
play multiple sounds without interruption,
|
||||
supports '.WAV' and '.AU' file formats as
|
||||
well as raw binary files. Able to copy with
|
||||
much shorter safetyMargin on sound buffers,
|
||||
and play without using the 'stop' call.
|
||||
All class and external symbols now begin
|
||||
with 'sl' or 'SL'. HTML documentation now
|
||||
available.
|
||||
|
||||
* 27th May 1998 -- First hack
|
||||
|
||||
|
|
@ -1 +0,0 @@
|
|||
SUBDIRS = src example
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
NOTICE: This Sound Library (SL) distribution contains source code that is
|
||||
placed into the public domain without copyright. These programs are freely
|
||||
distributable without licensing fees. These programs are provided without
|
||||
guarantee or warrantee expressed or implied.
|
||||
|
||||
If you use SL in a commercial or shareware product, it would be nice if you
|
||||
gave credit where it is due. If you make any modifications or improvements
|
||||
to SL, I would greatly appreciate a copy of the improved code.
|
||||
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
|
||||
Hi!
|
||||
|
||||
This is the fifth prototype of Steve's 'SL' sound library.
|
||||
|
||||
Check out 'CHANGES' and the new HTML documentation.
|
||||
|
||||
Steve
|
||||
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
|
||||
Building SL for Linux.
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
% make freebsd
|
||||
% su root
|
||||
% make install
|
||||
|
||||
...that's all folks.
|
||||
|
||||
Header files go into /usr/include/SL (analogous to /usr/include/GL for graphics)
|
||||
Library file(s) go into /usr/lib
|
||||
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
|
||||
Building SL for Linux.
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
% make linux
|
||||
% su root
|
||||
% make install
|
||||
|
||||
...that's all folks.
|
||||
|
||||
Header files go into /usr/include/SL (analogous to /usr/include/GL for graphics)
|
||||
Library file(s) go into /usr/lib
|
||||
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
|
||||
Building SL for OpenBSD.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
% make openbsd
|
||||
% su root
|
||||
% make install
|
||||
|
||||
...that's all folks.
|
||||
|
||||
Header files go into /usr/include/SL (analogous to /usr/include/GL for graphics)
|
||||
Library file(s) go into /usr/lib
|
||||
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
|
||||
Building SL for SGI.
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are two options, depending on whether you want to use GCC or
|
||||
the standard SGI C++ compiler.
|
||||
|
||||
GNU G++:
|
||||
|
||||
% make sgigcc
|
||||
% su root
|
||||
% make install
|
||||
|
||||
SGI C++:
|
||||
|
||||
% make sgi
|
||||
% su root
|
||||
% make install
|
||||
|
||||
...that's all folks.
|
||||
|
||||
Header files go into /usr/include/SL (analogous to /usr/include/GL for graphics)
|
||||
Library file(s) go into /usr/lib
|
||||
|
||||
When you link, be sure to include to -laudio
|
||||
|
||||
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
Building SL for UNIX
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If your UNIX box is Linux or OpenBSD then
|
||||
check out README.linux or README.openbsd.
|
||||
|
||||
If your UNIX box supports OSS (the Open
|
||||
Sound System) then in principal, you should
|
||||
only need to type:
|
||||
|
||||
% make oss
|
||||
% su root
|
||||
% make install
|
||||
|
||||
...however, your milage may vary. If you succeed
|
||||
in getting a non-Linux, non-OpenBSD version to
|
||||
work, I'd like to hear about it.
|
||||
|
||||
Steve Baker <sjbaker1@airmail.net>
|
||||
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
|
||||
Building SL for win32 (msvc)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
C:>nmake win32
|
||||
|
||||
|
||||
don't forget to set the environment !
|
||||
|
||||
example:
|
||||
|
||||
set include=c:\msdev\include;
|
||||
set lib=c:\msdev\lib
|
||||
|
||||
path c:\msdev\bin;c:\bin;c:\winnt;......
|
||||
|
|
@ -146,6 +146,9 @@ void fgBucketDiff( const FGBucket& b1, const FGBucket& b2, int *dx, int *dy ) {
|
|||
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:34 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.4 1999/03/27 05:34:05 curt
|
||||
// Elimitated some const warnings from the compiler.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -330,6 +330,9 @@ operator== ( const FGBucket& b1, const FGBucket& b2 )
|
|||
|
||||
|
||||
// $Log$
|
||||
// Revision 1.1 1999/04/05 21:32:34 curt
|
||||
// Initial revision
|
||||
//
|
||||
// Revision 1.8 1999/03/27 05:34:06 curt
|
||||
// Elimitated some const warnings from the compiler.
|
||||
//
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue