plib-devel

Re: [Plib-devel] I'm outta here.

[<Va...@t-...>]

"Curtis L. Olson" wrote:
> 
> > Hmmm - sounds like I should hold off installing my GeForce until I
> > get SuSE 6.4 and hope the new nVidia stuff is out by then.

And I've got only my 6.3 and have to 'post-install' XFree4.0 - as a
Linux newbi bwahah

> The most recent rumor I heard is that nvidia is not planning on using
> the XFree 4.0 / DRI infrastructure for their drivers ... they plan to
> forge their own path and do something else which no one is quite sure
> what, how, when, or why.  This is the rumor I heard.

I'm not reading the 'unofficial' sites with the rumors, but the official
nVidia Linux driver site
(http://www.nvidia.com/Products.nsf/htmlmedia/software_drivers.html)
says:

  ... The upcoming XFree86 X server 4.0 will use the Direct
  Rendering Infrastructure required to take full advantage of the
  RIVA processors. ...

This tells me that they'll use DRI. (Currently they aren't. But their
current drivers crash with even the most simplistic OpenGl applications
very badly)

CU,
Christian

RE: [Plib-devel] DXF load/save

[Dave M. <dp...@ef...>]

Here is a jumble of PLIB thoughts:

- The trivial alias/AC3D triangle import/export was omitted from
the loader/writer list.

- I got permission from the author of IVCON, John Burkardt, to use
his code in PLIB under LGPL

- For the loaders, would the following be wise:

	if ( glIsEnabled ( GL_LIGHTING ) )
	   load normal array
	else
	   load color array

That way, you only get the data you need.  Or are there some cases
which need both?  Or is there a different way to decide which is needed?
In my game, everything will be prelit so I will leave lighting disabled
and I don't need vertex normals.

- you can make a "really nice" skybox in 3DSMAX.
i would prefer that over a skydome.
multiple cloud bands moving in different directions and heights would be
great
simulating weather (rain,snow,storms with lightning) is needed.
i have some relevant code for this stuff once GLU/SSG-Util gets started.

- I should have ASE animation code commited by end of week

- Welcome back Steve and Happy St Patricks Day!  I hope everyone has
planted their potatoes in the northern hemisphere.

RE: [Plib-devel] ssg sky

[Norman V. <nh...@ca...>]

Curt wrote:
>
>I will be starting my new position in early april. 

Congrats !

Norman

Re: [Plib-devel] ssg sky

[Curtis L. O. <cu...@in...>]

Steve Baker writes:
> > Vehicle dynamics will be one big issue on my plate.  It would be great
> > to have something decent I could just use, but if not, I will make my
> > best effort to contribute whatever I have to write myself.
>
> I wasn't thinking of the full sophistication needed in a serious
> simulation - just something quick and dirty to let potential game
> developers get started quickly.
>
> Something like the code that the SGI Performer library provides for
> that kind of thing.

Sure ... we could save the sophisticated vehicle dynamics for another
library. :-)

> > For they sky, you need to feed in a top sky color and a horizon color.
>
> Is the horizon directional?  When the sun sets (for example), the sunset
> colour is most intense near to the point where the sun goes down.

Yes, you can specify an angle to rotate the sky so it can align with
the sun.  Again, the value of this rotation would be calculated
externally (and flight gear already contains the math to do this.)

> > This could be calculated by time, or sun angle with the horizon, or
> > you could just feed in random colors such as orange at the top and
> > purple at the horizon.
>
> MmmMmmmm - green and magenta skies.

I'd hate to not be able to accurately model your world Steve. :-)

> PLIB really needs a path generalization thingy - perhaps we should
> just suck that into the package too.
>
> However, for the textures you could just look in the ssg path or let
> the application tell you where they are.

Yup, that would work fine.  If you like, I'd be happy to move
FlightGear's path generalization code to plib ... or I could
contribute it as a starting point so you could "SteveBaker-ify" it.
As long as we could still accomplish the same basic things with it,
I'd be happy to use plib functionality for platform path independence.

I think this would definitely something that would fit well within the
scope of plib.

If you are interested I could send you some code.

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] ssg sky

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> > I imagine we're going to need to think in terms of an auxiliary library:
> > XXX is to SSG as GLU is to GL...where 'XXX' is this new thing.
> 
> That's good news, I'm glad you are interested in doing something like
> this.  I see two levels of things that might be useful ... a library
> of routines to build primitive objects ... spheres, cones, boxes,
> etc.  Something analogous to GLU.

Yep.

> Vehicle dynamics will be one big issue on my plate.  It would be great
> to have something decent I could just use, but if not, I will make my
> best effort to contribute whatever I have to write myself.

I wasn't thinking of the full sophistication needed in a serious
simulation - just something quick and dirty to let potential game
developers get started quickly.

Something like the code that the SGI Performer library provides for
that kind of thing.
 
