[Flightgear-devel] New JSBSim Newsletter Released
The latest issue of "Back of the Envelope", the newsletter for the JSBSim Flight Dynamics Model, has been posted at the JSBSim web site. You can download the PDF and read it by going to www.jsbsim.org and clicking on the newsletter link. Articles in this issue: - JSBSim Configuration File Format v2.0 Nears Release - Latest News - In Depth: Using JSBSim with Matlab / Simulink - Integrating JSBSim With Your Application - Simulate This! The Custer Channel Wing Thanks to this issue's contributing author, D. Wysong. As always, comments are solicited and welcome. Enjoy! Jon S. Berndt -- Project Coordinator JSBSim Flight Dynamics Model http://www.jsbsim.org ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
That's what happens when you don't read the whole thing. :) On Mon, 31 Jan 2005 16:03:25 -0800, Adam Dershowitz <[EMAIL PROTECTED]> wrote: > Don't you mean it should not include it with Windows? > Since it is #ifndef not #ifdef? > > -- Adam > > > From: Arthur Wiebe <[EMAIL PROTECTED]> > > Reply-To: FlightGear developers discussions > > > > Date: Mon, 31 Jan 2005 18:46:07 -0500 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] Mac os x simgear build break with > > RenderTexture.cpp > > > > That is wierd. Because of this: > > > > #ifndef _WIN32 > > # include SG_GLX_H > > #endif > > > > It should only include GLX on Windows. > > > > On Mon, 31 Jan 2005 17:51:34 -0500, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > >> > >> When I went to do a full build of simgear January 27th, I am having a > >> problem with the build of RenderTexture.cpp. I have been unable to > >> download newer source since then due to a network problem that breaks > >> CVS on my local network. > >> > >> Mac OS X doesn't generally support glx.h > >> > >> If someone has X11 developer sources installed on mac os x, the glx > >> file exists on: > >> > >> /usr/X11R6/include/GL > >> > >> but I don't think that I should be using that GLX file as I am NOT > >> building a version of FG for X, but rather for native mac os x. > >> > >> Does anyone have any suggestions for how to build simgear/screen > >> without requiring GLX? (I tried explicitly giving --without-x during > >> configure but it didn't seem to help). > >> > >> The first error message is: > >> > >> g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. > >> -DGLX_GLXEXT_PROTOTYPES > >> -I/Users/ima/Desktop/FlightGear/fgdev9.8/include -g -O2 -D_REENTRANT > >> -c -o RenderTexture.o `test -f 'RenderTexture.cpp' || echo > >> './'`RenderTexture.cpp > >> In file included from RenderTexture.cpp:58: > >> ../../simgear/screen/RenderTexture.h:56:20: OpenGL/glx.h: No such file > >> or directory > >> > >> .. followed by these errors > >> > >> In file included from RenderTexture.cpp:58: > >> ../../simgear/screen/RenderTexture.h:342: error: 'GLXContext' is used > >> as a > >> type, but is not defined as a type. > >> ../../simgear/screen/RenderTexture.h:343: error: 'GLXPbuffer' is used > >> as a > >> type, but is not defined as a type. > >> ../../simgear/screen/RenderTexture.h:345: error: 'GLXDrawable' is used > >> as a > >> type, but is not defined as a type. > >> ../../simgear/screen/RenderTexture.h:346: error: 'GLXContext' is used > >> as a > >> type, but is not defined as a type. > >> RenderTexture.cpp: In constructor `RenderTexture::RenderTexture(const > >> char*)': > >> RenderTexture.cpp:127: error: class `RenderTexture' does not have any > >> field > >> named `_hGLContext' > >> RenderTexture.cpp:128: error: class `RenderTexture' does not have any > >> field > >> named `_hPBuffer' > >> .. and so on > >> > >> Sorry, I seem especially clueless lately. 8-( > >> TIA for any help! > >> > >> Best regards, > >> > >> Ima > >> > >> ___ > >> Flightgear-devel mailing list > >> Flightgear-devel@flightgear.org > >> http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >> 2f585eeea02e2c79d7b1d8c4963bae2d > >> > > > > > > -- > > > > - http://artooro.blogspot.com (Weblog) > > - http://machcms.sourceforge.net (MachCMS Project) > > - http://acalproj.sourceforge.net (Calendar Project) > > > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@flightgear.org > > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > 2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
Don't you mean it should not include it with Windows? Since it is #ifndef not #ifdef? -- Adam > From: Arthur Wiebe <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions > Date: Mon, 31 Jan 2005 18:46:07 -0500 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Mac os x simgear build break with > RenderTexture.cpp > > That is wierd. Because of this: > > #ifndef _WIN32 > # include SG_GLX_H > #endif > > It should only include GLX on Windows. > > On Mon, 31 Jan 2005 17:51:34 -0500, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: >> >> When I went to do a full build of simgear January 27th, I am having a >> problem with the build of RenderTexture.cpp. I have been unable to >> download newer source since then due to a network problem that breaks >> CVS on my local network. >> >> Mac OS X doesn't generally support glx.h >> >> If someone has X11 developer sources installed on mac os x, the glx >> file exists on: >> >> /usr/X11R6/include/GL >> >> but I don't think that I should be using that GLX file as I am NOT >> building a version of FG for X, but rather for native mac os x. >> >> Does anyone have any suggestions for how to build simgear/screen >> without requiring GLX? (I tried explicitly giving --without-x during >> configure but it didn't seem to help). >> >> The first error message is: >> >> g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. >> -DGLX_GLXEXT_PROTOTYPES >> -I/Users/ima/Desktop/FlightGear/fgdev9.8/include -g -O2 -D_REENTRANT >> -c -o RenderTexture.o `test -f 'RenderTexture.cpp' || echo >> './'`RenderTexture.cpp >> In file included from RenderTexture.cpp:58: >> ../../simgear/screen/RenderTexture.h:56:20: OpenGL/glx.h: No such file >> or directory >> >> .. followed by these errors >> >> In file included from RenderTexture.cpp:58: >> ../../simgear/screen/RenderTexture.h:342: error: 'GLXContext' is used >> as a >> type, but is not defined as a type. >> ../../simgear/screen/RenderTexture.h:343: error: 'GLXPbuffer' is used >> as a >> type, but is not defined as a type. >> ../../simgear/screen/RenderTexture.h:345: error: 'GLXDrawable' is used >> as a >> type, but is not defined as a type. >> ../../simgear/screen/RenderTexture.h:346: error: 'GLXContext' is used >> as a >> type, but is not defined as a type. >> RenderTexture.cpp: In constructor `RenderTexture::RenderTexture(const >> char*)': >> RenderTexture.cpp:127: error: class `RenderTexture' does not have any >> field >> named `_hGLContext' >> RenderTexture.cpp:128: error: class `RenderTexture' does not have any >> field >> named `_hPBuffer' >> .. and so on >> >> Sorry, I seem especially clueless lately. 8-( >> TIA for any help! >> >> Best regards, >> >> Ima >> >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@flightgear.org >> http://mail.flightgear.org/mailman/listinfo/flightgear-devel >> 2f585eeea02e2c79d7b1d8c4963bae2d >> > > > -- > > - http://artooro.blogspot.com (Weblog) > - http://machcms.sourceforge.net (MachCMS Project) > - http://acalproj.sourceforge.net (Calendar Project) > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
That is wierd. Because of this: #ifndef _WIN32 # include SG_GLX_H #endif It should only include GLX on Windows. On Mon, 31 Jan 2005 17:51:34 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > When I went to do a full build of simgear January 27th, I am having a > problem with the build of RenderTexture.cpp. I have been unable to > download newer source since then due to a network problem that breaks > CVS on my local network. > > Mac OS X doesn't generally support glx.h > > If someone has X11 developer sources installed on mac os x, the glx > file exists on: > > /usr/X11R6/include/GL > > but I don't think that I should be using that GLX file as I am NOT > building a version of FG for X, but rather for native mac os x. > > Does anyone have any suggestions for how to build simgear/screen > without requiring GLX? (I tried explicitly giving --without-x during > configure but it didn't seem to help). > > The first error message is: > > g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. > -DGLX_GLXEXT_PROTOTYPES > -I/Users/ima/Desktop/FlightGear/fgdev9.8/include -g -O2 -D_REENTRANT > -c -o RenderTexture.o `test -f 'RenderTexture.cpp' || echo > './'`RenderTexture.cpp > In file included from RenderTexture.cpp:58: > ../../simgear/screen/RenderTexture.h:56:20: OpenGL/glx.h: No such file > or directory > > .. followed by these errors > > In file included from RenderTexture.cpp:58: > ../../simgear/screen/RenderTexture.h:342: error: 'GLXContext' is used > as a > type, but is not defined as a type. > ../../simgear/screen/RenderTexture.h:343: error: 'GLXPbuffer' is used > as a > type, but is not defined as a type. > ../../simgear/screen/RenderTexture.h:345: error: 'GLXDrawable' is used > as a > type, but is not defined as a type. > ../../simgear/screen/RenderTexture.h:346: error: 'GLXContext' is used > as a > type, but is not defined as a type. > RenderTexture.cpp: In constructor `RenderTexture::RenderTexture(const > char*)': > RenderTexture.cpp:127: error: class `RenderTexture' does not have any > field > named `_hGLContext' > RenderTexture.cpp:128: error: class `RenderTexture' does not have any > field > named `_hPBuffer' > .. and so on > > Sorry, I seem especially clueless lately. 8-( > TIA for any help! > > Best regards, > > Ima > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > -- - http://artooro.blogspot.com (Weblog) - http://machcms.sourceforge.net (MachCMS Project) - http://acalproj.sourceforge.net (Calendar Project) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Frederic Bouvier wrote: That's really nice ! But if all these models are placed automagically, what would happen to model that represent the real buildings ? I mean : if I create the Empire State Building and put it in fgfsdb, would there be a hole around it or would it be in collision with its generic clone ? It already happens at SFO with the radio towers and they need to be removed manually. Assuming there's a unique ID in the DOF (I've not seen the file yet) I'll maintain an exclusions list, so that when an updated DOF is imported such buildings can be ignored because we have a better version available. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
On Mon, 31 Jan 2005 23:37:49 +0100 Frederic Bouvier wrote: > > That's really nice ! > But if all these models are placed automagically, what would happen to > model that represent the real buildings ? I mean : if I create the > Empire State Building and put it in fgfsdb, would there be a hole around > > it or would it be in collision with its generic clone ? It already > happens at SFO with the radio towers and they need to be removed > manually. Yeah, the plan is that when a "correct" model for a bldg gets added to the DB, the entry in the DB for the generic building would get removed at that time. That should be straightforward to do, and not very demanding since the rate at which stuff gets added isn't huge. Since the DB is browseable, someone adding specific structures could make life easier by noting "delete the generic bldg at _" when adding their specific one. Radio towers are another matter. One of the original goals of this exercise with the DOF was in identifying which towers in the scenery are most likely buildings with antennae on the top, so that those towers aren't placed in the scenery to begin with (so removing them manually, like you've done with SF, wouldn't be necessary -- they wouldn't be placed there to begin with). That's what I was referring to when I said there's still stuff to work out about the radio towers. I have code that compares the FCC and FAA databases and tries to identify likely counterparts within stated positional uncertainties, but I'm still tweaking it. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpn5Td3SXg4t.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
When I went to do a full build of simgear January 27th, I am having a problem with the build of RenderTexture.cpp. I have been unable to download newer source since then due to a network problem that breaks CVS on my local network. Mac OS X doesn't generally support glx.h If someone has X11 developer sources installed on mac os x, the glx file exists on: /usr/X11R6/include/GL but I don't think that I should be using that GLX file as I am NOT building a version of FG for X, but rather for native mac os x. Does anyone have any suggestions for how to build simgear/screen without requiring GLX? (I tried explicitly giving --without-x during configure but it didn't seem to help). The first error message is: g++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -DGLX_GLXEXT_PROTOTYPES -I/Users/ima/Desktop/FlightGear/fgdev9.8/include -g -O2 -D_REENTRANT -c -o RenderTexture.o `test -f 'RenderTexture.cpp' || echo './'`RenderTexture.cpp In file included from RenderTexture.cpp:58: ../../simgear/screen/RenderTexture.h:56:20: OpenGL/glx.h: No such file or directory .. followed by these errors In file included from RenderTexture.cpp:58: ../../simgear/screen/RenderTexture.h:342: error: 'GLXContext' is used as a type, but is not defined as a type. ../../simgear/screen/RenderTexture.h:343: error: 'GLXPbuffer' is used as a type, but is not defined as a type. ../../simgear/screen/RenderTexture.h:345: error: 'GLXDrawable' is used as a type, but is not defined as a type. ../../simgear/screen/RenderTexture.h:346: error: 'GLXContext' is used as a type, but is not defined as a type. RenderTexture.cpp: In constructor `RenderTexture::RenderTexture(const char*)': RenderTexture.cpp:127: error: class `RenderTexture' does not have any field named `_hGLContext' RenderTexture.cpp:128: error: class `RenderTexture' does not have any field named `_hPBuffer' .. and so on Sorry, I seem especially clueless lately. 8-( TIA for any help! Best regards, Ima ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Chris Metzler a écrit : With building positions and heights from the FAA Digital Obstruction File, and a few new buriable (thus, height-adjustable) models, here's an approach into La Guardia Rwy 04, starting over Staten Island. http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg thru http://www.speakeasy.org/~cmetzler/KLGA_04_approach_023.jpg Some highlights: lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg over downtown brooklyn, show detail on some of the models -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_010.jpg view of midtown manhattan -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_011.jpg adjusting to final with manhattan in background -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_015.jpg over the tarmac, manhattan in the distance -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_021.jpg The plan is for the models to go into Jon Stockill's model database, and for the DOF data to go in there too, once some stuff about radio towers gets worked out. Then the downloadable scenery adds will include tall buildings, smokestacks, and other things. Other than the radio tower stuff, my main holdup is getting the models to look nicer. The way I'm proceding for the generic tall building models: I have a set of Blender models, all meters tall, with cross-sections of 50m square, 60m square, 60m quare with a 5m/side right triangle taken out of the corners, 30m x 60m, 25m radius circle, etc. I am in the process of making small (typically 32x32, sometimes 64x64, rarely 128x128) textures of building sides, typically tiny sections cropped from photos and then processed in the Gimp. My plan is to mix and match these to create a very wide variety of buildings that can be drawn from randomly when the .stg files are created. I'm not yet happy with the way most of them look. Some of them have alignment issues with horizontal/vertical features on the texture tiles that I thought I'd fixed, but haven't really. Some look very good close up, but from a distance look like odd solid color blocks. Most need roofs. None have hazard lights. And there will be more of them. So this isn't ready yet. But the pics should give an idea of how this can go. Re: frame rates. You can see the frame rates I was getting in the lower-right-hand corner. This is with a Gf4 Ti4600, but at 1600x1200. I did this approach again without the buildings in the scene, and got framerates that were 1-4 fps larger. And Manhattan is a worst-case scenario. So I don't think framerates are going to be much of a problem. That's really nice ! But if all these models are placed automagically, what would happen to model that represent the real buildings ? I mean : if I create the Empire State Building and put it in fgfsdb, would there be a hole around it or would it be in collision with its generic clone ? It already happens at SFO with the radio towers and they need to be removed manually. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fun with the FAA DOF.
With building positions and heights from the FAA Digital Obstruction File, and a few new buriable (thus, height-adjustable) models, here's an approach into La Guardia Rwy 04, starting over Staten Island. http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg thru http://www.speakeasy.org/~cmetzler/KLGA_04_approach_023.jpg Some highlights: lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg lower manhattan and downtown brooklyn start to come into view -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg over downtown brooklyn, show detail on some of the models -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_010.jpg view of midtown manhattan -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_011.jpg adjusting to final with manhattan in background -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_015.jpg over the tarmac, manhattan in the distance -- http://www.speakeasy.org/~cmetzler/KLGA_04_approach_021.jpg The plan is for the models to go into Jon Stockill's model database, and for the DOF data to go in there too, once some stuff about radio towers gets worked out. Then the downloadable scenery adds will include tall buildings, smokestacks, and other things. Other than the radio tower stuff, my main holdup is getting the models to look nicer. The way I'm proceding for the generic tall building models: I have a set of Blender models, all meters tall, with cross-sections of 50m square, 60m square, 60m quare with a 5m/side right triangle taken out of the corners, 30m x 60m, 25m radius circle, etc. I am in the process of making small (typically 32x32, sometimes 64x64, rarely 128x128) textures of building sides, typically tiny sections cropped from photos and then processed in the Gimp. My plan is to mix and match these to create a very wide variety of buildings that can be drawn from randomly when the .stg files are created. I'm not yet happy with the way most of them look. Some of them have alignment issues with horizontal/vertical features on the texture tiles that I thought I'd fixed, but haven't really. Some look very good close up, but from a distance look like odd solid color blocks. Most need roofs. None have hazard lights. And there will be more of them. So this isn't ready yet. But the pics should give an idea of how this can go. Re: frame rates. You can see the frame rates I was getting in the lower-right-hand corner. This is with a Gf4 Ti4600, but at 1600x1200. I did this approach again without the buildings in the scene, and got framerates that were 1-4 fps larger. And Manhattan is a worst-case scenario. So I don't think framerates are going to be much of a problem. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpq2gk8suAuy.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Frederic Bouvier said: > Jim Wilson a écrit : > > >Note that earlier in this thread it was mentioned that the "hack" that's in > >SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've > >confirmed). Someone also mentioned that the hack is working on one > >particular > >model, but I haven't looked at that yet. Really I just want to un-hackify > >this thing so that it uses the plib API. The question is, should I be able > >to > >do so with the current API? (in principle that is, assuming no bugs, > >alpha-sort issues, etc.) > > > > > > Jim, there is no black magic behind this "hack" that is not one. We > found when implementing display lists, that we couldn't manipulate state > anymore. So, for certain animation, we just returned back to immediate > rendering. There is a 'ignore' flag ( sgMakeAnimation function ) in > model.cxx that is doing just that. When a Blend animation is detected, > the makeDList function is not called for the animation branch. It is > just valid plib usage. > Do you know the answer to my question? I never suggested it was black magic. It just is not the right way to do it. The "hack" I'm refering to is "color[3] = _blend;" in SimGear, where "color[3]" is a pointer to a property of a plib class (not even in the same library package!). It is inevitable that that kind of thing will lead to breakage...or at least that's been my experience. Dlist doesn't seem to be the issue here, as I mentioned before, writing GL_EMISSIVE works. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Jim Wilson a écrit : Note that earlier in this thread it was mentioned that the "hack" that's in SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've confirmed). Someone also mentioned that the hack is working on one particular model, but I haven't looked at that yet. Really I just want to un-hackify this thing so that it uses the plib API. The question is, should I be able to do so with the current API? (in principle that is, assuming no bugs, alpha-sort issues, etc.) Jim, there is no black magic behind this "hack" that is not one. We found when implementing display lists, that we couldn't manipulate state anymore. So, for certain animation, we just returned back to immediate rendering. There is a 'ignore' flag ( sgMakeAnimation function ) in model.cxx that is doing just that. When a Blend animation is detected, the makeDList function is not called for the animation branch. It is just valid plib usage. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Norman Vine said: > Jim Wilson writes: > > > > Norman Vine said: > > > > > Jim Wilson writes: > > > > > > > > > > > > > As far as the reason the existing alpha-blend code doesn't work may be related > > > > to an update in 1.8.4 that was described in ChangeLog as "smaller and cleaner > > > > scene graphs". That's just a WAG, but it seems that this function would be > > > > better accomplished through an API rather than writing directly back to > > > > scenegraph memory from SimGear anyway (I find it mildly irritating that you > > > > can even do that :-/). > > > > > > My guess is that you aren't following the rules :-) > > > http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node111.html > > > > > > > You might be right. From the above link, it says: "If lighting is enabled, > > then the ambient and diffuse reflectance coefficients of the material should > > correspond to the translucency of the object." So does this mean that when > > using the plib API it is necessary to set alpha in both the ambient _and_ > > diffuse state colors? I think I tried that but... > > > > ..for some reason I was seeing some bogus numbers (> 1.0 colors) come up for > > ambient when dumping the ssgLeaf objects concerned. Maybe finding the > > source > > of that problem will fix things. > > Hmm ... > > I was alluding render ordering. > > Note it could be that the 'optimization' code in ssgBranch.cxx is doing things > 'behind your back' after loading that invalidates any assumptions about the > render order being the inverse of the loading order. > < not that you are necessarily making this assumption > I don't think that is it. I can set alpha values (by editing the ac3d file) in the test object and it will show as translucency, but the animation code will not manipulate that translucency as it once did. It is as if whatever the alpha is set to at load time, that is where it stays. Note that earlier in this thread it was mentioned that the "hack" that's in SimGear now worked with plib 1.8.3 and does not work with plib 1.8.4 (I've confirmed). Someone also mentioned that the hack is working on one particular model, but I haven't looked at that yet. Really I just want to un-hackify this thing so that it uses the plib API. The question is, should I be able to do so with the current API? (in principle that is, assuming no bugs, alpha-sort issues, etc.) > > you are familiar with this > http://www.sjbaker.org/steve/omniv/alpha_sorting.html Yeah, I think so, but a while back. As you know this has been a regular topic around here. Thanks, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] [PATCH] Simgear support for emissiveanimationfor instruments (ver 2)
Jim Wilson writes: > > Norman Vine said: > > > Jim Wilson writes: > > > > > > > > > > As far as the reason the existing alpha-blend code doesn't work may be > > > related > > > to an update in 1.8.4 that was described in ChangeLog as "smaller and > > > cleaner > > > scene graphs". That's just a WAG, but it seems that this function would > > > be > > > better accomplished through an API rather than writing directly back to > > > scenegraph memory from SimGear anyway (I find it mildly irritating that > > > you > > > can even do that :-/). > > > > My guess is that you aren't following the rules :-) > > http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node111.html > > > > You might be right. From the above link, it says: "If lighting is enabled, > then the ambient and diffuse reflectance coefficients of the material should > correspond to the translucency of the object." So does this mean that when > using the plib API it is necessary to set alpha in both the ambient _and_ > diffuse state colors? I think I tried that but... > > ..for some reason I was seeing some bogus numbers (> 1.0 colors) come up for > ambient when dumping the ssgLeaf objects concerned. Maybe finding the source > of that problem will fix things. Hmm ... I was alluding render ordering. Note it could be that the 'optimization' code in ssgBranch.cxx is doing things 'behind your back' after loading that invalidates any assumptions about the render order being the inverse of the loading order. < not that you are necessarily making this assumption > you are familiar with this http://www.sjbaker.org/steve/omniv/alpha_sorting.html Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] [PATCH] Simgear support for emissive animationfor instruments (ver 2)
Norman Vine said: > Jim Wilson writes: > > > > > > > As far as the reason the existing alpha-blend code doesn't work may be > > related > > to an update in 1.8.4 that was described in ChangeLog as "smaller and > > cleaner > > scene graphs". That's just a WAG, but it seems that this function would be > > better accomplished through an API rather than writing directly back to > > scenegraph memory from SimGear anyway (I find it mildly irritating that you > > can even do that :-/). > > My guess is that you aren't following the rules :-) > http://www.opengl.org/resources/tutorials/advanced/advanced97/notes/node111.html > You might be right. From the above link, it says: "If lighting is enabled, then the ambient and diffuse reflectance coefficients of the material should correspond to the translucency of the object." So does this mean that when using the plib API it is necessary to set alpha in both the ambient _and_ diffuse state colors? I think I tried that but... ..for some reason I was seeing some bogus numbers (> 1.0 colors) come up for ambient when dumping the ssgLeaf objects concerned. Maybe finding the source of that problem will fix things. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Frederic Bouvier wrote: Erik Hofman a écrit : There has been a hack to get alpha blending to work when display lists are activated. Maybe this is having the opposite effect at this time? You can disable that be commenting out the line "ignore = true;" for theSGBlendAnimation in simgear/scene/model/model.cxx It's just a ild guess though. This hack is working right for the ufo. Yes, but Jim is trying it on a totally different way. As I understand it he even creates a new scenegraph subbranch every time there is a change. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Jim Wilson wrote: Uggh...sometimes plib really sucks. The ssg API seems pretty straight forward until some quirk rears its ugly head. There's just enough documentation to make you think it'll work. The above idea didn't pan out. It seems odd that I can write a GL_EMISSIVE state and it gets rendered next time, but the GL_DIFFUSE state update seems to have no effect. Anyone know why? There has been a hack to get alpha blending to work when display lists are activated. Maybe this is having the opposite effect at this time? You can disable that be commenting out the line "ignore = true;" for theSGBlendAnimation in simgear/scene/model/model.cxx It's just a ild guess though. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Simgear support for emissive animation for instruments (ver 2)
Erik Hofman a écrit : Jim Wilson wrote: Uggh...sometimes plib really sucks. The ssg API seems pretty straight forward until some quirk rears its ugly head. There's just enough documentation to make you think it'll work. The above idea didn't pan out. It seems odd that I can write a GL_EMISSIVE state and it gets rendered next time, but the GL_DIFFUSE state update seems to have no effect. Anyone know why? There has been a hack to get alpha blending to work when display lists are activated. Maybe this is having the opposite effect at this time? You can disable that be commenting out the line "ignore = true;" for theSGBlendAnimation in simgear/scene/model/model.cxx It's just a ild guess though. This hack is working right for the ufo. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
