David Megginson wrote:
Jon S. Berndt wrote:
I'd like to consider using this to send the sound manager events of
interest, but a protocol for message passing must be reached.
Jon sent me some ideas by private mail, and they look workable -- it
really comes down to a judgement call about
David Megginson wrote:
Alex Perry wrote:
Many Cessnas have a small metal tab that sticks out of the front of
the wing, at the stagnant airflow point for the desired angle of
attack.
Do you have to turn it off manually when you're sitting on the tarmac
or taxiing slowly?
It
Don Baker wrote:
It isn't gravity. It is simply that only at high angle of attack
conditions is there enough air to shove it upward.
Ahem, shove it upwards against what force? :)
At zero speed, there is zero aerodynamic force. What holds it down,
if not gravity? At least on the Cherokee
OK, as promised, I've put together a first release of my YASim (sue
me, I couldn't think of a better name) FDM for FlightGear. Actually,
I promised over on the flightmodel list, for those who aren't
subscribed. Basically, this is a rough, first cut of a different
take on FDM design. It's
Dave Luff wrote:
John Wojnaroski writes:
Some want to work spins, prop contact points, etc. But a LOT of
accidents occur because the PIC failed to do a proper weight and
balance, overloaded the A/C, and/or exceeded the CG
limits. Something to consider - how about a weight and
David Megginson wrote:
Since we have the YASim FDM in the FlightGear source tree, it makes
sense to add Andy's four config files to the base package. Right
now, YASim looks for the config files in $FG_ROOT/Aircraft; that's
probably going to be a bit confusing, since the JSBSim models are
I'm not quite sure how things got out of hand this time, but they sure
did...
Norman Vine wrote:
Andy Ross wrote:
OK, clearly I have to cut out the microsoft stuff. So noted. And it
wasn't a windows.h problem, but instead with cygwin. And the
no-underscore-followed-by-capital
John Check wrote:
Andy Ross wrote:
For me? Neither:
Aircraft carrier!
Pretty sure Objects/Geometry/saratoga.obj is a carrier
You're kidding, really? OK, I feel dumb.
I've never touched the geometry side of fgfs, so any pointers would be
appreciated. What can I use to look
Erik Hofman wrote:
Err, I must confess I actaully found it! (Man, MipsPro has way too
many compiler switches, it was hidden int the
-LANG:ansi-for-init-scope=ON flag).
Anyway, I won't bug you any more with this :-)
Doh! Too late, I already changed it. :(
It turns out the MSVC has
I found the following magazine review, which I used to fix the
performance of the YASim model. It's the turbo variant.
http://www.planeandpilotmag.com/content/specs/79cessnaturbo.html
Also, this site, which is a buyer's guide for the 310 family, has lots
of good trivia about equipment
Christian Mayer wrote:
But one other observation: I couldn't lift of with the YAsim C310 (172
and 747 worked fine). I can accelerate and pull. The front lifts of
but i'm not gaining any altitude.
Was your engine RPM stuck at 1700? There is a version skew problem
with the c310.xml file.
Just in case someone is wondering, this is a definition that eluded me
for a LONG time: what, exactly, is mixture. Mixture is this: the
ratio, by volume (!) of the liquid fuel and gasseous air being drawn
into the cylinders. That's why it has to be adjusted with altitude --
the liquid densities
Ross Goldner wrote:
The CVS commit logs don't provide much info. Can they be made to send
the changes made, too, so people can see the actual detail of the change
(as a diff -u).
No need. Check out cvs diff. :)
Or maybe I'm misunderstanding what you want?
Andy
--
Andrew J. Ross
Norman Vine wrote:
G..
One of those variables that only lives in the 'ether world'
A VERY GOOD REASON for these things to live in a real 'C'
variable ..
I think you misunderstood. It *does* live in a real C variable
(FGInterface::Tank1Fuel). That variable never got
Jim Wilson wrote:
Andy Ross writes:
3. Reading information that the FDM hasn't set shouldn't cause a crash.
Same with reverse?...seems like the problem with JSBsim and using
threads has to do with shared memory, one thread reading before or
while the other writes.
Eeep
John Check wrote:
Andy Ross wrote:
I assume these changes are already in the queue for the base package.
but. but.
Sorry, my fault. I had a sticky date tag in my base package. No, I
can't for the life of me remember why. Of all of CVS's quirks, this
is the worst; doing a cvs
John Wojnaroski wrote:
Are we sub-optimizing to a point design for convience? Okay some
things get better, but it sounds like this will bypass some of the
basic ideas behind C++.
Which ideas? Encapsulation? No, we got that in properties via the
tie mechanism. Composition? Yup, got that
Jim Wilson wrote:
Mainly I just want to focus on getting a really nice looking panel
without getting too hung up in doing everyting at once. Probably
I'll add pilars if any would show facing forward and then possibly
very plain doors (if it looks too much like you're sitting in a
Norman Vine wrote:
Here is some code to translate the HUD with the eye vector
for those that want to play :-)
That won't work, though. The translation approximation is good only
for small panning angles, which is violated in a big way by the
virtual cockpit notion. I want to pan by 180
Erik Hofman wrote:
Do you have any idea if the mmap() function is available on all
platforms? This is basically like a one shot read of the airports file
into memory (but instead leaving it on the drive). It would be easy to
search the memory location then.
Bad idea. This means that the
David Megginson wrote:
Andy is the first easyxml user outside the property manager, so this
is the first time the problem has come up.
Andy: would you object if I made the fix in YASim in the FlightGear
CVS tree after fixing the problem in SimGear?
Not at all, we should clearly have
David Megginson wrote:
Andy Ross writes:
The reason this bites only YASim, I suspect, is that I'm the only
non-SimGear code that actually uses this file. Everything else uses
the PropertyTree wrapper parser instead. I didn't know about this
at the time, so I just used the raw SAX
Erik Hofman wrote:
Please correct me if I'm wrong, but to my understanding namespaces are
like classes but without the overloading and such?
Namespaces are just namespaces. :)
Some languages call them packages or modules, but the idea is
really simple: a symbol (function, class, global
[bouncing this to flightgear-devel from flightgear-flightmodel]
David Megginson wrote:
Curtis L. Olson writes:
[about sloping runways]
Depending on how much we trust the underlying DEM data, they may or
may not be deliberate ...
We shouldn't trust our DEM data at all even at
Jon S. Berndt wrote:
Alex wrote:
For starters, can the JSB filters (etc) stuff be used without
JSBSim?
The base class of all JSBSim classes - including the FCS classes - is
FGJSBBase. So, technically, no.
This would be a good feature to look at breaking out of the FDM. At
its most
Julian Foad wrote:
In my experience, debugging FG (single-stepping, run-to-here, etc.) is
almost impossible under GDB and I believe the OpenGL I'm in charge of
the main loop philosophy is the main cause.
I've successfully and productively run fgfs under gdb just fine. I'm
not sure there's
Geoff McLane wrote:
JSBSim stops after the QNAN's,
and now YASim c172 seems unable to get speed to lift off ...
Just one of those days ...
Odd. Jim Wilson also reported a not enough power situation (with
the YASim 747) that I couldn't reproduce. I didn't think to ask about
platform.
Christian Mayer wrote:
Off course. As I wrote in my mail it's no problem to add additional
include/library directories. But I don't see a reason to add
K:\Projekte\SimGear\simgear\zlib or ..\SimGear\simgear\zlib to the
include directory. The include directory should have only intuitive
Melchior FRANZ wrote:
Andy Ross wrote:
There's also a complication with the Harrier. You'll need to map a
joystick axis to the /controls/thrust-vector[0] property in order to
work the thrust vectoring.
Works also reasonably well when mapped to the low/high properties
Boslough, Mark B wrote:
I am again trying to compile the CVS version of FlightGear. I *think*
I am following instructions! I have not had any trouble building the
version 0.7.8, but with CVS I get the following compile error:
Not to be too snooty, but sometimes it's helpful to actually
John Wojnaroski wrote:
both 747 and f15 seem to be underpowered. or possibly too much drag?
Can't hold a vertical climb in the f15 and can only get to mid
altitudes in
the teens with 747
This is the second time this has been reported, but I can't reproduce
it. Your note later on,
John Wojnaroski wrote:
New question. controls for teh gear and flaps? will the existinig
bindings for the keyboard work?
Are the gear and flap values now properties?
The gear is controlled by /controls/gear-down, a boolean. The flaps
are in /controls/flaps, a floating point number from
John Wojnaroski wrote:
Also, does the gear still exhibit extention/retraction delays. Is
there a fgGetDouble(/controls/gear[n]-position') or something like
that which returns a value from 0 to 1?
Aerodynamically, yes. The gear is interpolated from all to none
over the retract-time
Jon S. Berndt wrote:
Christian Mayer wrote:
Get a card with TL setup (i.e. a GeForce or a Radeon). FlightGear
profits heaps from the TL setup.
How?
Presumably because most (all? I didn't check) of the geometry is
stored in display lists. These can be stored on-card and eliminate
the
Curtis L. Olson wrote:
D Luff wrote:
YASim initialised at about 40 knots charging down the runway,
with the engines running and the magnetos off. Due to the
aformentioned full left aileron I didn't get very far.
Yes, YASim engine start procedures need to be on the todo list
Cameron Moore wrote:
Safety board says pilots can cause tail fin to break off
http://www.cnn.com/2002/US/02/08/ntsb.flight587/index.html
IANAPNAE, but this sounds like they're blaming the pilot for a weak
tail fin. Thought it was interesting...
There's politics at work here
Curtis L. Olson wrote:
The 747-yasim-set.xml file references a non-existant panel. Is there
something better we can use in the mean time? Or just not specify a
panel until we have one we can use?
I've been wondering about that myself. :) I figured it was checked in
this way because
John Wojnaroski wrote:
Melchior FRANZ wrote:
That's the metakit. You find it in in the SimGear directory. Just have
to compile and install it.
Right! I thought I caught that when building SimGear and it complained
about finding the metakit. followed the readme steps. The library
Jim Wilson wrote:
Are you talking about the newer 3D model or newer xml? I'm not sure
exactly what affects the position of the model, but using Yasim-DC3
any model including the glider is sideways.
Now, that's interesting. I'd just assumed this was a modelling issue,
but you're saying
Curtis L. Olson wrote:
Ok, looking further, it appears that nothing, no place, no where is
setting the runway elevation any more ... it get's initialized at
startup, but then never is updated as the aircraft moves.
Ah, which explains why I've never seen this. I only ever bother
testing in
Curtis L. Olson wrote:
JSBSim properly handles updating the runway/ground elevation most of
the time, but here is at least one situation where it doesn't. YASim
doesn't handle this at all (but Andy's the new kid so we can cut him
some slack.) :-)
Uh, stupid question: where do I stick
Curtis L. Olson wrote:
Andy Ross wrote:
Uh, stupid question: where do I stick the number? I can't imagine
this is difficult to fix.
Should be a breeze.
Essentially you are assuming that the runway elevation field in the
FGInterface structure is getting updated externally
Martin van Beilen wrote:
Unfortunately the script won't work very well with JSBSim. JSBSim's
aileron trim is so insensitive that it can't even compensate for one
notch of rudder. (IANAP, so I don't know how realistic that is.)
YASim's aileron trim seems to behave like a secondary aileron
Martin van Beilen wrote:
Andy Ross wrote:
But... sh and awk?
Goodness gracious, learn some perl, man! :)
I'm fluent in Perl, thank you very much. However:
ls -l /usr/bin/{awk,nc,perl}
- -rwxr-xr-x 2 root root88236 Jun 19 1999 /usr/bin/awk*
- -rwxr-xr-x 1 root
Martin van Beilen wrote:
I think I am beginning to understand what the source of the
confusion is. As most of you know, weather reports specify the winds
as a _from_ heading. However, in simulated space I tend to think of
wind as a vector, i.e. a _to_ heading. Apparently, two out of three
David Megginson wrote:
Jim Wilson writes:
And the question that brings to mind is, how will we be able to set
the z axis in a way that it can handle the panel? In other words,
the scale is so large now that it'll disappear just like airplane
model components do when viewed too
[This didn't seem to come through the first time. Apologies if you
see it twice.]
Here's a fun toy. I've been using the property picker a lot recently,
while working on a panel for the Harrier. Sometimes it gets difficult
to find the property you're looking for in a crowded tree. The
Martin Spott wrote:
I had some tests with 0.7.9 source and today's CVS (_very_ nice panel), with
0.7.9 base package and today's CVS, I tried different airports but the
'feature' is still there: Several models tend to bank to the left when the
stick is in the middle:
c172-larcsim does
Martin Dressler wrote:
Please start with some yasim aircraft and apply parking break. Look
at skid ball. I thought that it should be in the middle of tube, when
sitting on runway. but it isn't.
Hrm... that one's weird. I'm on it, no ideas yet.
Andy
--
Andrew J. Ross
Tony Peden wrote:
Andy Ross wrote:
Martin Dressler wrote:
Please start with some yasim aircraft and apply parking break.
Look at skid ball. I thought that it should be in the middle of
tube, when sitting on runway. but it isn't.
Hrm... that one's weird. I'm on it, no ideas
Tony Peden writes:
Just for the record, what's most likely happening here is that since
JSBSim senses that the gear are underground on the first update(), the
gear code calculate a reaction force based on how far underground they
are.
One thing you might try is clamping the gear force to
John Wojnaroski wrote:
On the 747 YASim model, have not been able to slow to a resonable
approach speed 150kts and maintain altitude, run out of elevator
authority around 184 kts and flap settings seem to have no effect. The
numbers I have in my 747 flight manual don't match up with what
Jim Wilson wrote:
IIRC the 747-400 comes down pretty fast anyway. I think you're
looking at 195 KIAS range for final dropping down to 175 KIAS (with
full flaps) at the outer marker. But note again, this is from
memory. Still, there is no way that pig flies at 150.
The biggest
Jim Wilson wrote:
Yes agreed. And probably with a 747-400 it is only those longer
flights like London-Vancouver that get filled to the brim with fuel.
Andy, is the aircraft otherwise considered filled to capacity
(passenger/cargo) in the fdm?
Um... I'm not sure. :)
The configured
Martin van Beilen wrote:
Actually it is fairly easy to make the property manager Thread
Safetm. All regular r/w locking can happen on a per-node basis, and
can be encapsulated transparently. The property manager seems like an
ideal candidate for IPC messaging, so if we want, it can be
Martin van Beilen wrote:
Andy Ross wrote:
For those with Java experience, consider the Vector class. It's
threadsafe, right?
No, it's not. Imagine what happens when one thread is reading it
while another thread is writing to it. :-)
Right. Now enumerate over it in one thread
Alex Perry wrote:
David Megginson wrote:
I've been wondering for a while - suppose I take a non-force
feedback yoke, and attach a wheel that actually moved the neutral
position by moving the end points of both springs backwards or
forwards, and use this instead of the software trim,
Jim Wilson wrote:
Also noticed the rudder control seems to be broken on the dc3 at the
moment.
Blame David. :)
The DC-3 is a taildragger, and therefore doesn't have a steerable
wheel to turn with. Instead, real aircraft use differential braking
to do this.
The problem is, typical control
Wow, good stuff. Skimming through to apply my own intuition:
6.99% ssgEntity::cull_test
5.28% ssgBranch::cull
4.85% ssgVtxTable::draw_geometry
3.42% FGHitList::IntersectLeaf
3.28% FGHitList::IntersectBranch
2.85% ssgVtxTable::getNumVertices
2.71% sgFrustum::contains
1.85% sgdPointInTriangle
I spent most of today working on a virtual cockpit interface for the
panel, and I'll be damned, it works!
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply
Curtis L. Olson wrote:
Martin Dressler writes:
I'm now working on Ground view mode and I just go through code to
fully understand the problem. I find some small nearly cosmetic
bugs. What is the best way to rapair them. Should I make diff of
affected code or should I tar the whole
Tony Peden wrote:
Andy Ross wrote:
+ They're more human readable. Inevitably, you're going to be doing a
diff between revisions to see what's changed anyway. This just give
it to you up front. If you want to look at more surrounding code,
you certainly can, but everyone
Curtis L. Olson wrote:
It does do a pretty darn good job all things considered, but it's not
magic and it can't figure the 'right' thing to do given a conflicting
situation. And the number of times conflicting situations arise is
more than most patch apologists would probably admit. :-)
David Megginson wrote:
Changes for gear and flaps are still abrupt, but I have great faith
that I'll be able to get the normalized gear and flap positions from
YASim very, very soon now.
Actually, now that the subject's been brought up, I realize that YASim
doesn't time-interpolate the
John Check wrote:
Andy Ross wrote:
One rocker axis on the throttle to simulate rudder (not very
well -- I still use my analog TM pedals for that).
Rudder control is really what I'm interested in. I tried binding the
throttle wheel of my gravis Blackhawk, but the pot is super cheesy
Tony Peden wrote:
David Megginson wrote:
Tony Peden wrote:
I certainly like the idea of having some sort of units indicator
on every property name, though I agree risk of breakage is high
in this case.
I can change everything in FlightGear and the base package, but I'm
David Megginson wrote:
Andy Ross writes:
I agree in general. I'd suggest the use of -fraction or somesuch
instead of -pct if the range is 0:1, as it is for most of these
properties currently.
An earlier suggestion was -n for normalized, which is probably the
most accurate
Jim Wilson wrote:
But if those settings don't represent a form of units--just arbitrary
values, why do they need a suffix? The suffixes were intended to
reflect units and make sense only when they mean something, like
knowing if the value is in feet or meters, degrees or radians, knots
Erik Hofman wrote:
Jon S. Berndt wrote:
Erik Hofman wrote:
Christian Mayer wrote:
Jon S Berndt wrote:
In my mind, mass is in kg. and force is in Newtons.
That's correct.
Are you sure [...]?
See?
My bad
Oh, dear. Time for the whirlwind tour of unit conventions.
I just checked in YASim changes that allow for more cleaner export of
control output to the property tree (and flaps now extend slowly now,
to boot). But this breaks the XML syntax in an incompatible way, so
you'll need to update your planes in order to run the code in CVS.
Get the new planes
David Megginson wtore:
Alex Perry writes:
How about tackng -1 on the end ?
That's nice, but since Tony and Andy have agreed on -norm, we may as
well leave the whole discussion closed.
Oooh, actually I really like -1. Shorter and really obvious. Alas
that it's too late. I weep for
John Check wrote:
Andy Ross wrote:
I did try these out against David's (freakishly cool) model
animations, though, and they seem to work really well modulo a few
direction/orientation conventions. The DC-3 gear do indeed pull up
slowly.
I'm not seeing the slow gear transition
Erik Hofman wrote:
David Megginson wrote:
Erik Hofman wrote:
If I see it right, you could do that in the animation files also
by having different factor falues, doesn't it?
Probably, but then the sound wouldn't sync up.
I could change the pitch a bit (changing factor also).
David Megginson wrote:
For some reason, the animations are not working with the YASim Cessna
310 model (despite the fact that the same kinds of animations work
fine with the YASim DC-3). I cannot find anything obvious in the
config file, but perhaps Andy could take a glance.
It's not
David Findlay wrote:
Andy Ross wrote:
I spent most of today working on a virtual cockpit interface for the
panel, and I'll be damned, it works!
Umm, one problem. When you look down, the panel follows the bottom of
the screen. Other than that it's great. We just need the interiors
Curtis L. Olson wrote:
David Megginson writes:
David Findlay writes:
It appears that the plane is above the runway at least with the c172.
It's very hard to get it exactly right.
Another thing that might be helpful is if the FDM's would report the
amount of each gear
John Wojnaroski wrote:
I added the tags to the 747 file, but it appears the code is not
exporting a value for the nose gear or the flap settings.
Can you post what you changed? I'm not sure from the above exactly
which tags went where. Certainly, if you put the right tags in the
right
Curtis L. Olson wrote:
Andy Ross writes:
No problems there. YASim now reports this number in
/gear/gears[n]/compression-norm (should be an OK choice, according
to our rapidly evolving property conventions). The remaining
problems are only bookkeeping. We need to make exactly
John Wojnaroski wrote:
How complete is the 747 wing model for slats, spoilers? Note they are
in the XML file; is it just a question of specifying the control axis
input.
Indeed. I have the /controls/spoilers property bound to the same
joystick axis I use for mixture (or maybe propeller
Curtis L. Olson wrote:
I'm really nervous about forcing this down to 0.1 for all cases. This
will mess things up for people with voodoo cards.
Can we change this back?
Perhaps we need to do a separate pass for rendering the 3d model and
change the near clip plane just for that
Jim Wilson wrote:
Ummm...why not clear the z-buffer and use a seperate scene graph?
Note that there are *lots* of people using pre-geforce generation
hardware. Probably more than not.
Actually, it's those folks who are at risk. Clearing the whole z
buffer soaks up big chunks of
Here's another batch of virtual cockpit stuff. There is a patch
attached, and the two modified files in full can be found at:
http://www.plausible.org/andy/vc-20020305.tar.gz
Folks who want to try the patch (it's easy, really!) can just get into
their just-updated FlightGear source
Erik Hofman wrote:
I have a propblem with a peace of CC code which is pretty standard for
common C. When I define a structure and point an array to a
pre-defined array;
[...]
this works for C but not for CC? Am I doing something wrong here, or
doesn't CC allow this type of
Dave Luff wrote:
So supposing a pilot is communicating with approach on comm1, but has
comm2 monitoring the tower, what happens if a stronger tower
transmission is received at the same time as an approach transmission?
It doesn't have anything to do with signal strength. The two radios
Danie Heath wrote:
I'm extremely eager to start developing, but I can't because metakit
won't compile on my Linux system.
This is flatly incorrect. Metakit builds just fine on your Linux
system.
Hey, if you don't provide any documentation for your problems, then I
won't document my
Paul Deppe wrote:
A related question - after rebuilding with the makefile system, is
there a way to make install only the files which have changed? For
example, suppose there is only a change to a .cxx file in plib/ssg. I
do a make, which rebuilds only libplibssg.a. But when I do a
John Wojnaroski wrote:
Bottom line: trying to run fgfs and opengc across the network with
different platforms (in this case linux and cygwin) results in each
side having a different value for the class in raw_ctrls.hxx and the
socket read operations fail.
I think the problem is
Richard Bytheway wrote:
I was having a fiddle with keyboard.xml to support a UK keyboard,
and discovered that the characters £ and ¬ (which are shift-3 and
shift-key to left of 1) break the XML parser. Is this intentional?
Also, in the grand re-organisation of the XML files that appears
David Megginson wrote:
I disagree -- the view code gets *very* hard to understand very
easily. If that information is tracked, it should be tracked
externally (the view manager, again?) and not in the viewer code
itself.
Amen. I spent many hours over the weekend trying to make the view
[A bunch of notes on Norm's notes. Basically, everything he wrote
(even the editorializing) makes sense to me, with a few exceptions as
detailed below]
Norman Vine wrote:
Easy beans - no gimble lock - infinitely stackable orientations -
everything has it's own logical spot - quick -
Norman Vine wrote:
David Megginson wrote:
Thanks -- the internal cockpit view seems much better. Now the ball's
in Andy's court to patch up the virtual panel code (and de-quat the
mouse code), and we're flying!
exactly the kind of response that led me to coin the phrase
MAYDAY
While I'm thinking about it, can someone with knowlege please let me
know that I've got the right facts for the following coordinate
systems:
Model coordinates (that is, the reference frame of the local aircraft,
into which the model and panel geometry will be drawn):
Origin = nose of the
Andy Ross wrote:
Model coordinates (that is, the reference frame of the local aircraft,
into which the model and panel geometry will be drawn):
Origin = nose of the aircraft (?)
X = backwards
Y = up
Z = left
First confusion: the /sim/view/pilot/{x,y,z}-offset properties don't
Norman Vine wrote:
Andy Ross wrote:
The location of the scenery origin is another.
I thought I that this would have been self evident apon reading the
code sections I pointed out yesterday.
But just to be clear
THERE IS NO FIXED SCENERY ORIGIN
Norman, stop it. The world may
David Megginson wrote:
Wolfram Kuss writes:
Are r,p,h relative to the plane or the current view?
I imagine two RPH vectors: the main vector (which would in some cases
be the orientation of the plane) and the offset vector, which are
relative to the main ones. For the pilot view,
David Megginson wrote:
Andy Ross writes:
The scenery center is set out of the main loop, and looks to me
like it can be easily replaced with the eyepoint with no loss of
function.
That sounds like an excellent idea. Are there any hidden gotchas?
None yet. Code that doesn't exist
Jon S. Berndt wrote:
I don't know if this applies at all, but it worries me to hear what
Andy wrote about the code going away. Will this have any impact on the
ability to calculate the location, height, and orientation of an
aircraft on a tile given the tile may have a non-vertical
This looks really good to me. A few nits below, based on the way I
think about the problem.
David Megginson wrote:
1. looking from a known position outwards
2. looking at a known position from an offset
3. looking at one known position from another
Heh, cockpit, chase and tower. I
David Megginson wrote:
Curtis L. Olson wrote:
For internal views, a heading and pitch offset to the view makes
sense.
And roll, for that matter -- I don't see any good reason to leave out
one degree of freedom. Think of a tail-gunner view in a bomber for
one example of where we
David Megginson wrote:
Andy Ross wrote:
Nit: those should be sgMat4's, right? Or are you returning a
pointer to an array of four vectors?
Returning sgMat4's seems to cause compiler problems, and this is how
Norm had it before.
Why not use an output parameter then:
void
1 - 100 of 1282 matches
Mail list logo