> For they sky, you need to feed in a top sky color and a horizon color.

Is the horizon directional?  When the sun sets (for example), the sunset
colour is most intense near to the point where the sun goes down.

> This could be calculated by time, or sun angle with the horizon, or
> you could just feed in random colors such as orange at the top and
> purple at the horizon.

MmmMmmmm - green and magenta skies.

> I know the resistance to introducing additional packages and
> dependencies, but somehow things that get into modeling of the real
> world seem to me to be beyond the scope of plib.

Yes - I think so.  It's not so much that it's beyond the scope as
that PLIB is meant for games where the restrictions implied by
modelling the real world are frequently unacceptable.
 
> There may be some current simgear dependencies, but perhaps with a bit
> of thought, most if not all of these could be removed.  The big one
> that comes to mind is I use flight gear's mac/pc/unix path
> generalization class ... but this could be eliminated and I could just
> require the caller to provide the appropriate complete path to the
> files needed (two textures and a star database.)

PLIB really needs a path generalization thingy - perhaps we should
just suck that into the package too.

However, for the textures you could just look in the ssg path or let
the application tell you where they are.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] ssg sky

[Curtis L. O. <cu...@in...>]

Curt wrote:
> > > >
> > > > >     http://www.menet.umn.edu/~curt/tmp/tux-sky-demo.jpg
> > > > >
> > > > >I'm designing this in such a way that you can use a separate module
> > > > >that calculates the real positions of the sky objects so you can have
> > > > >a live dynamic sky that will precisely match the real world.

> Durk Talsma wrote:
> > > I'd certainly offer it up for potential inclusion in plib/ssg, but the
> > > decision would be up to Steve.

Steve Baker writes:
> I think it's very appropriate.
>
> I imagine we're going to need to think in terms of an auxiliary library:
> XXX is to SSG as GLU is to GL...where 'XXX' is this new thing.

That's good news, I'm glad you are interested in doing something like
this.  I see two levels of things that might be useful ... a library
of routines to build primitive objects ... spheres, cones, boxes,
etc.  Something analogous to GLU.

Then there could be higher level items such as a complete drop skies,
or drop in terrain renderers, or ... what else is there ... everyone
here is only interested in flight sims, right? :-)

> > > My interests are more simulation
> > > oriented rather than game oriented.
>
> There are less differences than you might expect.

Yup, lots of stuff that applies to both sides ...

> > >  I've been considering putting
> > > together my own package of things that would sit a level up from plib,
> > > or be out of the scope of plib ... things like a drop in sky, terrain
> > > rendering/paging tools, or even a collection of vehicle dynamics
> > > codes.
>
> 100% what I had in mind.  I've been thinking about extracting the
> 'walking/jumping/falling/sliding/swimming' code out of my Tux game
> and putting them into such a library.  Adding some *simple* flight
> math (nothing like as complex as flight gear) and some simple car
> driving dynamics would produce something that would let most wannabe
> games developers throw something together in very short order.

I will be starting my new position in early april.  I haven't made any
official announcement yet to the cyber community (not that it would be
of interest to that many people ...)

Vehicle dynamics will be one big issue on my plate.  It would be great
to have something decent I could just use, but if not, I will make my
best effort to contribute whatever I have to write myself.

> It's not a particularly easy choice.  I'd guess that most games would want
> to describe the colours of the sky in some detail (eg one of the Tux levels
> has a completely orange sky to give a feeling of opressive heat - there is
> no time of day I could feed into the top of that stack to get an orange
> sky).  I'd guess that they'd also want to specify the general local time
> of day though - but they wouldn't even care where the stars ended up.
>
> Disentangling those things sounds tricky since we need to cross layers.
>
> For my Tux game, I'd want direct control over the sky colour
> and some very simple interface (like local time of day) to set the
> sun/moon/stars.  I'd like to set the horizon colour(s) and the sky
> top colour directly - then say "8:00am" and have everything else
> 'do the right thing' at some default lat/long/date.

To understand my sky implimentation, imagine some contraptions where
you have complete control over the positions of everything, and it
starts out with everything dangling in a big heap.

For a game that doesn't care about accurate positioning of these
things, you can just pick any position that looks good for you (by
trial and error for instance.)

For they sky, you need to feed in a top sky color and a horizon color.

This could be calculated by time, or sun angle with the horizon, or
you could just feed in random colors such as orange at the top and
purple at the horizon.

> OTOH, I could imagine (say) a car racing game having a user-settable
> time of day so you could race at night, at dawn and at midday - and
> even have the time change dynamically like it does in FGFS.
>
> So, having the sky colours be 'right' for that time of day would
> be OK for some games - but definitely not for others.
>
> Only something like a flight sim would be likely to care about such
> subtle effects as lat/long and date on the look of the sky.

True, that is why I set up the sky so these things are completely
driven externally ... and I would expect that as soon as someone tries
to use this outside of flightgear, they'll send me a nice long list of
additional parameters they'd like to have control of.

