Russell Suter
David Megginson wrote:
Andy Ross wrote:
I'm not sure exactly what this is for. I can (and
probably should)
export the C.G. position for the view code to use
appropriately. But
the VRP stuff seems like a double-correction. It's basically
identical to the
snip
Anyone got any wavefile editor recommendations BTW? I used
CoolEdit (Windows) for the ATIS, but the trial period is now
long gone, and when I went to buy it I found the guy had sold
it to Adobe and the price had tripled. No thanks! I'm using
Audacity now, but it's not entirely
Can someone file a formal complain to this Microsoft patent:
This may be a good starter page for anyone wanting to file a protest:
http://www.uspto.gov/main/faq/p340030.htm
Mally
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version:
Vivian Meazza writes:
I remain disconcerted that the visual model appears to roll through 180 degs
vertically on the up and down legs of a loop when in chase or helicopter
view. Not the end of the world, but lacking realism.
Yes this is a short coming of the math method used.
Note that the
Jim Wilson wrote
Vivian Meazza [EMAIL PROTECTED] said:
Josh Babcock
Vivian Meazza wrote:
I enter the loop in a shallow dive, 2nd stage boost on, 350
kts, pull
baaack the stick and the model rolls violently and does not
enter the
loop ... Works fine in
Holy ... !
JSBSim has been doing this for some time, now. I can't remember just how
long, We include XML scripts from other scripts. The claim that this is
patentable is absurd.
Jon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Mally
Sent: Friday,
* Vivian Meazza -- Friday 13 February 2004 13:19:
Could the prop pitch be the problem
Unlikely -- it's already maximum by default.
- I can't find any method of controlling it
Either via http/telnet/property browser:
/controls/engines/engine[n]/propeller-pitch
Some joystick configs
Jon Berndt [EMAIL PROTECTED] said:
David Megginson [EMAIL PROTECTED] said:
It's the location on the plane where the FDM reports the
lon/lat/alt. It's kind-of a nifty idea, actually.
In relation to? It is always 0,0,0 in Yasim.
Best,
Jim
JSBSim could also define the
Presumably it can be traced back via CVS?
Mally
- Original Message -
From: Jon Berndt [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Friday, February 13, 2004 12:34 PM
Subject: RE: [Flightgear-devel] XML SCripting
Holy ... !
JSBSim has been doing
Perhaps someone could try posting the story to Slashdot. It's not a big
one in the grand scheme of things, but they do love MS bashing,
especially when the victim is an open source type.
Josh
Jon Berndt wrote:
Holy ... !
JSBSim has been doing this for some time, now. I can't remember just
Ummm, maybe I should have checked /. before posting that, they ran the
story last night.
Unsend Unsend Unsend!
Josh
Jon Berndt wrote:
Holy ... !
JSBSim has been doing this for some time, now. I can't remember just how
long, We include XML scripts from other scripts. The claim that this is
Jim Wilson wrote:
Yes it is. I'm probably being really dense, but I can't think of a reason why
it would be important to know what the origin is in fdm coordinates. So long
as position is reported to fgfs at the nose, we should be fine.
Assuming that the model also has its origin at the nose.
Curtis L. Olson [EMAIL PROTECTED] wrote:
I think it boils down to how many polygons are we pushing through the
pipeline every frame? How many pixels are we rendering each frame? How
many texture/state changes are we doing each frame? Is the system
thrashing it's texture cache? Are we
Norman Vine [EMAIL PROTECTED] said:
Vivian Meazza writes:
I remain disconcerted that the visual model appears to roll through 180 degs
vertically on the up and down legs of a loop when in chase or helicopter
view. Not the end of the world, but lacking realism.
Yes this is a short
* Martin Spott -- Friday 13 February 2004 15:08:
As we saw recently when trying out the 'hunter' model: The polygon
count appears not to have any noticeable impact on the frame rate with
the Octane (MXI). Some people running PC's and Erik with his O2 claimed
that such a high-polygon model
Josh
Ummm, maybe I should have checked /. before posting that, they ran the
story last night.
Unsend Unsend Unsend!
No problem, except that you didn't quote the actual post you were trying to
unsend (Perhaps someone could try posting the story to Slashdot), which was a
bit confusing.
However
Russell Sutter wrote:
David Megginson wrote:
Andy Ross wrote:
I'm not sure exactly what this is for. I can (and probably
should) export the C.G. position for the view code to use
appropriately. But the VRP stuff seems like a double-correction.
It's basically identical to the view
On Fri, 13 Feb 2004 07:07:05 -0800
Andy Ross [EMAIL PROTECTED] wrote:
Adding the VRP is yet another mechanism, basically a direct analog of
the view offset stuff on the FDM side. I just don't see the need. If
we decide the VRP is the right way to do it, we should chuck the view
offset stuff for
Melchior FRANZ [EMAIL PROTECTED] said:
* Martin Spott -- Friday 13 February 2004 15:08:
As we saw recently when trying out the 'hunter' model: The polygon
count appears not to have any noticeable impact on the frame rate with
the Octane (MXI). Some people running PC's and Erik with his O2
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
Put simply the matrix math used supports a 'restrained' cylindrical viewer
That is a problem, but it isn't the issue here.
There is a singularity in the math model which in effect snaps the orientation
of the model 180* when
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
Norman Vine [EMAIL PROTECTED] said:
Put simply the matrix math used supports a 'restrained' cylindrical viewer
That is a problem, but it isn't the issue here.
There is a singularity in the math model which in effect
Jim Wilson advised:
Norman Vine [EMAIL PROTECTED] said:
Vivian Meazza writes:
I remain disconcerted that the visual model appears to
roll through
180 degs vertically on the up and down legs of a loop
when in chase
or helicopter view. Not the end of the world, but lacking
Richard
You may not be a patent lawyer, but that's a convincing sounding explanation of
the legal position.
Thanks.
Mally
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 10/02/04
Andy Ross wrote:
Russell Sutter wrote:
David Megginson wrote:
Andy Ross wrote:
I'm not sure exactly what this is for. I can (and probably
should) export the C.G. position for the view code to use
appropriately. But the VRP stuff seems like a double-correction.
It's basically
* [EMAIL PROTECTED] (Jon Berndt) [2004.02.13 07:27]:
JSBSim has been doing this for some time, now. I can't remember just how
long, We include XML scripts from other scripts. The claim that this is
patentable is absurd.
Jon
Presumably it can be traced back via CVS?
Mally
This is
Andy Ross wrote:
Jon S. Berndt wrote:
Can the view offset or rendering code (whatever it is that draws the
3D aircraft models) move the origin of the set of vertices that
defines the model per-frame so that the CG aligns with that reported
by the FDM?
Well, yes, because they're just
I updated from cvs last night and noticed that both the j3cub and the
dc3 no longer converge in yasim. I checked several other yasim
aircraft, and their models all converged. (an225, a10, p51d, and
c172). Has anything changed in yasim?
Dave Perry
Russell Suter writes:
I don't think that's what he means. I took him to mean that the visual
model
origin is translated to the CG every frame. If that's what you mean,
you really
don't want to do that. That's a matrix transform for every vertex in
the model.
This is boils down to
On Fri, 13 Feb 2004 11:15:19 -0600
Cameron Moore [EMAIL PROTECTED] wrote:
FWIW, Microsoft filed their patent on Dec. 1, 2000. The CVS entry
you reference was from Apr. 6, 2001. Can you beat the December date?
--
Cameron Moore
Probably.
Jon
___
One other point and then I'll shut the heck up. In the case of military
aircraft with loadouts,
you'll want to consider the visual transition between a missile on the
rail and flyout as an
example. When we first implemented this kind of thing, the missile
looked fine on the rail
but when
Dave Perry wrote:
I updated from cvs last night and noticed that both the j3cub and the
dc3 no longer converge in yasim. I checked several other yasim
aircraft, and their models all converged. (an225, a10, p51d, and
c172). Has anything changed in yasim?
The wing twist bugfix went in,
An interesting article:
http://news.osdir.com/article448.html
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Jon S Berndt [EMAIL PROTECTED] said:
On Fri, 13 Feb 2004 08:22:15 -0800
Andy Ross [EMAIL PROTECTED] wrote:
Jon S. Berndt wrote:
Can the view offset or rendering code (whatever it is that draws the
3D aircraft models) move the origin of the set of vertices that
defines the model
Russell Suter wrote:
Don't get me wrong, I'm not saying this is a bad system, I'm just not
sure I agree it
is an industry standard...
The FAA uses positive numbers towards the tail in specifying longitudinal
weight and balance limits in the TCDS; all weight and balance calculations
I've seen
You may not be a patent lawyer, but that's a convincing sounding explanation
of
the legal position.
PS. I'm just wondering if you have any thoughts on my earlier question, i.e.
whether what's being patented has to be something non-obvious?
Mally
---
Outgoing mail is certified Virus Free.
David Megginson wrote:
I just took a glance at the stations in the service and maintenance
manual for the PA-28-151/161, and the technical drawings have
measurements positive towards the tail in the longitudinal (x) axis
and positive upwards in the vertical (Z) axis. In the lateral (y)
axis,
Jon S Berndt wrote:
On Fri, 13 Feb 2004 10:23:56 -0700
Russell Suter [EMAIL PROTECTED] wrote:
Jon S Berndt wrote:
But then, the FDM still has to report where the FDM is in a common
reference frame.
Exactly! At my company, we call this the control point and we have
standardized on the
Jim Wilson [EMAIL PROTECTED] writes:
Very nice landing. Did you make any attempt to get audio?
i fly with sound disabled, so there was no audio...
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with
On Freitag, 13. Februar 2004 20:53, Russell Suter wrote:
point. Ideally, all FDMs would use the same point.
Ideally this point is configurable.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing
Jon S Berndt wrote:
On Fri, 13 Feb 2004 08:22:15 -0800
Andy Ross [EMAIL PROTECTED] wrote:
Jon S. Berndt wrote:
Can the view offset or rendering code (whatever it is that draws the
3D aircraft models) move the origin of the set of vertices that
defines the model per-frame so that the CG aligns
On Fri, 13 Feb 2004 13:09:30 -0700
Russell Suter [EMAIL PROTECTED] wrote:
So then the pilot's eyepoint is relative to the dynamic CG? I guess
I just assumed JSBSim reported a position from a
fixed point on the aircraft. Ack! Would your VRP then become the
point from which the pilot's
On Fri, 13 Feb 2004 12:53:45 -0700
Russell Suter [EMAIL PROTECTED] wrote:
The VRP is a **solid** point of reference.
Yes, that is most likely different for each aircraft, No? Maybe I've
missed something here but as I understand it, the
VRP is an attempt to define a fixed point of reference in
Russell Suter [EMAIL PROTECTED] said:
Jon S Berndt wrote:
On Fri, 13 Feb 2004 08:22:15 -0800
Andy Ross [EMAIL PROTECTED] wrote:
Jon S. Berndt wrote:
Can the view offset or rendering code (whatever it is that draws the
3D aircraft models) move the origin of the set of vertices
On Fri, 13 Feb 2004 20:30:35 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon, I forget, what exactly is the reason for defining a VRP in the
config file? I thought that JSBSim already knew where the nose was.
We normally track:
- Initial empty weight CG
- Dynamic CG (includes fuel burnoff)
-
On Fri, 13 Feb 2004 20:30:35 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon, I forget, what exactly is the reason for defining a VRP in the
config file? I thought that JSBSim already knew where the nose was.
Also, Jim: will the view code be able to place a 3D model correctly no
matter what the
Jon S Berndt [EMAIL PROTECTED] said:
On Fri, 13 Feb 2004 20:30:35 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon, I forget, what exactly is the reason for defining a VRP in the
config file? I thought that JSBSim already knew where the nose was.
Also, Jim: will the view code be able to
Jon S Berndt [EMAIL PROTECTED] said:
On Fri, 13 Feb 2004 20:30:35 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon, I forget, what exactly is the reason for defining a VRP in the
config file? I thought that JSBSim already knew where the nose was.
We normally track:
- Initial empty
Jon, I forget, what exactly is the reason for defining a VRP in the config
file? I thought that JSBSim already knew where the nose was.
In JSBSim the locations of things along the longitudinal (X) axis are defined
in the configuration file based on an arbitrary point on this axis. The
point
David Culp [EMAIL PROTECTED] said:
Jon, I forget, what exactly is the reason for defining a VRP in the config
file? I thought that JSBSim already knew where the nose was.
In JSBSim the locations of things along the longitudinal (X) axis are defined
in the configuration file based on an
Jon S Berndt wrote:
On Fri, 13 Feb 2004 20:30:35 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon, I forget, what exactly is the reason for defining a VRP in the
config file? I thought that JSBSim already knew where the nose was.
We normally track:
- Initial empty weight CG
- Dynamic CG
On Fri, 13 Feb 2004 21:25:42 -
Jim Wilson [EMAIL PROTECTED] wrote:
Jon S Berndt [EMAIL PROTECTED] said:
We normally track:
- Initial empty weight CG
- Dynamic CG (includes fuel burnoff)
- landing gear ground contact points
- scrape points
- pilot eyepoint (for calculating pilot accels for
On Fri, 13 Feb 2004 14:33:43 -0700
Russell Suter [EMAIL PROTECTED] wrote:
Although I strongly agree that JSBSim reporting a fixed point
relative to the aircraft is good, I'm not
particularly thrilled with the point you have chosen. I am more than
happy to agree to disagree on that one though.
Any chance of modeling wingtip vortices (when CL is high enough above
some threshhold) and rocket engine exhaust?
:-)
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Actually, I'm pretty sure that with nasal and the animations we have we
can do exhaust cones right now. Just model a cone, assign it a
translucent, emmisive materiel and then use nasal to turn it on and
off. You can even make it get bigger and smaller with the animations.
Don't know how to
Josh Babcock wrote
Actually, I'm pretty sure that with nasal and the animations
we have we
can do exhaust cones right now. Just model a cone, assign it a
translucent, emmisive materiel and then use nasal to turn it on and
off. You can even make it get bigger and smaller with the
This would be nice:
http://www.dfrc.nasa.gov/Gallery/Photo/X-15/Small/EC68-1889.jpg
:-)
Jon
Josh Babcock [EMAIL PROTECTED] wrote:
Actually, I'm pretty sure that with nasal and the animations we have
we can do exhaust cones right now. Just model a cone, assign it a
translucent, emmisive
On Fri, 13 Feb 2004 15:49:09 -0600,
Jon S Berndt [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
On Fri, 13 Feb 2004 14:33:43 -0700
Russell Suter [EMAIL PROTECTED] wrote:
Although I strongly agree that JSBSim reporting a fixed point
relative to the aircraft is good, I'm not
Jon S Berndt wrote:
On Fri, 13 Feb 2004 14:33:43 -0700
Russell Suter [EMAIL PROTECTED] wrote:
Although I strongly agree that JSBSim reporting a fixed point
relative to the aircraft is good, I'm not
particularly thrilled with the point you have chosen. I am more than
happy to agree to
On Fri, 13 Feb 2004 16:52:12 -0700
Russell Suter [EMAIL PROTECTED] wrote:
Well, Jon, I think you already know the answer to that question. The
You probably answered that several times, but I didn't catch it in
your email.
way you phrase it though implies that I somehow
believe that the
Jon S Berndt wrote:
Given each JSBSim aircraft config file, we will need to add the
AC_VRP ###
entry to each aircraft file.
No, let's not do that -- instead, let FlightGear pass the VRP through the
JSBSim API. That way, we can use different 3D models with the same flight
model.
All the
David Megginson [EMAIL PROTECTED] said:
Jon S Berndt wrote:
Given each JSBSim aircraft config file, we will need to add the
AC_VRP ###
entry to each aircraft file.
No, let's not do that -- instead, let FlightGear pass the VRP through the
JSBSim API. That way, we can use
If I understand correctly, all the AC_VRP does is ensure that the
lon/lat/alt
is reported at the nose. You can position _any_ 3D model in
relation to that
location however you like with the model offsets.
Jim
Yes. For JSBSim only we will know where our published VRP is at any time.
This
Jon S Berndt wrote:
Given each JSBSim aircraft config file, we will need to add the
AC_VRP ###
entry to each aircraft file.
No, let's not do that -- instead, let FlightGear pass the VRP through the
JSBSim API. That way, we can use different 3D models with the
same flight model.
Uncle!
Jon S Berndt wrote:
I don't see any advantage to your approach.
By your responses, you give me no indication that you even understand
what I'm saying.
I seem to be alone in my dissent anyway... What you are planning will
work just fine.
--
Russ
Conway's Law: The structure of a system
Jon Berndt wrote:
No, let's not do that -- instead, let FlightGear pass the VRP through the
JSBSim API. That way, we can use different 3D models with the
same flight model.
That _absolutely_ defeats the whole purpose.
I don't see that. What is the benefit of a configurable VRP at all, if the
Uncle!
Jon S Berndt wrote:
I don't see any advantage to your approach.
By your responses, you give me no indication that you even understand
what I'm saying.
Playing dumb has never been so effective.
;-)
It's been a very arduous set of discussions over time, so I'm game to take
the
I don't see that. What is the benefit of a configurable VRP at
all, if the 3D modeller cannot set it in the XML config file for
the model?
Aaargh!
It's the FDM's item to configure. See below.
In that case, you might as well just report the 0,0,0
point, as Jim suggests.
This would
David Megginson [EMAIL PROTECTED] said:
Jon Berndt wrote:
No, let's not do that -- instead, let FlightGear pass the VRP through the
JSBSim API. That way, we can use different 3D models with the
same flight model.
That _absolutely_ defeats the whole purpose.
I don't see that. What
Jon Berndt wrote:
so I'm game to take
the Nike approach and Just Do It.
That's probably wise.
I did _think_ I understood what you were
saying, though, and still wish I understood your approach.
I think it better that I scrape up some time somehow and implement
the meta file approach.
Russell Suter writes:
Jon S Berndt wrote:
I don't see any advantage to your approach.
By your responses, you give me no indication that you even understand
what I'm saying.
I seem to be alone in my dissent anyway... What you are planning will
work just fine.
Russell
You are not
70 matches
Mail list logo
