RE: [Flightgear-devel] request for comments?
Curtis L. Olson writes: > > Norman Vine writes: > > > > appreciating-the-Simple-in-SSG-more-each-dail'ly yr's > > So if I read you right, your beef is more with OSG's cygwin support > and less to do with capabilities, performance, etc. No it has more todo with my appreciating easily understood code in multiprogrammer projects and that OSG is still rapidly evolving BTW Have you ever tried writing any code with OSG ?? Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] request for comments?
On Tue, 05 Aug 2003 11:23:07 -0500 "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > I'm even talking about "simple" things like "multitexturing" which > isn't exactly a new concept (i.e. it's been supported by > hardware/opengl since the voodoo-1 days.) Plib unfortunatley has no > support for multitexturing. These other scene graphs do, and also > support things like "imposters" which is the technique often used for > 3d clouds. We could always create our own fork of plib, or at least plib.ssg, and implement these features ourselves. Its my understanding that plib's author is waiting for the opengl shading language to be standardised before adding any new features. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clouds3D and Matrices in general
Lee Elliott <[EMAIL PROTECTED]> said: > It's a tricky one. If fgfs rendered the a/c after everything else it wouldn't > work with the nice new clouds. I think there could be a problem with tagging > transparent objects - most side/cabin windows on the large a/c are going to > be done in the texture map via alpha/transparency against the hull paint > scheme - not only is cutting out the individual windows a lot of work, it > also tends to spoils the smoothing of the object, because of the uneven > concentration of vertices, and also increases the poly count. That's the reason for tagging the objects (with xml or ac3d object data). You can just include the fuselage if it has transparent portions. > Is an a/c model treated separately from the 'scene' or is it dissembled into > it's component sub-objects, which are then z-buffered along with the rest of > the scene polys? AFAIK it's all rendered together. The plib scene graph's (IIRC model's have they're own), are just convenient ways to handle the opengl stuff. If you have multiple scene graphs and you don't clear the depth buffer in between then it's all z-buffered together. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Build problems
Norman, seems more proper than "GL/glut.h" so I will make the change in the configure.ac files. Thanks for catching this, Curt. Norman Vine writes: > Jon Berndt writes: > > > > I've tried building the latest flightgear from CVS. I've updated to the > > latest version both plib and simgear and they build. However, when trying > > to build flightgear I get an error right away when trying to build the > > applications in test: > > > gcc-L/usr/X11R6/lib -o gl-info.exe > > gl-info.o -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 > > gl-info.o(.text+0x19):gl-info.c: undefined reference to `_glGetString' > > gl-info.o(.text+0x58):gl-info.c: undefined reference to `_glGetFloatv' > > gl-info.o(.text+0x9c):gl-info.c: undefined reference to `_glGetFloatv' > > gl-info.o(.text+0xdc):gl-info.c: undefined reference to `_glGetIntegerv' > > gl-info.o(.text+0x120):gl-info.c: undefined reference to `_glGetIntegerv' > > I had the same problem working in a Cygwin bash shell > ended up making sure that the GLUT_H check in both SimGear's > and FlightGear's configure.ac read as below > > dnl check for glut location > AC_CHECK_HEADER(GL/glut.h) > if test "x$ac_cv_header_GL_glut_h" = "xyes"; then > AC_DEFINE([GLUT_H], , [Define as glut.h include location]) > else > AC_CHECK_HEADER(GLUT/glut.h) > if test "x$ac_cv_header_GLUT_glut_h" = "xyes"; then > AC_DEFINE([GLUT_H], , [Define as glut.h include location]) > else > echo "Neither GL/glut.h nor GLUT/glut.h found. Cannot continue" > exit > fi > fi > > > NOTE the use of <> and not "" surrounding GL/glut.h > > I think that this is an appropriate fix for all systems but YMMV > > Norman > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] request for comments?
Norman Vine writes: > No it has more todo with my appreciating easily understood code in > multiprogrammer projects and that OSG is still rapidly evolving Fair enough; I've heard the 'rapidly' developing comment from other sources as well. > BTW Have you ever tried writing any code with OSG ?? I personally have not written any code with it, but a couple people here locally have been using it and seem to be pretty successful and happy with their results. Lack of documentation is another knock on both OSG and OpenSG. Plib is pretty good on that front, at least for the core functionality that has been around for a couple years. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Multiplayer Network Server
On Tue, 5 Aug 2003 19:36:15 +0100 (BST) Paul Morriss <[EMAIL PROTECTED]> wrote: * Mass Multiplayer Server (MAYS) - Instead of a single How do you get MAYS from Mass MultiPlayer Server? Should it not be MMS, or MMPS? This is serious. The correct acronym is critical in getting project support! ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] request for comments?
Lee Elliott writes: > What native object formats would be supported? If we stuck with the .ac > object format then we're going to be limited to one texture per object > anyway. Lee, I don't think either OSG nor OpenSG support the .ac format. However, it shouldn't be that hard to write a plib based converter to a format that one of these does support. The AC format also seems to have significant short comings in terms of calculating vertex normals (look closely at the shading of the control surfaces on most .ac format models to see how bad this is.) > I'd like to switch to a more versatile object format but that's going to > require new modelling/texturing s/w and the skills to use them. > > I don't think this will be a show stopper but it's going to take some time to > transition, especially if the models needs to be converted. Yup, another option would be to write a .ac loader if we do switch... that might be pretty doable since the .ac format is fairly simple. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] Build problems
What would have changed to screw it up, though? I've never had a problem with this before... JOn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Norman Vine > Sent: Tuesday, August 05, 2003 8:03 AM > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] Build problems > > > Jon Berndt writes: > > > > I've tried building the latest flightgear from CVS. I've updated to the > > latest version both plib and simgear and they build. However, > when trying > > to build flightgear I get an error right away when trying to build the > > applications in test: > > > gcc-L/usr/X11R6/lib -o gl-info.exe > > gl-info.o -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 > > gl-info.o(.text+0x19):gl-info.c: undefined reference to `_glGetString' > > gl-info.o(.text+0x58):gl-info.c: undefined reference to `_glGetFloatv' > > gl-info.o(.text+0x9c):gl-info.c: undefined reference to `_glGetFloatv' > > gl-info.o(.text+0xdc):gl-info.c: undefined reference to `_glGetIntegerv' > > gl-info.o(.text+0x120):gl-info.c: undefined reference to > `_glGetIntegerv' > > I had the same problem working in a Cygwin bash shell > ended up making sure that the GLUT_H check in both SimGear's > and FlightGear's configure.ac read as below > > dnl check for glut location > AC_CHECK_HEADER(GL/glut.h) > if test "x$ac_cv_header_GL_glut_h" = "xyes"; then > AC_DEFINE([GLUT_H], , [Define as glut.h include location]) > else > AC_CHECK_HEADER(GLUT/glut.h) > if test "x$ac_cv_header_GLUT_glut_h" = "xyes"; then > AC_DEFINE([GLUT_H], , [Define as glut.h > include location]) > else > echo "Neither GL/glut.h nor GLUT/glut.h found. Cannot continue" > exit > fi > fi > > > NOTE the use of <> and not "" surrounding GL/glut.h > > I think that this is an appropriate fix for all systems but YMMV > > Norman > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] request for comments?
Curtis L. Olson writes: > > Hi Norman, > > I appreciate your experience and that your comment is well informed, > but taken at face value, it doesn't do much to inform the rest of us. > Can you list any supporting reasons? That's kind of what I was > angling for in my original posting. I use OSG it in several projects and keeping a gnu WIN32 port going is a *MAJOR* PITA in fact currently I seem to be the only one who can compile the examples with Cygwin That said OSG is a powerful and rapidly growing library that I appreciate enough to help maintain but I can not reccomend it 'yet' for a cross platform multiprogrammer project such as FGFS. Give it 6 months or so and my opinions might change but for now I reccomend FlightGear staying with SSG appreciating-the-Simple-in-SSG-more-each-dail'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] request for comments?
Norman Vine writes: > Well being the original porter and current maintainer of > OpenSceneGraph's Cygwin and MingW32 ports as well as the main WIN32 > contributer < porter > for Producer the GLUT replacement used by OSG > I guess I might be in a position to make a relatively informed > comment. > > I reccomend staying with SSG Hi Norman, I appreciate your experience and that your comment is well informed, but taken at face value, it doesn't do much to inform the rest of us. Can you list any supporting reasons? That's kind of what I was angling for in my original posting. Thanks, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org 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] request for comments?
On Tuesday 05 August 2003 17:23, Curtis L. Olson wrote: > Hi, > > I just wanted to float an idea on the list and see if anyone had any > comments. This isn't an official proposal and I'm not chomping at the > bit to make a change. It's just an idea I find interesting to think > about and I'd like to get some sort of feedback/comments if any one > has any. > > plib/ssg has served us well and when we jumped on board the plib > bandwagon, it was the best thing available in terms of performance, > robustness, stability, features, etc. > > However, in the last couple years, the scene graph portion of plib has > developed very slowly; meanwhile projects like "Open Scene Graph" > (http://openscenegraph.org/) and "OpenSG" (http://www.opensg.org) seem > to be roaring ahead with support for many of the newer graphics tricks > and effects. > > I'm even talking about "simple" things like "multitexturing" which > isn't exactly a new concept (i.e. it's been supported by > hardware/opengl since the voodoo-1 days.) Plib unfortunatley has no > support for multitexturing. These other scene graphs do, and also > support things like "imposters" which is the technique often used for > 3d clouds. > > At the risk of tainting the discussion I will say that from my > investigation, "Open Scene Graph" seems to be the better choice. > There are people here locally that use it, and I know that other > flightgear developers have used it as well. It seems to support all > the platforms that we currently support. No one I've talked to seems > to know much about OpenSG and the one web link I found > (http://sgi.felk.cvut.cz/~pavlicm/Dipl/sw.htm) seems to put Open Scene > Graph ahead in terms of performance (based on a single test which > doesn't say too much actually.) > > It would probably be a large job to convert everything in > simgear/flightgear over to use a new scene graph, but it may give us > many more options for moving forward with new and better graphic > effects. There will certainly be ramifications that we won't discover > until it's too late to go back. > > One proposal I've heard has been to try to build a "scene graph > independent" layer (i.e. our own generic scene graph API that could > translate calls into any of the actual scene graph api's, but I'd like > to avoid that based on performance concerns and also the point here is > not to write to the lowest common denominator, we want to be able to > push forward with newer graphic effects.) > > Any other thoughts/comments? > > Thanks, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org What native object formats would be supported? If we stuck with the .ac object format then we're going to be limited to one texture per object anyway. I'd like to switch to a more versatile object format but that's going to require new modelling/texturing s/w and the skills to use them. I don't think this will be a show stopper but it's going to take some time to transition, especially if the models needs to be converted. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] request for comments?
On Tuesday, August 5, 2003, at 05:23 pm, Curtis L. Olson wrote: At the risk of tainting the discussion I will say that from my investigation, "Open Scene Graph" seems to be the better choice. There are people here locally that use it, and I know that other flightgear developers have used it as well. It seems to support all the platforms that we currently support. No one I've talked to seems to know much about OpenSG and the one web link I found (http://sgi.felk.cvut.cz/~pavlicm/Dipl/sw.htm) seems to put Open Scene Graph ahead in terms of performance (based on a single test which doesn't say too much actually.) OpenSceneGraph looks much better than I remember, but it's also worth looking at OGRE, which is being (very) actively developed. http://ogre.sf.net/ Is the place to start. Note that OGRE is a bit more 'gamey' than the other systems mentioned, notably it supports DirectX in addition to OpenGL. I'm not really sure if being more game-orientated would be considered a bonus or not for FlightGear. Also, I'm far more concerned about getting rid of PLIB / GLUT for our OS interaction, than the graphical shortcomings of SSG. There are a couple of obvious replacements: SDL, SDL, or just possibly, SDL. :-) This would remove various limitations on joysticks (SDL supports hats), number of sound channels (SDL has a mixer), video mode-switching (SDL knows how to make X do that, quite apart from on Win32 or OS-X) Perhaps most importantly, SDL gives the application back it's event loop. Oh, and the the OpenSceneGraph FAQ lists SDL as a candidate rendering layer, for people who're finding GLUT a pain. Of course switching both the scene graph and the OS-abstraction at the same time would be silly : one could either switch to SDL, and initially retain SSG, or alternatively, try and get OpenSceneGraph working alongside the rest of PLIB. Not sure which makes more sense. All my opinion, naturally. James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