> I'd be quite happy to include all the 'astronomy' code into PLIB since
> it's probably not actually very many lines of code - but exposing the
> appropriate interface to set sky colours and such like directly would
> be important - and it might be easier to do that by simply slicing off
> the 'astronomy/time' layers and exposing whatever is left sticking up
> as the API to the sky renderer.

I know the resistance to introducing additional packages and
dependencies, but somehow things that get into modeling of the real
world seem to me to be beyond the scope of plib.

> Some other random thoughts:
>
> * It would be cool to generalise the sky code to allow multiple moons
>   (games set on Mars perhaps) and multiple suns (games set on
>   Tattoine).

This would be easy ... although would involve some changes to the api.
Hmmm, multiple suns and moons ... that might make for some interesting
moon phase effects. :-)

> * What about clouds and how that ties into FGFS's weather
>   modules....ikky!

I would like to build cloud support directly into the sky model and
provide some api to specify multiple cloud layers, altitude,
thickness, density, random variation, sunrise/set effects, wind
effects, and probably a few other things, but I probably won't have
time to deal with this in the near future.

> * Does Curt's current sky code set SSG's light sources to the sun and/or
>   moon coordinates?

My code right now just builds the ssg structures and provides a
mechanism for orienting/placing them properly.  I set the light source
else where.

> Yes - me too!
>
> What I want to avoid at all costs is introducing more dependancies
> into games that use PLIB.  If Curt's new sky code is to be in some
> SSG-Utils library then it needs to depend only on SG/SSG and
> (possibly) other PLIB components.  I don't want people to have to
> download SimGear in order to get (say) Tux_AQFH to display
> stars/sun/moon.

There may be some current simgear dependencies, but perhaps with a bit
of thought, most if not all of these could be removed.  The big one
that comes to mind is I use flight gear's mac/pc/unix path
generalization class ... but this could be eliminated and I could just
require the caller to provide the appropriate complete path to the
files needed (two textures and a star database.)

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] Quaternion code changes/fixes.

[Steve B. <sjb...@ai...>]

I've just committed the changes to SG to fix all the known Quaternion
code and to change the parameters of the quaternion routines to take
an sgVec4 rather than a special structure.  This simplifies the code
in quite a few places.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] I'm outta here.

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> The current state of the nvidia utah-glx support is such that I'm
> about ready to go by a voodoo3 ...  the latest utah-glx stuff out of
> CVS is utterly broke for my TNT2 ... no textures, 0.5 fps, completely
> brings the machine to it's knees when rendering ... software only mesa
> *is* faster and much less disruptive to the machine.  I'm not a happy
> member of the nvidia band wagon right now.
> 
> If I didn't have to buy a new transmitter for my new R/C plane, I
> would have a voodoo3 in my hand right now.

Uck!  That's terrible.  I *hate* my Voodoo-3, I actually prefer the
Voodoo-2!  The trouble with the V3 is that because it drives the 2D
as well as the 3D, the 3D bits-per-pixel has to be the same as the
2D setting - which means that you have to have a sucky 16 bit 2D display
because the Voodoo engine can only do 16 bit 3D.  On the old V1 and V2,
the 3D hardware was completely unknown to the 2D stuff - so you could
get a decent 2D card and run it at 24 or 32 bpp and still get 3D accelleration.

The V3's pixel fill rate is hardly any better than a pair of V2's in SLI
mode - and it has hardly any other advantages.
 
> > > BTW: SuSE 6.4 (release date: end of this month) will come with XFree
> > > 4.0. But it won't be the default setting.
> >
> > Hmmm - sounds like I should hold off installing my GeForce until I
> > get SuSE 6.4 and hope the new nVidia stuff is out by then.
> 
> The most recent rumor I heard is that nvidia is not planning on using
> the XFree 4.0 / DRI infrastructure for their drivers ... they plan to
> forge their own path and do something else which no one is quite sure
> what, how, when, or why.  This is the rumor I heard.

One might speculate that their recent nuptuals with SGI may have had
an influence on that decision...but then being selected by M$ for the
Xbox hardware means that they'll be a pretty schitzophrenic organization.
 
      8-(

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] I'm outta here.

[Curtis L. O. <cu...@in...>]

Steve Baker writes:
> > ...but XFree4.0 is released and nVidia promised that their linux
> > drivers will be out very soon.
> > I really hope that they are more stable than the current ones!
>
> Indeed.  I have not heard great things about them - and even the nVidia
> web site is full of excuses and such.

The current state of the nvidia utah-glx support is such that I'm
about ready to go by a voodoo3 ...  the latest utah-glx stuff out of
CVS is utterly broke for my TNT2 ... no textures, 0.5 fps, completely
brings the machine to it's knees when rendering ... software only mesa
*is* faster and much less disruptive to the machine.  I'm not a happy
member of the nvidia band wagon right now.

