Re: [Flightgear-devel] Failures and Instrumentation
David Megginson wrote: /instrumentation/altimeter/ /instrumentation/airspeed-indicator/ /instrumentation/vor-gauge/ /instrumentation/transponder/ etc., with indexes as appropriate. Inside each branch, we have a collection of properties, some common to many (or all) instruments, Yes, good. In particular, I have been wanting to modularise the instrument steam code to handle multiple copies of each instrument. e.g. It is common for an aircraft to have two altimeters which are (often) identical apart from having their pressure-datum knobs set to different values. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] How to draw lines?
I need some help. I wan to draw lines in instruments layer. I made a new subclass of FGInstrumentLayer and in draw method I do glDisable ( GL_TEXTURE_2D ); glBegin(GL_LINES); glVertex2f(-100,0); glVertex2f(100,0); glEnd(); but it doesn't draw anything. But when I draw something with GL_POLYGON it draw fine. What I should to change, please? Thanks, MaDr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/martin ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] x++ The World's First XML-Based ProgrammingLanguage
Jonathan Polley wrote: Jon Berndt wrote: Just because something *can* be done doesn't mean it *should* be! Actually, I was going to say that it was another solution in search of a problem. I honestly thought it was a joke, but the website looks serious enough to believe. Good grief. But it's not the first -- XSLT is a full XML-based programming language, thankfully tailored to a much smaller problem area. And XSLT is still a horrific monster, IMHO. I still remain dumbfounded at the number of otherwise bright people in this world that believe that needlessly gluing together two useful technologies results in improvement. What happened to encapsulation? It's not just for programs anymore. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] x++ The World's First XML-Based ProgrammingLanguage
Andy Ross writes: Jonathan Polley wrote: Jon Berndt wrote: Just because something *can* be done doesn't mean it *should* be! Actually, I was going to say that it was another solution in search of a problem. I honestly thought it was a joke, but the website looks serious enough to believe. Good grief. But it's not the first -- XSLT is a full XML-based programming language, thankfully tailored to a much smaller problem area. And XSLT is still a horrific monster, IMHO. I still remain dumbfounded at the number of otherwise bright people in this world that believe that needlessly gluing together two useful technologies results in improvement. What happened to encapsulation? It's not just for programs anymore. :) The only thing I can possibly see is that they want to have some sort of gui point and click graphical visual programming thingy and then they can dump out the actual result as xml, but the developer would rarely if ever actually look at the xml Of course, that's just me trying to make sense of it. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to draw lines?
Martin Dressler wrote: I wan to draw lines in instruments layer. I made a new subclass of FGInstrumentLayer and in draw method I do glDisable ( GL_TEXTURE_2D ); glBegin(GL_LINES); glVertex2f(-100,0); glVertex2f(100,0); glEnd(); but it doesn't draw anything. But when I draw something with GL_POLYGON it draw fine. What I should to change, please? Is this on the 3D panel or 2D? In 3D, the texture layers are drawn with GL_POLYGON_OFFSET, which by default does not apply to lines. For reasons having to do with a metaphor collision (lines are thick in screenspace, while polygons aren't) lines don't work well with glPolygonOffset() -- you have to play with the factor argument. Try using glVertex3f() and specifying a Z coordinate of about 0.01 or so; that might work. But are you actually sure you want to be drawing lines? Lines are not the natural medium for 3D hardware -- they don't antialias well (if at all), don't have an easy way to associate their size with the world around them, and don't behave nicely under changes of perspective. Almost always, you'll get better results by using a 1D texture to draw your lines. Picture a 4x1 GL_LUMINANCE_ALPHA texture that looks like this: 0 0 0 255 255 0 0 0 Set your line color with glColor, and draw the line in world-space coordinates as a thicker (4x as wide as the intended line) quad modulated by the texture. Now, the line will be nicely antialiased, will look correct when viewed at funny angles, and will be less likely to excercise slow paths and funny behavior in the OpenGL driver. You'll send about twice as many vertices to the driver, but that's not likely to be significant when compared with the terrain complexity. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] x++ The World's First XML-Based ProgrammingLanguage
Andy Ross writes: I honestly thought it was a joke, but the website looks serious enough to believe. Good grief. People have been proposing this kind of thing right from the start. But it's not the first -- XSLT is a full XML-based programming language, thankfully tailored to a much smaller problem area. And XSLT is still a horrific monster, IMHO. Yes, but at least XSLT is mostly declarative, so it's in XML's problem area. Basically my rule is that markup languages are nouns and adjectives, while programming languages are verbs and adverbs. You use a markup language to describe information and programming languages to act on it. Note, however, that the excess has often gone the other way. Far too many programmers use code to define large amounts of data (consider especially the early AI work in LISP). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How to draw lines?
Andy Ross writes: Is this on the 3D panel or 2D? In 3D, the texture layers are drawn with GL_POLYGON_OFFSET, which by default does not apply to lines. For reasons having to do with a metaphor collision (lines are thick in screenspace, while polygons aren't) lines don't work well with glPolygonOffset() Actually, as I understand it, glPOLYGONoffset by definition only works with polygon, and not at all with points or lines (even though we might like them to work the same way, they don't.) -- you have to play with the factor argument. Try using glVertex3f() and specifying a Z coordinate of about 0.01 or so; that might work. Yup, you'd have to physically reposition the lines and points. But are you actually sure you want to be drawing lines? Are you working on some sort of glass cockpit thingie? Lines are not the natural medium for 3D hardware -- they don't antialias well (if at all), don't have an easy way to associate their size with the world around them, and don't behave nicely under changes of perspective. Almost always, you'll get better results by using a 1D texture to draw your lines. Picture a 4x1 GL_LUMINANCE_ALPHA texture that looks like this: 0 0 0 255 255 0 0 0 Set your line color with glColor, and draw the line in world-space coordinates as a thicker (4x as wide as the intended line) quad modulated by the texture. Now, the line will be nicely antialiased, will look correct when viewed at funny angles, and will be less likely to excercise slow paths and funny behavior in the OpenGL driver. You'll send about twice as many vertices to the driver, but that's not likely to be significant when compared with the terrain complexity. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
Norman Vine [EMAIL PROTECTED] said: Andy Ross writes: Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Right --- So why not leave the camera at 0,0,0 and add an additional offset to the 'tile-offset' When I first saw this suggestion what came to mind was using camera at 0,0,0. Applying the offset (difference between our current view position and the scenery center) to the scenery. And applying the difference between our view position and the model origin (aircraft position) to the model. But I guess I'm a little confused on how this would be done. Would we apply the same rotation matrix with an adjusted translation vector? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] see-through instrument panel
just took a look at the outside view with the cessna and i noticed you can see the instrument panel through the fuselage. this is on linux with a geforce card. picture at: http://caliban.lbl.gov/fgfs_panel.ppm also, the engine is at 0 rpm but the propeller is spinning in the animation. all this is with the latest cvs for everything. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Andy Ross writes: Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Right --- So why not leave the camera at 0,0,0 and add an additional offset to the 'tile-offset' When I first saw this suggestion what came to mind was using camera at 0,0,0. Applying the offset (difference between our current view position and the scenery center) to the scenery. And applying the difference between our view position and the model origin (aircraft position) to the model. But I guess I'm a little confused on how this would be done. Would we apply the same rotation matrix with an adjusted translation vector? Yes, but this is the easy part :-) Not really sure yet how to get the Terrain Intersection routines working with an 'offset' from the tile_center, and the since the scenery tiling is NECESSARY due to 'precision issues', we can'y adbandon it. I know it should just be another translation but I can't seem to get it working right thinking publically Since the scenery tiles are in are in a tile-relative coordinate space we should just have to add vdiff = ( scenery_center - abs_view_pos ) to the scenery_center in the ssg_prep_tile() call and subtract vdiff from the scenery_center in the scenery intersection routines / Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] GS needle sensitivity.
I had someone recently comment that they thought the glide slope needle was too sensitive in FG. Can anyone comment on this? What sort of needle range relative to how many degrees off the target glide slope should we be seeing? This person suggested 2 'dots' per degree off the glide slope (but they aren't a pilot and haven't flown any real instrument approaches.) I thought I had investigated this and had done it correctly when I first wrote the code, but it would be nice to verify that we are still doing this right since the question has come up (and given that the 2d panel instrument can also scale the values, there is more than one place an error could creep in.) Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: see-through instrument panel
Andy Ross [EMAIL PROTECTED] writes: What size depth buffer are you using? The default is to use the same depth as the color bits, so if you're in 16 bit color mode, you're probably using a shallow depth buffer. You could try a depth of 24 in your XF86Config-4 file, and see if that fixes it -- I don't see this behavior under XFree with either a GeForce 2MX or GeForce 3. indeed, i am using 16 bit depth. i just tried 24 bit depth and that fixes it. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GS needle sensitivity.
Curtis L. Olson wrote: I had someone recently comment that they thought the glide slope needle was too sensitive in FG. Can anyone comment on this? I think the glideslope needle is too sensitive in FG. :) I don't have any harder evidence either, but I'll throw in my 2¢ anyway. I've been practicing constant AoA landings in the A-4 over the last week or so (getting really good at them now, gonna have to code up arrestor wires pretty soon...), and using the ILS receiver to train my eyes to recognize the right glideslope. It's definitely very touchy, even 2-3 miles out. My sense is that maximum deflection of our instrument is only a small fraction of a degree, when it should* be something more like 1° or so. Andy * Where should means what other simulators seem to do and not what real equipment does. -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] GS needle sensitivity.
Paul Deppe writes: Glideslope beams are designed to be 1.4 degrees tall, that is, +/- 2 dots (full scale) deviation on the gauge is equal to +/- 0.7 degrees glidesope deviation, or 0.35 degrees per dot. This is the same for all standard ILS's. The localizer beam width is designed to produce +/- 2 dots deviation at +/- 700 feet deviation from centerline at the runway threshold. The localizer scale sensitivity in degrees per dot is therefore a function of the distance from the threshold to the localizer antenna. Ok, we were way off. We don't handle changing the 'cone' shape depending on the position of the transmitter relative to the threshold, but that's something that wouldn't hurt to put on the todo list todo some day. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug tracker
The SourceForge Bug Tracker has the following outstanding bug reports: ID SummaryDate Assigned To Submitted By 433286 Sun lights plane at night. 2001-06-14 17:33 nobody dmegginson (still a bug) 433288 Switching view causes slow pan.2001-06-14 17:38 nobody dmegginson (still a bug) 433735 FDM Airport Altitude 2001-06-16 07:38 nobody apeden 435655 no terrain intersection bug at e75n35 2001-06-22 20:39 nobody hrothgar 439307 LaRCSim Segfault Bug 2001-07-07 09:31 nobody nobody 440019 Aircraft level when it shouldn't be2001-07-10 05:02 nobody nobody 471112 Visual zoom out squashes and twists view 2001-10-14 14:03 nobody julianfoad (fixed) 471116 Some text on panel stays white at night2001-10-14 14:09 nobody julianfoad (mostly fixed) 471118 Turn ball flickers from side to side. 2001-10-14 14:14 nobody julianfoad (fixed) 471127 Setting sun chopped by horizon and cloud 2001-10-14 14:39 nobody julianfoad (still a bug) 471134 Httpd seg-faults on invalid paths. 2001-10-14 14:46 nobody julianfoad (I have a fix; not in CVS yet) 471136 Nav needle flickers when nav radio off 2001-10-14 14:50 nobody julianfoad (still a bug) 477578 Mouse pointer lost when menu turned off2001-11-02 09:33 nobody dluff 504761 No video when starting FGFS2002-01-16 23:41 nobody jtwilley I have marked the status in parentheses of some of these. (The oldest one is still a hot topic!) Anyone got any info on the rest? I don't know whether the tracker can be made to send notification to this mailing list of any new reports or changes, but I would like that as long as the frequency stays low. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GS needle sensitivity.
The localizer beam width is designed to produce +/- 2 dots deviation at +/- 700 feet deviation from centerline at the runway threshold. The localizer scale sensitivity in degrees per dot is therefore a function of the distance from the threshold to the localizer antenna. I agree with the summary, but would like to point out that the 700 number in the text is not a hard-and-fast rule and merely the usual default. It should be safe enough for the purposes of the simulation though. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype); \
for ( int i = 0; i num_vertices; i++)\
{ \
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]); \
if(t) glTexCoord2fv(texcoords[i]); \
glVertex3fv(vertices[i]);\
} \
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
if ( num_normals 1 )
{
glEnableClientState ( GL_NORMAL_ARRAY ) ;
glNormalPointer ( GL_FLOAT, 0, normals-get(0) ) ;
}
if ( num_texcoords 1 )
{
glEnableClientState ( GL_TEXTURE_COORD_ARRAY ) ;
glTexCoordPointer ( 2, GL_FLOAT, 0, texcoords-get(0) ) ;
}
glEnableClientState ( GL_VERTEX_ARRAY ) ;
glVertexPointer ( 3, GL_FLOAT, 0, vertices-get(0) ) ;
glDrawArrays ( gltype, 0, num_vertices ) ;
glPopClientAttrib () ;
}
}
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
plib-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/plib-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] GS needle sensitivity.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Deppe Sent: Tuesday, July 09, 2002 4:31 PM To: FGFS-Devel Subject: RE: [Flightgear-devel] GS needle sensitivity. I had someone recently comment that they thought the glide slope needle was too sensitive in FG. Can anyone comment on this? What sort of needle range relative to how many degrees off the target glide slope should we be seeing? This person suggested 2 'dots' per degree off the glide slope (but they aren't a pilot and haven't flown any real instrument approaches.) I thought I had investigated this and had done it correctly when I first wrote the code, but it would be nice to verify that we are still doing this right since the question has come up (and given that the 2d panel instrument can also scale the values, there is more than one place an error could creep in.) Gents, Glideslope beams are designed to be 1.4 degrees tall, that is, +/- 2 dots (full scale) deviation on the gauge is equal to +/- 0.7 degrees glidesope deviation, or 0.35 degrees per dot. This is the same for all standard ILS's. This is correct. The localizer beam width is designed to produce +/- 2 dots deviation at +/- 700 feet deviation from centerline at the runway threshold. The localizer scale sensitivity in degrees per dot is therefore a function of the distance from the threshold to the localizer antenna. This is worded weird. I would word it like this (this is from the diagram in the FAA instrument rating written exam). The glideslope is a beam 1.4 degrees thick. It is pointed 3 degrees up from the horizon starting at the 1000' foot mark down the runway from the threshold. At 1300' from the threshold you are at an altitude of 100' above touchdown zone. If you are off the GS by 2 dots at the 1300' mark you are off by 28' (so either 72' or 128' above the touchdown zone). If you are 5.6nm from the threshold (the Outer Marker) and you are off by 2 dots you are off by 420' up or down. The target altitude at that point is 1500' above the touchdown zone. Here is a table of what 1 dot or 2 dots mean at different distances. Distance from threshold Target Alt 1 Dot off 2 Dots off Significance 1300' 100'14' 28' Inner Marker 2600' (1/2nm) 200'28' 56' Middle Marker 1.9nm 500'70' 140' 5.6nm 1500' 210'420' Outer Marker Ryan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compile error with plib
Hi all, For the past couple of weeks I have been unable to get a clean compile of plib, although SimGear and FlightGear have given no trouble. I get a series of nearly identical errors from ssg such as this: ssgLoadBGL.cxx:2103: no matching function for call to `ssgVtxArray::ssgVtxArray (int, ssgVertexArray *, ssgNormalArray *, NULL, NULL, ssgIndexArray *)' ssg.h:1511: candidates are: ssgVtxArray::ssgVtxArray () ssg.h:1517: ssgVtxArray::ssgVtxArray (GLenum, ssgVertexArray *, ssgNormalArray *, ssgTexCoordArray *, ssgColourArray *, ssgIndexArray *) ssg.h:1546: ssgVtxArray::ssgVtxArray (const ssgVtxArray ) This is with a current checkout of CVS each day. Did I miss a patch that hasn't made it to CVS yet, or is it from a compatibility issue at this end? System is based on RH 7.1, c++ is gcc 2.96-85. Apologies for being off topic, but have not had any contact with plib beeyond its fgfs usage. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
OS = Windows ME
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 67 FPS to 74 FPS = 10%
Default orientation
I also did some testing around both Seattle and Denver, mainly for the
complex terrain, and saw the following:
KSEA went from 18 FPS to 27 FPS = 50% improvement
KDEN went from 27 FPS to 35 FPS = 30% improvement
Although I have a sample size of only three, I was surprised to see the
more complex scene with such a significantly greater improvement.
Jonathan Polley
On Tuesday, July 9, 2002, at 08:37 PM, Norman Vine wrote:
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype); \
for ( int i = 0; i num_vertices; i++) \
{\
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]); \
if(t) glTexCoord2fv(texcoords[i]); \
glVertex3fv(vertices[i]); \
}\
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
if ( num_normals 1 )
{
glEnableClientState ( GL_NORMAL_ARRAY ) ;
glNormalPointer ( GL_FLOAT, 0, normals-get(0) ) ;
}
if ( num_texcoords 1 )
{
glEnableClientState ( GL_TEXTURE_COORD_ARRAY ) ;
glTexCoordPointer ( 2, GL_FLOAT, 0, texcoords-get(0) ) ;
}
glEnableClientState ( GL_VERTEX_ARRAY ) ;
glVertexPointer ( 3, GL_FLOAT, 0, vertices-get(0) ) ;
glDrawArrays ( gltype, 0, num_vertices ) ;
glPopClientAttrib () ;
}
}
---
This sf.net email is sponsored by:ThinkGeek
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
One more thing, the command line is configured as:
--fdm=ufo --disable-clouds --disable-panel --visibility-miles=50
On Tuesday, July 9, 2002, at 10:00 PM, Jonathan Polley wrote:
OS = Windows ME
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 67 FPS to 74 FPS = 10%
Default orientation
I also did some testing around both Seattle and Denver, mainly for the
complex terrain, and saw the following:
KSEA went from 18 FPS to 27 FPS = 50% improvement
KDEN went from 27 FPS to 35 FPS = 30% improvement
Although I have a sample size of only three, I was surprised to see the
more complex scene with such a significantly greater improvement.
Jonathan Polley
On Tuesday, July 9, 2002, at 08:37 PM, Norman Vine wrote:
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype);\
for ( int i = 0; i num_vertices; i++) \
{ \
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]);\
if(t) glTexCoord2fv(texcoords[i]);\
glVertex3fv(vertices[i]); \
} \
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
if ( num_normals 1 )
{
glEnableClientState ( GL_NORMAL_ARRAY ) ;
glNormalPointer ( GL_FLOAT, 0, normals-get(0) ) ;
}
if ( num_texcoords 1 )
{
glEnableClientState ( GL_TEXTURE_COORD_ARRAY ) ;
glTexCoordPointer ( 2, GL_FLOAT, 0, texcoords-get(0) ) ;
}
glEnableClientState ( GL_VERTEX_ARRAY ) ;
glVertexPointer ( 3, GL_FLOAT, 0, vertices-get(0) ) ;
[Flightgear-devel] A-4 manual
I've been doing really well recently with my A-4 landings, so I wrote up a putative Flight Operations Manual to record the stuff I've learned: http://www.plausible.org/a4-ops/ Obviously, I've never actually trained with the Navy, so lots of this is guesswork based on data points I've picked up from research and/or experience with the flight model. So it's not necessarily something you'd want to hand to a real pilot, but it should help to get FlightGear geeks up to speed on this stuff. If folks like it, it would be nice to put it up on the flightgear.org site. A set of operational manuals for all of our core models would be a really good thing to have. I need to write up something similar for the Harrier, which is even harder to land. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
OS = Linux 2.4.18 CPU = P3-500 GFX = GF2 GTS 32MB VER = CVS from yesterday Default startup went from 13 fps to 16 fps = +23% I should note that I compiled everything with no optimizations and no in-lines since I've been using valgrind a lot lately. * [EMAIL PROTECTED] (Norman Vine) [2002.07.09 20:34]: Hi All I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib If you do test this please report back with your results and system type OS, CPU, GFX card Thanks Norman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darrell Walisser Sent: Sunday, June 30, 2002 10:27 PM To: [EMAIL PROTECTED] Subject: [Plib-devel] ssg vertex tables tuning Hi all, While running FlightGear, I noticed a problem with PLIB's vertex tables. The implementation is fine, but performance was hideous on Mac OS X (like 5fps), even on a fast G4. I'm really curious if this is also a problem on other OS's. After some examination, it seems the majority of FlightGear's geometry is rendered in small triangle fans, of 5-10 vertices each, with the occasional big lump of vertices in a detailed area. Why is this a problem? Well, it turns out that the setup time for vertex arrays is actually slower than glVertex3fv() etc because there are so few vertices per table. So, I coded a solution that only kicks into the vertex array code if the number of vertices is beyond a certain threshold, otherwise it uses glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this value is probably highly system-dependent and we might want to make it configurable either at build-time or run-time. Here's the code (for ssgVtxTable.cxx). Having different versions of the inner loop is probably overkill, but you get the idea: snip/ -- Cameron Moore / I put tape on the mirrors in my house so I don't \ \ accidentally walk through into another dimension. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] atlas binary
Got my new machine pretty much the way I want it...but rebuilding atlas is one of those little things that are left. It looks like there's some issues with Atlas and simgear that haven't been fixed in CVS yet (well as far as I've looked). Anyone have a working Atlas binary that will probably go under rh7 for a fix it and re-compile weary linux abuser? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
I also rebuilt for my other two platforms, and here are the results:
OS = Red Hat 7.3
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 32 FPS to 38 FPS = 19%
Default orientation
OS = Mac OS X 10.1.5
CPU = G4 867 MHz
GFX = GeForce 3
Default location went from 12 FPS to 34 FPS = 183% (I double checked this)
!
Default orientation
On Tuesday, July 9, 2002, at 08:37 PM, Norman Vine wrote:
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype); \
for ( int i = 0; i num_vertices; i++) \
{\
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]); \
if(t) glTexCoord2fv(texcoords[i]); \
glVertex3fv(vertices[i]); \
}\
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
if ( num_normals 1 )
{
glEnableClientState ( GL_NORMAL_ARRAY ) ;
glNormalPointer ( GL_FLOAT, 0, normals-get(0) ) ;
}
if ( num_texcoords 1 )
{
glEnableClientState ( GL_TEXTURE_COORD_ARRAY ) ;
glTexCoordPointer ( 2, GL_FLOAT, 0, texcoords-get(0) ) ;
}
glEnableClientState ( GL_VERTEX_ARRAY ) ;
glVertexPointer ( 3, GL_FLOAT, 0, vertices-get(0) ) ;
glDrawArrays ( gltype, 0, num_vertices ) ;
glPopClientAttrib () ;
}
}
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
plib-devel mailing list
[EMAIL PROTECTED]
