re: [Flightgear-devel] request for comments?

2003-08-14 Thread David Megginson
Curtis L. Olson writes:

  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.)

That might be overkill, but it would be a good idea to try to isolate
the SSG calls to as few files as possible before we make the final
decision about switching.  Right now, I think that the SSG stuff is
spread a little haphazardly through the code base.


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] request for comments?

2003-08-14 Thread Norman Vine
Curtis L. Olson writes:
 
 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.
 
 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. 

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

HTH

Norman




___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] request for comments?

2003-08-11 Thread Jim Wilson
Curtis L. Olson [EMAIL PROTECTED] said:

 I don't think either OSG nor OpenSG support the .ac format.  However,
OpenSceneGraph does according to the website.  Not sure how well it works.

 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.)

That's a problem with the models themselves.  There are also things we could
do to help this on the plib side.

Best,

Jim



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] request for comments?

2003-08-10 Thread Curtis L. Olson
Norman Vine writes:
 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

So if I read you right, your beef is more with OSG's cygwin support
and less to do with capabilities, performance, etc.

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] request for comments?

2003-08-08 Thread Jon S Berndt
On Tue, 5 Aug 2003 11:23:07 -0500
 Curtis L. Olson [EMAIL PROTECTED] wrote:
but it may give us many more options for moving forward with new and
better graphic effects.
My uneducated, gut feeling, leads me to opt for the route 
that gives the most promise for the future.

Jon

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] request for comments?

2003-08-06 Thread Gene Buckle
 On Tue, 5 Aug 2003 11:23:07 -0500
   Curtis L. Olson [EMAIL PROTECTED] wrote:

 but it may give us many more options for moving forward with new and
 better graphic effects.

 My uneducated, gut feeling, leads me to opt for the route
 that gives the most promise for the future.


...and from what I've seen of you guys struggling with the limitations of
the existing system, plib is _not_ the best choice.

g.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


RE: [Flightgear-devel] request for comments?

2003-08-06 Thread Jim Wilson
Curtis L. Olson [EMAIL PROTECTED] said:

 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.
 

Could it be easier to work on adding some of these features to plib?  Are
there major issues there?

Best,

Jim

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] request for comments?

2003-08-05 Thread James Turner
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


Re: [Flightgear-devel] request for comments?

2003-08-05 Thread Lee Elliott
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?

2003-08-05 Thread Curtis L. Olson
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?

2003-08-05 Thread Norman Vine
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?

2003-08-05 Thread Curtis L. Olson
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] request for comments?

2003-08-05 Thread Curtis L. Olson
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] request for comments?

2003-08-05 Thread Bernie Bright
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] request for comments?

2003-08-05 Thread Norman Vine
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