If I didn't have to buy a new transmitter for my new R/C plane, I
would have a voodoo3 in my hand right now.

> > BTW: SuSE 6.4 (release date: end of this month) will come with XFree
> > 4.0. But it won't be the default setting.
>
> Hmmm - sounds like I should hold off installing my GeForce until I
> get SuSE 6.4 and hope the new nVidia stuff is out by then.

The most recent rumor I heard is that nvidia is not planning on using
the XFree 4.0 / DRI infrastructure for their drivers ... they plan to
forge their own path and do something else which no one is quite sure
what, how, when, or why.  This is the rumor I heard.

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] I'm outta here.

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:

> I don't know how much you are up-to-date due to your holiday...

Not at all.  The old 150MHz laptop I bought to take on vacation had
some problems (now fixed) so I took an enforced 2 week break from all
thing Internet-related.  Probably a good thing actually.

> ...but XFree4.0 is released and nVidia promised that their linux
> drivers will be out very soon.
> I really hope that they are more stable than the current ones!

Indeed.  I have not heard great things about them - and even the nVidia
web site is full of excuses and such.

> BTW: SuSE 6.4 (release date: end of this month) will come with XFree
> 4.0. But it won't be the default setting.

Hmmm - sounds like I should hold off installing my GeForce until I
get SuSE 6.4 and hope the new nVidia stuff is out by then.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] I'm outta here.

[<Va...@t-...>]

Steve Baker wrote:
> 
> Christian Mayer wrote:
> 
> > When you've handled that you'll have 2 little squares in your face and
> > you won't be motivated to install the GeForce you got (you did, didn't
> > you?)...
> 
> Yep - I have the GeForce (thanks KJ!)...now I just have to dig out the
> drivers, etc, etc.  

I don't know how much you are up-to-date due to your holiday, but
XFree4.0 is released and nVidia promised that their linux drivers will
be out very soon. 
I really hope that they are more stable than the current ones!

CU,
Christian

BTW: SuSE 6.4 (release date: end of this month) will come with XFree
4.0. But it won't be the default setting.

Re: [Plib-devel] Another stumper ...

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> I'm building two objects in ssg.  One uses:
> 
>     state->enable( GL_COLOR_MATERIAL );
>     state->setColourMaterial( GL_AMBIENT_AND_DIFFUSE );
> 
> The vertex colors are then provided via the ssgVertexColourArray.
> 
> The next object uses:
> 
>     state->enable( GL_COLOR_MATERIAL );
>     state->setColourMaterial( GL_DIFFUSE );
>     state->setMaterial( GL_AMBIENT, 0.0, 0.0, 0.0, 1.0 );
> 
> Note that the second object, the color_material function only applies
> to the diffuse component, and I explicitely set the ambient component
> to be black.
> 
> Now, when I draw my scene, it *appears* as if ssg's lazy state
> management gets confused and on subsequent rendering passes, doesn't
> properly set the AMBIENT back to all black for the second object.  If
> I register a call back for the leaf node and have it explicitely call:
> 
>     color = all black;
>     glMaterialfv ( GL_FRONT_AND_BACK, GL_AMBIENT, color ) ;
> 
> In this case the object is properly rendered.
> 
> Now to add to my confusion, I added some printf()'s to ssg to see when
> and where it calls:
> 
>     glMaterialfv ( GL_FRONT_AND_BACK, GL_AMBIENT, ambient_color ) ;
> 
> As best I can tell, ssg resets the ambient color to 1, 1, 1, 1 at the
> start of each rendering pass.  But, I do see it apparently trying to
> do the right thing and setting the ambient color back to 0, 0, 0, 1
> before rendering my second object, but for some reason this call
> doesn't appear to have an effect.  Like I said before, if I also
> "help" and make my own glMaterialfv() call in the object's predraw
> callback, everything starts to work.

I am totally brain-fried over this.  I've seen the same problem in
my own code - and the effect seems to vary from one OpenGL implementation
to another.

The problem seems to relate to the order of operations when enabling
glColorMaterial - or something like that.

I asked the Guru's on OpenGL-Gamedev to explain how this is *supposed*
to work - and it rapidly became apparrent that even amongst the people
who wrote the OpenGL spec, they don't 100% agree on what should happen
in some of the darker corners of the API.  Given that, it's not
entirely suprising that some OpenGL drivers get it wrong.

I've tried a variety of work-arounds - but whatever I do seems to
flake on some other driver.

IIRC, the coe of the misunderstanding is this:

  When you use glColorMaterial to tell opengl to use glColor to
set the current material colour, does it tell the renderer to use
the glColor colour for that component or does it tell the material
to change it's colour to whatever glColor says.

You may need to think about that distinction carefully.

