Re: [Flightgear-devel] Terrain LOD clumping
I haven't looked at this since I submitted the original message, but will probably work on it again soon. One note: I believe (but haven't verified) that because of where the range selector is being placed in the scene graph, all the children from the same tile are using the same range. That is, the range selector is being placed between the tile geometry point and the triangles, fans, etc. This causes the whole tile to pop into/out of range at the same time and possibly cause the range to be calculated based on a tile corner. I should probably look at offsetting the triangle geometery first, but, like I say, I haven't worked on this. Phil Cazzola - Original Message - From: Gerard Robin [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@flightgear.org Sent: Sunday, July 31, 2005 3:56 AM Subject: Re: [Flightgear-devel] Terrain LOD clumping Le dimanche 31 juillet 2005 à 10:39 +0200, Erik Hofman a écrit : I had this message still in my TODO box and looking a bit closer it looks to me like MIPMAPPING should take care of this, doesn't it? Does anybody think this might be useful to include? Erik That would be useful, if with it, we could reduce the cpu usage. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] JSBSim/FGTable.cpp exception
I was getting a access exception in FGTable.cpp line at line 267. I belive I have tracked it down to values not being initialized in the constructor for the 3D tables. Fix: Index: FGTable.cpp===RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/FGTable.cpp,vretrieving revision 1.6diff -r1.6 FGTable.cpp69a70 lastRowIndex=lastColumnIndex=2; I will cross post this with the FG devel and JSBSim devel lists. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D view goes away by itself
Hmmm. I have something similar that works, but I don't see the important
difference. I copied/modifed stepView() to be a stepCockpitView().
It does an explicit
setprop(/sim/current-view/view-number, 0);
which I believe forces a copyToCurrent() and an update(),
but I'm not sure if that is the reason it works.
The internal flag is set for each defined view in the constructor and the
view manager
copies the flag from the currently used view in copyToCurrent(). Is there
any chance the
node.getChild(view-number).getValue() == 0 is lying, .e.g.
returning a zero when it cannot find a value?
For reference, here is what I use and it seems to work:
In view.nas
##
# Handler. Step to the next in cockpit view.
#
# This assumes the cockpit is view 0
stepCockpitView = func {
# switch to cockpit view
setprop(/sim/current-view/view-number, 0);
# determine the current cockpit view number
curr = getprop(/sim/view/cockpit-view-number);
cviews = props.globals.getNode(/sim/view).getChildren(cockpit-view);
curr = curr + arg[0];
if (curr 0){ curr = size(cviews) - 1; }
elsif(curr = size(cviews)) { curr = 0; }
setprop(/sim/current-view/goal-heading-offset-deg,
cviews[curr].getNode(heading).getValue());
setprop(/sim/view/cockpit-view-number, curr);
# And pop up a nice reminder
gui.popupTip( cviews[curr].getNode(name).getValue());
}
In preferences.xml
view
nameInteranl View/name
typelookfrom/type
internal type=booltrue/internal
config
from-model type=booltrue/from-model
from-model-idx type=int0/from-model-idx
ground-level-nearplane-m type=double0.5f/ground-level-nearplane-m
default-field-of-view-deg
type=double55.0/default-field-of-view-deg
default-pitch-deg type=double0/default-pitch-deg
default-heading-deg type=double0/default-heading-deg
front-direction-deg type=double0/front-direction-deg
front-left-direction-deg type=double45/front-left-direction-deg
left-direction-deg type=double90/left-direction-deg
back-left-direction-deg type=double135/back-left-direction-deg
back-direction-deg type=double180/back-direction-deg
back-right-direction-deg type=double225/back-right-direction-deg
right-direction-deg type=double270/right-direction-deg
front-right-direction-deg
type=double315/front-right-direction-deg
x-offset-m type=double0/x-offset-m
y-offset-m type=double0.8/y-offset-m
z-offset-m type=double2.0/z-offset-m
/config
cockpit-view-number type=int0/cockpit-view-number
cockpit-number-views type=int4/cockpit-number-views
cockpit-view
nameFront/name
heading type=double0/heading
/cockpit-view
cockpit-view
nameFront Right/name
heading type=double315/heading
/cockpit-view
cockpit-view
nameRear/name
heading type=double180/heading
/cockpit-view
cockpit-view
nameFront Left/name
heading type=double45/heading
/cockpit-view
/view
In keyboard.xml
key n=86
nameV/name
descScroll through cockpit views./desc
binding
commandnasal/command
scriptview.stepCockpitView(1)/script
/binding
/key
- Original Message -
From: Dave Culp [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, May 26, 2005 4:19 PM
Subject: [Flightgear-devel] 3D view goes away by itself
[ snip ]
It works fine on the ground, but about 10 seconds after takeoff the 3D
side
views of the aircraft's engine/wing go away and never come back. I check
through the property browser and all the values look unchanged. It seems
like the internal boolean value must have changed, but the property
browser
does not indicate a change (even after a refresh of course).
Any idea what causes the view to change by itself after takeoff?
Thanks,
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in theHimalayas
- Original Message -
From: Paul Furber [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Tuesday, May 03, 2005 7:00 AM
Subject: Re: [Flightgear-devel] Re: Speed of CVS version and flying in
theHimalayas
On Tue, 2005-05-03 at 14:17 +0200, Melchior FRANZ wrote:
That's an old, well known bug. If you position fgfs exactly on the tile
boundaries
(*integer* lon/lat), the intersection code somehow falls through between
the
tiles. Try this:
$ ./fgfs --lat=87.001 --long=28.001 --altitude=3
Thanks - this worked a treat. I'm now flying at 32000 feet over the
breathtaking, er, sea. Oops - looks like I picked the wrong tile set :)
I wasn't sure if you figured this out:
Lat=87 and Long=28 would be a polar location, somewhere north of Murmansk.
Lat =28 and Long=87 is on the China/Nepal border
--
Paul Furber [EMAIL PROTECTED]
ex tenebris lux, ex fenestris tux
--
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SGBucket::sgBucketDiff fix
This is a minor bug fix for sgBucketDiff().
If you crossed the bucket size boundary, the answer for dx could be wrong.
E.g.
going from 0:0, 21:7 to 0:7, 21:7 would give you dx = 7 (correct)
but going from 0:0, 21:7 to 0:3, 22:0 would give you dx = 6 (instead of 7)
Previously it differenced the center longitudes of the buckets. When you
cross a boundary, the center point of the larger bucket now lies on the
edge of the smaller
bucket.
The result was a dx with an integer + 1/2 bucket, which rint() was
rounding to the nearest even int.
This function only seems to be used in TerraGear. Source, test cases and
results attached.
Can someone with the keys review this and check it in?
Thanks,
Phil Cazzola
$ cvs diff newbucket.cxx
Index: newbucket.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/bucket/newbucket.cxx,v
retrieving revision 1.3
diff -r1.3 newbucket.cxx
274,278c274,282
double c1_lon = b1.get_center_lon();
double c2_lon = b2.get_center_lon();
double diff_lon = c2_lon - c1_lon;
double span;
if ( sg_bucket_span(c1_lat) = sg_bucket_span(c2_lat) ) {
---
double diff_lon=0.0;
double span=0.0;
SGBucket tmp_bucket;
// To handle crossing the bucket size boundary
// we need to account for different size buckets.
if ( sg_bucket_span(c1_lat) = sg_bucket_span(c2_lat) )
{
283a288,299
diff_lon = b2.get_center_lon() - b1.get_center_lon();
if (diff_lon 0.0)
{
diff_lon -= b1.get_width()*0.5 + b2.get_width()*0.5 - span;
}
else
{
diff_lon += b1.get_width()*0.5 + b2.get_width()*0.5 - span;
}
Test 1 x passed
Test 1 y passed
Test 2 x passed
Test 2 y passed
Test 3 x passed
Test 3 y passed
Test 4 x passed
Test 4 y passed
Test 5 x passed
Test 5 y passed
Test 6 x passed
Test 6 y passed
Test 7 x passed
Test 7 y passed
Test 8 x passed
Test 8 y passed
Test 9 x passed
Test 9 y passed
Test 10 x passed
Test 10 y passed
Test 11 x passed
Test 11 y passed
Test 12 x passed
Test 12 y passed
Test 13 x passed
Test 13 y passed
Test 14 x passed
Test 14 y passed
Test 15 x passed
Test 15 y passed
Test 16 x passed
Test 16 y passed
Tests completed
Total errors = 0
Test 1 x passed
Test 1 y passed
Test 2 x passed
Test 2 y passed
Test 3 x passed
Test 3 y passed
Test 4 x passed
Test 4 y passed
Test 5 x passed
Test 5 y passed
Test 6 x failed!
Expected: 7, acutal:6
Test 6 y passed
Test 7 x failed!
Expected: 7, acutal:6
Test 7 y passed
Test 8 x passed
Test 8 y passed
Test 9 x passed
Test 9 y passed
Test 10 x failed!
Expected: 7, acutal:6
Test 10 y passed
Test 11 x failed!
Expected: 7, acutal:6
Test 11 y passed
Test 12 x failed!
Expected: 7, acutal:6
Test 12 y passed
Test 13 x failed!
Expected: 164, acutal:162
Test 13 y passed
Test 14 x failed!
Expected: -164, acutal:-162
Test 14 y passed
Test 15 x failed!
Expected: -164, acutal:-162
Test 15 y passed
Test 16 x failed!
Expected: -164, acutal:-162
Test 16 y passed
Tests completed
Total errors = 9
testbucket.cxx
Description: Binary data
newbucket.cxx
Description: Binary data
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
