Re: [Flightgear-devel] Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 08:50, Melchior FRANZ wrote: The FDMs are currently the only users of the groundcache, and yes, they benefit from it. A lot. Per-wheel/contact-point ground awareness hadn't been done before Mathias implemented the ground cache. And probably it would have been a big performance problem to constantly do intersection test with the whole tile. Still, I didn't mean to blame the problems on the FDMs. I just called it FDM stuttering because this is what the user sees (and because the ground-cache code is in the FDM/ directory :-) But the FDM only stuttered, because it wasn't called in time, because of unfortunate groundcache/beacon interaction. And that wasn't really a bug, either. Neither in the beacon, nor in the ground cache. Just a detail that had to be tuned for better performance. :-) That approach to have croase objects for intersection tests and detaild ones for views is really a ood one. May be one can have models for a very low level of detail for that case. Anyway, I am thinking and started playing with that ground cache being structured in an octree. That will make the lookup time about log(n) instead of n if n is the number of triangles in the cache. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Montag 30 Mai 2005 14:21, Jon Stockill wrote: I'm not certain the area that the ground cache covers, but I suspect it has applications beyond just contact points. ISTR Lee was wanting to know ground elevation a distance ahead of the aircraft for the terrain following mode of the TSR2s autopilot - could this be used? Hmm, not really. The problem that cache solves is the lookup time when doing queries for altitude computations or in the future intersection tests with whatever (May be crashes with power lines?). If you do that test once for each timeframe and only at one place per aircraft, you can well, and you even have to, traverse the whole scenegraph to get that information. The time to traverse the whole scenegraph is too high if you want to know that information for many points and for different informations like the locations for the wires on the carrier. So the trick is to build a as small as possible subset of the scenegraph and do queries there. The smaller the cache is, the better are the response times. So for that reason, I don't think that this is usable for this task at the moment. What you will need for that will be more something similar like the groundcache covering a much bigger area. But instead of putting every surface into that cache, one could preselect the objects depending on the distance and its size, that is ignore too small ones. And additionally, one should simplyfy the surfaces to some bigger ones if they are far away. A structure like that might recycle and/or share some code with the groundcache. And such a structure can probably be well used for an improoved implementation of radar contacts. That problem is a typical LOD algorithm, I expect to find magnitudes of publications about such and fast algorithms. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
Hi,
On Dienstag 31 Mai 2005 08:05, Mathias Fröhlich wrote:
Since I have to visit a customer today, I expect to find time tomorrow.
Sorry for that ...
Just before any customer ...
Found a thinko. It worked for my testcases by accident.
Attached ia a small patch not thought for application to CVS right now. It
contains to the fix of that thinko some output which is triggered if the
point in triangle test is less tolerant instead of more tolerant ...
For all having problems here. Please test and tell me if you stil experience
1. this bug or
2. see this '' message on the screen while flying
around.
Have to leave now ...
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: src/FDM/groundcache.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/groundcache.cxx,v
retrieving revision 1.7
diff -u -r1.7 groundcache.cxx
--- src/FDM/groundcache.cxx 30 May 2005 08:48:27 - 1.7
+++ src/FDM/groundcache.cxx 31 May 2005 06:55:41 -
@@ -131,7 +131,8 @@
SGDfloat tmp = (y2 - y3);
SGDfloat tmpn = (x2 - x3);
int side1 = SG_SIGN (tmp * (rx - x3) + (y3 - ry) * tmpn);
-int side2 = SG_SIGN (tmp * (x1 - x3) + (y3 - side1*eps - y1) * tmpn);
+int side2 = SG_SIGN (tmp * (x1 - x3) + (y3 - y1) * tmpn
+ + side1 * eps * fabs(tmpn));
if ( side1 != side2 ) {
// printf(failed side 1 check\n);
return false;
@@ -141,7 +142,8 @@
tmp = (y3 - ry);
tmpn = (x3 - rx);
side1 = SG_SIGN (tmp * (x2 - rx) + (ry - y2) * tmpn);
-side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - y1) * tmpn
+ + side1 * eps * fabs(tmpn));
if ( side1 != side2 ) {
// printf(failed side 2 check\n);
return false;
@@ -151,7 +153,8 @@
tmp = (y2 - ry);
tmpn = (x2 - rx);
side1 = SG_SIGN (tmp * (x3 - rx) + (ry - y3) * tmpn);
-side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - y1) * tmpn
+ + side1 * eps * fabs(tmpn));
if ( side1 != side2 ) {
// printf(failed side 3 check\n);
return false;
@@ -350,6 +353,8 @@
double this_radius = sgdLengthVec3(isectpoint);
if (ground_radius this_radius)
ground_radius = this_radius;
+ } else if (sgdPointInTriangle( isectpoint, t.vertices )) {
+SG_LOG(SG_FLIGHT,SG_ALERT, );
}
}
}
@@ -620,6 +625,9 @@
sgdVec3 isecpoint;
if ( sgdIsectInfLinePlane( isecpoint, pt, dir, triangle.plane )
sgdPointInTriangle( isecpoint, triangle.vertices ) ) {
+ if (!fgdPointInTriangle( isecpoint, triangle.vertices )) {
+SG_LOG(SG_FLIGHT,SG_ALERT, );
+ }
// Check for the closest intersection point.
// FIXME: is this the right one?
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
Mathias Fröhlich wrote: =46ound a thinko. It worked for my testcases by accident. Attached ia a small patch not thought for application to CVS right now. Fuer mich tut's der - jedenfalls kann ich jetzt lustig zwischen EKOD, EKSB, EDXF und EDHK mit dem Autopiloten in der A-10 im Viereck fliegen, ohne, dass die Kiste stehenbleibt. Tschuess, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with todays CVS
Martin Spott wrote: Fuer mich tut's der - [...] Sorry, this was intended to be a private EMail. I was just reporting success on my test-course, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with Terrasynch
On Tuesday 31 May 2005 00:44, Curtis L. Olson wrote: Lee Elliott wrote: Can anyone confirm that terrasynch is currently working? Hmmm, the master scenery server looks like it may have gone down ... I can't ping it or log into it right now. It's going to have to wait until tomorrow am before I'll be near the machine to look at it though. Curt. Hello Curt, thanks for checking. I think I've got everything right at my end but I'll not know for sure until it works:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [ANN] Blender 2.37 released ac3d_export.py HOWTO
Blender 2.37 has just been released:
http://www.blender3d.org/
New features fixes:
http://www.blender3d.org/cms/Blender_2_37.496.0.html
Most relevant changes for fgfs work:
- manipulators (widgets in the 3D space for scaling, rotation, translation)
- new ac3d importer/exporter
AC3D-EXPORT
===
- it's much faster now (but you'll only see that on big scenes)
- one doesn't have to select from a popup everytime one exports to an
AC3D file ...
- but only *selected* objects are saved now, which is quite a pain.
It means that you have first to make all layers active, then press
AKEY,AKEY, then save, and then restore your original setup (i.e.
deselect all layers/objects that you don't want active for further
work). Will probably get fixed in 2.38.
+++
Attached is a patch that adds the possibility to export (1) all,
(2) only selected objects, or to (3) ask every time (like in older versions).
+++
- you can now choose which objects *not* to export, by simply prepending
# (as in commented out) or ! (as in not) to the object name.
That's very useful for helper objects that shouldn't end up in the
exported model. (And a good argument for selecting all (see last point).
- exports objects with more than one material assigned. This isn't
supported by the AC3D spec, but the exporter auto-splits these objects
into one object per material. This can be prevented by prepending
= (keep as-is) or $ (expensive, don't touch) to the object name.
- does automatically turn parented objects into AC3D's OBJECT_GROUP,
(whereas it exported them flattened before)
- exports crease in AC3D 4 mode
- allows to select a texture base dir (that is best kept empty, because
it's prepended to all texture paths), and an export path
- changes to the exporter properties are now saved in
~/.blender/scripts/bpydata/config/. To make changes you open a
Scripts Window and select Scripts-System-Scripts Config Editor-
Export-AC3D.
- there you can also instruct Blender not to ask before overwriting
(see the General section)
m.
Index: ac3d_export.py
===
RCS file: /cvsroot/bf-blender/blender/release/scripts/ac3d_export.py,v
retrieving revision 1.10
diff -u -p -r1.10 ac3d_export.py
--- ac3d_export.py 16 Apr 2005 05:25:41 - 1.10
+++ ac3d_export.py 31 May 2005 12:48:01 -
@@ -110,6 +110,7 @@ MATIDX_ERROR = False
REG_KEY = 'ac3d_export'
# config options:
+WHICH_OBJECTS = 'all'
SKIP_DATA = False
MIRCOL_AS_AMB = False
MIRCOL_AS_EMIS = False
@@ -121,6 +122,7 @@ NO_SPLIT = False
EXPORT_DIR = ''
tooltips = {
+ 'WHICH_OBJECTS': which objects should get exported (\all\, \selected\, \ask\),
'SKIP_DATA': don't export mesh names as data fields,
'MIRCOL_AS_AMB': export mirror color as ambient color,
'MIRCOL_AS_EMIS': export mirror color as emissive color,
@@ -134,6 +136,7 @@ tooltips = {
def update_RegistryInfo():
d = {}
+ d['WHICH_OBJECTS'] = WHICH_OBJECTS
d['SKIP_DATA'] = SKIP_DATA
d['MIRCOL_AS_AMB'] = MIRCOL_AS_AMB
d['MIRCOL_AS_EMIS'] = MIRCOL_AS_EMIS
@@ -152,6 +155,7 @@ rd = Blender.Registry.GetKey(REG_KEY, Tr
if rd:
try:
AC3D_4 = rd['AC3D_4']
+ WHICH_OBJECTS = rd['WHICH_OBJECTS']
SKIP_DATA = rd['SKIP_DATA']
MIRCOL_AS_AMB = rd['MIRCOL_AS_AMB']
MIRCOL_AS_EMIS = rd['MIRCOL_AS_EMIS']
@@ -673,7 +677,15 @@ def fs_callback(filename):
# -- End of definitions
-OBJS = Blender.Object.GetSelected()
+if WHICH_OBJECTS == 'ask':
+ which = ['all', 'selected'][Blender.Draw.PupMenu('Export objects%t|all%x0|selected%x1')]
+else:
+ which = WHICH_OBJECTS
+
+if which == 'all':
+ OBJS = Blender.Object.Get()
+else:
+ OBJS = Blender.Object.GetSelected()
if not OBJS:
Blender.Draw.PupMenu('ERROR: No objects selected')
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] batteries, alternators, volts, amps - electrical system
I need to do some work beefing up our electrical system model a bit. I'd like to add a simple model for a battery where output varies with time and a simple alternator model where output varies with rpm. I'm a complete moron when it comes to electrical stuff so I'm not even sure I'm asking a sensable question. Does anyone know of a good online reference(s) or even just send me some reasonable info. In the end I'd like to be able to be able to output bus voltage (downstream of the battery + alternator) and also model an ammeter. I already have a way to back propogate the total current draw on the system, where the individual electrical system outputs can be marked with some current draw when they are on, however, I need to work on the input side of the equation. Again, I want to start pretty simple and not get drug down with too fancy of an implimentation. Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] batteries, alternators, volts, amps - electrical system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis L. Olson schrieb: I need to do some work beefing up our electrical system model a bit. I'd like to add a simple model for a battery where output varies with time and a simple alternator model where output varies with rpm. I'm a complete moron when it comes to electrical stuff so I'm not even sure I'm asking a sensable question. Does anyone know of a good online reference(s) or even just send me some reasonable info. In the end I'd like to be able to be able to output bus voltage (downstream of the battery + alternator) and also model an ammeter. I already have a way to back propogate the total current draw on the system, where the individual electrical system outputs can be marked with some current draw when they are on, however, I need to work on the input side of the equation. Again, I want to start pretty simple and not get drug down with too fancy of an implimentation. All you need is Kirchhoff's law (e.g.: http://en.wikipedia.org/wiki/Kirchhoff%27s_circuit_laws) If you can live with a stationary current (i.e. no dynamic effects) it boils down to solving simple linear equations (Ax = b). If you need dynamic behaviour (what I doubt) you'll get partial equations... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFCnOqklhWtxOxWNFcRAv7fAJ9sHLh30zOaY151Vypo/wqBRqXCkgCfbCh2 +Faa6DFVVvP71jrablW2Syc= =3wiv -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Cannot put character with ascii code 0 into the property tree
I have been experimenting with Nasal lately. The focus of my experiment is to have one Nasal script communicate with another using the property tree. In an attempt of communication, a Nasal script of mine placed the following stream of characters to the property tree: 1, 80, 194, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 127, 0, 0, 6, 207, 128, 174, 239, 0, 0, 127, 0, 0, 6, 207, 128, 174, 239, 0, 0, 0, 0, 0, 20, 0, 2, 0, 15, 0, 0, 0, 0 Unfortunately, the property tree cuts off everything after the first character \0. My questions are: Why doesn't the property tree except the \0 character? Is there any chance that it can accept the \0 character? Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cannot put character with ascii code 0 into the property tree
Ampere K. Hardraade wrote: Why doesn't the property tree except the \0 character? Is there any chance that it can accept the \0 character? The zero is the ASCII NUL character, which has been used as the end of string marker since the beginning of time (which we all know was at midnight GMT on December 31st 1969). This convention is so prevalent that every language encoding known to man avoids the use of this byte for compatibility with C code that expects to read it as the end of the string. Property names should be ASCII strings, by convention at least if not by force. ASCII strings don't contain nuls. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