This means that if you do something like:

   glMaterial ( ...AMBIENT...BLUE ) ;
   glColorMaterial ( ...AMBIENT... ) ;
   glEnable ( GL_COLOR_MATERIAL ) ;
   glColor ( RED ) ;  /* Set current ambient colour to RED. */
   glDisable ( GL_COLOR_MATERIAL ) ;
   draw something ;

...the resident guru's couldn't decide whether the current ambient
colour is:

* BLUE - because disabling the ColorMaterial means that
  the renderer switches to using the glMaterial colour - which
  was set to BLUE

* RED - because the glColor command changed the current material's
  ambient colour to RED and even though we've now disabled the
  ability to change the glMaterial colour future glColor commands.

Well, this is just one example of the mess we are in here.  IIRC,
it got deeper than that.

This stuff doesn't matter for most programs - but when you are
trying to use lazy evaluation of state change, it's a pain.

I think what's needed is to write some simple OpenGL test
programs and to try them on a variety of machines.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] I'm outta here.

[Steve B. <sjb...@ai...>]

Christian Mayer wrote:

> When you've handled that you'll have 2 little squares in your face and
> you won't be motivated to install the GeForce you got (you did, didn't
> you?)...

Yep - I have the GeForce (thanks KJ!)...now I just have to dig out the
drivers, etc, etc.  I'm now the proud owner of an ancient laptop that's
going to get the old Voodoo-1 card in it's docking station - so I'll have
a wider range of contraptions to test with.

> Oh, and I wish you that you got lots of SPAM as that can be 'answered'
> very efficiently :-)

Actually, amazingly little SPAM - all things considered.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] ssg Leaf call backs

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> It would be convenient to be able to attach pre/post draw call backs
> to branch nodes as well as leaf nodes.  ssg allows me to do this now,
> but it never calls the functions attached to branches, only leaf
> nodes.

The trouble is that leaf nodes are not rendered in order - even though
I don't (yet) sort by material property, I do render translucent leaf
nodes after all the opaque nodes.

Hence, if a branch node were to contain both translucent and opaque
leaves, there would be no good time to call the callbacks.

In future (when I get around to some material sorting), this would be
an even bigger problem.

> The alternative is to depend on the (?non-defined?) behavior that the
> first kid added to a branch is the first one processed during
> ssgCullandDraw().  This doesn't seem very satisfying or robust...
> especially if I later change the leaf nodes and forget to attach the
> call back to the first leaf.

It *definitely* doesn't work - even now - because of the transparency
thing - and even if you are getting away with it right now, I can
promise to break your code sometime in the future.
 
> Or we could be wasteful and attach the callback to every leaf node in
> a sub tree, but I'd rather not do that either, but it would be the
> safest I suppose.

Yep.  I guess that's what you need to do.  :-(
 
> These things would also need to be considered if you ever impliment
> state sorting ... yuk ... the callbacks could get out of sync with the
> leaf nodes being drawn!  Perhaps we could add some sort of marker node
> such that everything below a marker would be state sorted then drawn.
> Then you continue traversing/rendering the rest of the tree as before.

...or call the per-branch callbacks multiple times - once for each batch
of its child nodes.  That would be pretty ugly to implement.
 
> Right now the things I'm interested in doing with callbacks is to set
> blend modes and depth testing.  In some cases here it's just fine to
> set these on a per leaf basis, but in other cases it would be nice to
> be able to set these on a per-subtree basis.

Sounds like I need to dump those things into ssgState so that they can
be done without callbacks.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] DXF load/save

[Steve B. <sjb...@ai...>]

Dave McClurg wrote:
 
> I commited Wavefront OBJ import/export functions to PLIB/SSG
> They only handle geometry right now
> If someone can give me to a texture mapped OBJ model, i'll work on
> adding the texture support

Bill Weiland <bil...@ch...> said that he was working on an SSG
loader that would be ready "probably within the next few weeks"...dunno
what happened to that.

Bill - are you listening?

AFAIK, here is the current list of who is working on
what loader/writer-wise:

.ase : Author: Dave McClurg dp...@ef...
        IMPORT Status: 80% complete & functional
        EXPORT Status: complete
        Description: ASCII Export format of 3DSMAX.
        Todo: need to support mesh animations and sub materials fully
        but works well for most models

Dave says: I am interested in writing a VRML 1.0 ascii loader if that
  makes sense.  Anyone else  actively working on VRML support?  Does
  anyone have an issue with only supporting VRML 1.0 ascii ?
------------------------------------------------------------------------
.lwo: Leath Muller <le...@gb...>

       I am going to write a file importer for PLIB (Lightwave)
       but not an exporter yet... (file extension is .lwo)
       The code has been written already (for my modeller) I
       just have to convert it to PLIB.
------------------------------------------------------------------------
             "Christopher K. St. John" <cs...@qu...>

 I've got a partially finished VRML97 loader. However, VRML97 and
VRML 1.0 are different enough so that having two different loaders
is probably reasonable.
------------------------------------------------------------------------
.pov: Author: Christian Mayer <Va...@t-...>
      IMPORT Status: never - considered impossible
      EXPORT Status: started, but currently on hold while I'm trying
                     to figure out how to write a writer for SSG as
                     the example code that I used didn't work.
      Description:   PovRay is a well known freeware raytracer.
      Note:          You'll probably need at least MegaPov or the yet
                     to come PovRay 3.5 (=> I'll use mesh2)
------------------------------------------------------------------------
.obj: Author: Bill Weiland <bil...@ch...>
      IMPORT Status: "probably within the next few weeks"
      EXPORT Status: not yet?
   ...also...
      Author: Dave McClurg <dp...@ef...>
      IMPORT Status: Geometry only - no texture
      EXPORT Status: Geometry only - no texture
      Description:   OBJ is a fairly simple ASCII model format
                     exported by Wavefront.
------------------------------------------------------------------------
.ac : Author: Steve Baker <sjb...@ai...>
        IMPORT Status: 100% complete & functional
        EXPORT Status: none
        Description: ASCII Export format of AC3D.
------------------------------------------------------------------------
.ssg : Author: Steve Baker <sjb...@ai...> 
        IMPORT Status: 100% complete & functional
        EXPORT Status: 100% complete & functional
        Description: Native binary format for SSG - supported by PPE
------------------------------------------------------------------------
.dxf : Author: Dave McClurg <dp...@ef...>
        IMPORT Status: DXF lines and faces are both supported
        EXPORT Status: DXF lines and faces are both supported
------------------------------------------------------------------------

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] SLERP

[Steve B. <sjb...@ai...>]

Michael Kurth wrote:
> 
> I fixed a lot of mistakes in the Quaternion code and sent them to Steve. I
> suspect he put them into the CVS tree but I actually havent check up on him
> =)
> 
> I fixed errors in 3 functions and now everything works fine from what I can
> tell. I even sent Steve a demo of a quaternion camera. I'm not at home or
> I'd send the updates again but the essence was someone had
> 
> X*X + X*Y + Z*Z + W*W
> in two functions which should be Y*Y
> 
> And the mult function was REALLY off, but it appears from your message you
> found those mistakes.

I worked on the fixed up code - and fixed some other inconsistancies in
the SG library over my vacation - I should get a release out in the next
day or two - jetlag permitting  :-)

The SGD part of the library was getting sadly out of date compared to the
main SG functions and there were quite a few places where doubles were
being used in float functions and vice-versa.

Watch this space.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] ssg sky

[Steve B. <sjb...@ai...>]

Durk Talsma wrote:

> > > Curt wrote:
> > >
> > > >     http://www.menet.umn.edu/~curt/tmp/tux-sky-demo.jpg
> > > >
> > > >I'm designing this in such a way that you can use a separate module
> > > >that calculates the real positions of the sky objects so you can have
> > > >a live dynamic sky that will precisely match the real world.

> > I'd certainly offer it up for potential inclusion in plib/ssg, but the
> > decision would be up to Steve.

I think it's very appropriate.

I imagine we're going to need to think in terms of an auxiliary library:
XXX is to SSG as GLU is to GL...where 'XXX' is this new thing.

> > My interests are more simulation
> > oriented rather than game oriented.

There are less differences than you might expect.

> >  I've been considering putting
> > together my own package of things that would sit a level up from plib,
> > or be out of the scope of plib ... things like a drop in sky, terrain
> > rendering/paging tools, or even a collection of vehicle dynamics
> > codes.

100% what I had in mind.  I've been thinking about extracting the
'walking/jumping/falling/sliding/swimming' code out of my Tux game
and putting them into such a library.  Adding some *simple* flight
math (nothing like as complex as flight gear) and some simple car
driving dynamics would produce something that would let most wannabe
games developers throw something together in very short order.

> > I'm thinking it would be nice to have plib + my_package = getting your
> > simulation project off the ground quickly.

Yes.

> The code that calculates the right position of the sun, moon, and planets
> currently pretty much intertwined with the rest of FlightGear, and one of my
> intentions is to seperate this from the core of the simulator code.

Good.

> Because
> Astronomy and time code is pretty much intertwined, I'm currently thinking of
> reorganizing this into a single time/astromomy lib. Though I'm open to
> including this code in plib as well, I'm not sure if this is the right place
> for this lib to go.

I guess we have some layering here:

        date + local time + lat/long position
                       |
                       |
                       v
          universal time + lat/long position
                       |
                       |
                       v
            Position of sun/moon/stars
               and sky colours
                       |
                       |
                       v
             Correctly rendered sky

The issue here is where to slice the layer that we want to be in SSG-Utils,
and what part to leave behind into some other package - or in FGFS.

It's not a particularly easy choice.  I'd guess that most games would want
to describe the colours of the sky in some detail (eg one of the Tux levels
has a completely orange sky to give a feeling of opressive heat - there is
no time of day I could feed into the top of that stack to get an orange
sky).  I'd guess that they'd also want to specify the general local time
of day though - but they wouldn't even care where the stars ended up.

Disentangling those things sounds tricky since we need to cross layers.

For my Tux game, I'd want direct control over the sky colour
and some very simple interface (like local time of day) to set the
sun/moon/stars.  I'd like to set the horizon colour(s) and the sky
top colour directly - then say "8:00am" and have everything else
'do the right thing' at some default lat/long/date.

OTOH, I could imagine (say) a car racing game having a user-settable
time of day so you could race at night, at dawn and at midday - and
even have the time change dynamically like it does in FGFS.

So, having the sky colours be 'right' for that time of day would
be OK for some games - but definitely not for others.

Only something like a flight sim would be likely to care about such
subtle effects as lat/long and date on the look of the sky.

I'd be quite happy to include all the 'astronomy' code into PLIB since
it's probably not actually very many lines of code - but exposing the
appropriate interface to set sky colours and such like directly would
be important - and it might be easier to do that by simply slicing off
the 'astronomy/time' layers and exposing whatever is left sticking up
as the API to the sky renderer.

Some other random thoughts:

* It would be cool to generalise the sky code to allow multiple moons
  (games set on Mars perhaps) and multiple suns (games set on Tattoine).

* What about clouds and how that ties into FGFS's weather modules....ikky!

* Does Curt's current sky code set SSG's light sources to the sun and/or
  moon coordinates?

> Eventually, I'd like to develop some code that is also suitable for use in
> stuff like a Space Flight simulator, and this would impose an additional
> demand on the lib. My first choice in that case would be to include the
> Astronomy and Time code in something like Curt's SimGear lib. As said, I'm
> open to suggestion.

Yes - me too!

What I want to avoid at all costs is introducing more dependancies into
games that use PLIB.  If Curt's new sky code is to be in some SSG-Utils
library then it needs to depend only on SG/SSG and (possibly) other PLIB
components.  I don't want people to have to download SimGear in order
to get (say) Tux_AQFH to display stars/sun/moon.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] I'm outta here.

[<Va...@t-...>]

Welcome back!

Steve Baker wrote:
> 
> Steve Baker wrote:
> 
> >   I'm off on a much needed vacation for two weeks - so I'll basically
> > be uncontactable until about 18th March.
> 
> I'm back!  Unfortunately, there are now ~360 emails in my home mailbox
> and over 2,000 at work (eeekkk!) - so please bear with me as I wade
> through it all.

When you've handled that you'll have 2 little squares in your face and
you won't be motivated to install the GeForce you got (you did, didn't
you?)...

I wish you it won't be that drastic.

Oh, and I wish you that you got lots of SPAM as that can be 'answered'
very efficiently :-) 

CU,
Christian

Re: [Plib-devel] desperate plea for help (SKYBOX)

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> Right now I'm implimenting a sky dome (this is for a flight
> simulator.)  But it would be interesting to add a skybox option
> sometime as well.

This sounds like a way cool thing that ought to be distributed
with PLIB somehow since a large fraction of SSG programs must
need this kind of thing.  For example, my Tux game 'draws' the
sky with a simple screen clear - it would be cool if it could
have clouds and stars and stuff too - but not cool enough to
make me want to go out and write the code to do it!

If there were a simple couple-of-lines setup command to build
a sky and then a one line per-frame update command, it would
be something I could imagine nearly everyone using.

It seems somehow wrong to bloat the SSG core library with this
kind of thing - perhaps an SSG utility library is needed to collect
such useful things.

I've been having thoughts of playing with other handy 'utility'
modules such as the movement/collision code in Tux_AQFH.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] I'm outta here.

[Steve B. <sjb...@ai...>]

Steve Baker wrote:

>   I'm off on a much needed vacation for two weeks - so I'll basically
> be uncontactable until about 18th March.

I'm back!  Unfortunately, there are now ~360 emails in my home mailbox
and over 2,000 at work (eeekkk!) - so please bear with me as I wade
through it all.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] DXF load/save

[Dave M. <dp...@ef...>]

I commited Wavefront OBJ import/export functions to PLIB/SSG
They only handle geometry right now
If someone can give me to a texture mapped OBJ model, i'll work on adding the texture support

Re: [Plib-devel] import/export

[<Va...@t-...>]

Dave McClurg wrote:
> 
> > > looking at IVCON and AC3D,
> > > i'm trying to figure out what would be the most useful formats
> > > to add to PLIB next.  here are some quick and easy choices:
> > >
> > > - POV file "#version 3.0" EXPORT ONLY!
> > >
> > > i'm using IVCON because the code is pretty clean without alot
> > of dependencies
> > > and it will quickly allow PLIB to support more formats.
> >
> > Does the POV export support textures?
> nope. just basic geometry. it is pretty limited

OK, then I'll continue with my POV exporter - which needs MegaPov (an
unofficial version) or the yet to come POV 3.5

CU,
Christian

[Plib-devel] Another stumper ...

[Curtis L. O. <cu...@in...>]

Here's another weird one I'm running into.  

I realize that with opengl, that opening statement always has meant
I've done something stupid.  But in this case I'm wondering if I've
hit an untested path of ssg and have managed to confuse it's lazy
state management.  Or it could be I've hit a subtlety of ssg and have
failed to do something I should be doing.  At any rate, here's the
description of my problem.

Note, with the exception of the "work around" I list at the end, I'm
not making any opengl calls in my code ... everything is handled
through ssg mechanisms.  (Well, no opengl calls that should matter.
The opengl calls I am doing are stuck in call backs and dis/enable
depth testing and change the blend mode.  These cannot be done with
ssg's provided state management.)

I'm building two objects in ssg.  One uses:

    state->enable( GL_COLOR_MATERIAL );
    state->setColourMaterial( GL_AMBIENT_AND_DIFFUSE );

The vertex colors are then provided via the ssgVertexColourArray.

The next object uses:

    state->enable( GL_COLOR_MATERIAL );
    state->setColourMaterial( GL_DIFFUSE );
    state->setMaterial( GL_AMBIENT, 0.0, 0.0, 0.0, 1.0 );

Note that the second object, the color_material function only applies
to the diffuse component, and I explicitely set the ambient component
to be black.

Now, when I draw my scene, it *appears* as if ssg's lazy state
management gets confused and on subsequent rendering passes, doesn't
properly set the AMBIENT back to all black for the second object.  If
I register a call back for the leaf node and have it explicitely call:

    color = all black;
    glMaterialfv ( GL_FRONT_AND_BACK, GL_AMBIENT, color ) ;

In this case the object is properly rendered.

Now to add to my confusion, I added some printf()'s to ssg to see when
and where it calls:

    glMaterialfv ( GL_FRONT_AND_BACK, GL_AMBIENT, ambient_color ) ;

As best I can tell, ssg resets the ambient color to 1, 1, 1, 1 at the
start of each rendering pass.  But, I do see it apparently trying to
do the right thing and setting the ambient color back to 0, 0, 0, 1
before rendering my second object, but for some reason this call
doesn't appear to have an effect.  Like I said before, if I also
"help" and make my own glMaterialfv() call in the object's predraw
callback, everything starts to work.

I guess I'm not expecting any quick solution from anyone, especially
with Steve on vacation.  But I'm hoping that writing out my problem
will help me stumble on the solution ... but so far that hasn't
worked.  So the only thing left to do is actually fire off the letter.
Usually if I get this far, I discover right after posting what my
problem is.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] ssg Leaf call backs

[Curtis L. O. <cu...@in...>]

Steve,

Here's another one for you.

It would be convenient to be able to attach pre/post draw call backs
to branch nodes as well as leaf nodes.  ssg allows me to do this now,
but it never calls the functions attached to branches, only leaf
nodes.

Assuming you are doing a depth first traversal of the scene graph, it
would be nice if the predraw callback would be called when a branch is
first decended to, and the postdraw callback would be called after all
the "kids" have been processed (last thing on the way back out.)

The alternative is to depend on the (?non-defined?) behavior that the
first kid added to a branch is the first one processed during
ssgCullandDraw().  This doesn't seem very satisfying or robust...
especially if I later change the leaf nodes and forget to attach the
call back to the first leaf.

Or we could be wasteful and attach the callback to every leaf node in
a sub tree, but I'd rather not do that either, but it would be the
safest I suppose.

These things would also need to be considered if you ever impliment
state sorting ... yuk ... the callbacks could get out of sync with the
leaf nodes being drawn!  Perhaps we could add some sort of marker node
such that everything below a marker would be state sorted then drawn.
Then you continue traversing/rendering the rest of the tree as before.

Right now the things I'm interested in doing with callbacks is to set
blend modes and depth testing.  In some cases here it's just fine to
set these on a per leaf basis, but in other cases it would be nice to
be able to set these on a per-subtree basis.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] import/export

[Dave M. <dp...@ef...>]

> > looking at IVCON and AC3D,
> > i'm trying to figure out what would be the most useful formats
> > to add to PLIB next.  here are some quick and easy choices:
> > 
> > - POV file "#version 3.0" EXPORT ONLY!
> > 
> > i'm using IVCON because the code is pretty clean without alot 
> of dependencies
> > and it will quickly allow PLIB to support more formats.
> 
> Does the POV export support textures?
nope. just basic geometry. it is pretty limited

The only formats in IVCON that seem to deal with textures and
texture coords are:

- golgotha GMOD
- SoftImage HRC (Softimage 4D Creative Environment v3.00)
- Inventor V2.0 ascii  ( AC3D exports version 2.1 :( )

interested in any of these?