plib-devel

[Plib-devel] "setValuator" in PUI

[Fay J. F C. AAC/W. <joh...@eg...>]

I have been looking at the "setValuator" functions in the PUI part of PLIB.
It occurs to me that if the user calls "setValuator" with a pointer-to-float
argument and then calls it again with a pointer-to-integer argument, he will
get some strange results.  Specifically, his integer variable will be
overwritten with the integer equivalent of his floating-point variable, both
immediately and whenever "getValue" is called.
 
First question:  is this a problem?  Ideally the user would be careful
enough to know what's going on.  I'm hard pressed to think of any
circumstances where this behavior is desirable.
 
If the answer is yes, this is a problem, then I suggest that we modify the
"setValuator" functions (pu.h, line 390 or so) as follows:
  void setValuator ( int   *i ) { res_integer = i ; res_floater = NULL ;
res_string = NULL ; re_eval () ; }
  void setValuator ( float *f ) { res_integer = NULL ; res_floater = f ;
res_string = NULL ; re_eval () ; }
  void setValuator ( char  *s ) { res_integer = NULL ; res_floater = NULL ;
res_string  = s ; re_eval () ; }
 

John F. Fay 
joh...@eg... 

RE: [Plib-devel] ssgBranch with pre and post draw callbacks

[Dave M. <Dav...@dy...>]

Thanks. The change is commited to CVS

-- Dave McClurg
mailto:dp...@ef...
http://mcdave.cjb.net


> Hello,
> 
> I have a small modification to submit for plib-ssg. This consists in
> allowing the call of the pre and post draw callbacks for branches and
> not only for leaves.
> 
> I use this in TORCS to modify parameters not managed by 
> ssgSimpleState,
> but from an object point of vue, because when an object is 
> loaded from a
> modeler, it is painful to traverse the sub-tree for adding redundant
> pre and post callbacks to all the leaves.
> 
> Here are the modifications:
> 
> file ssgBranch.cxx:
> 
> void ssgBranch::cull ( sgFrustum *f, sgMat4 m, int test_needed )
> {
>   int cull_result = cull_test ( f, m, test_needed ) ;
> 
>   if ( cull_result == SSG_OUTSIDE )
>     return ;
> 
>   for ( ssgEntity *e = getKid ( 0 ) ; e != NULL ; e = getNextKid() )
>     e -> cull ( f, m, cull_result != SSG_INSIDE ) ;
> }
> 
> becomes:
> 
> void ssgBranch::cull ( sgFrustum *f, sgMat4 m, int test_needed )
> {
>     int cull_result = cull_test ( f, m, test_needed ) ;
>     
>     if ( cull_result == SSG_OUTSIDE )
> 	return ;
> 	    
>     if ( preDrawCB != NULL && ! (*preDrawCB)(this) )
> 	return ;
> 	    
>     for ( ssgEntity *e = getKid ( 0 ) ; e != NULL ; e = getNextKid() )
> 	e -> cull ( f, m, cull_result != SSG_INSIDE ) ;
> 	    
>     if ( postDrawCB != NULL )
> 	(*postDrawCB)(this) ;
> }
> 
> For the current version I use a derived version of ssgBranch to manage
> the GL_TEXTURE_GEN_[ST] states for env mapping and the glTexEnvf calls
> to display the textures in different manners.
> 
> Eric.
> --
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> 
>                        TORCS
>             The Open Racing Car Simulator
>                  http://torcs.org
> 
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] ssgBranch with pre and post draw callbacks

[Eric E. <Eri...@fr...>]

Hello,

I have a small modification to submit for plib-ssg. This consists in
allowing the call of the pre and post draw callbacks for branches and
not only for leaves.

I use this in TORCS to modify parameters not managed by ssgSimpleState,
but from an object point of vue, because when an object is loaded from a
modeler, it is painful to traverse the sub-tree for adding redundant
pre and post callbacks to all the leaves.

Here are the modifications:

file ssgBranch.cxx:

void ssgBranch::cull ( sgFrustum *f, sgMat4 m, int test_needed )
{
  int cull_result = cull_test ( f, m, test_needed ) ;

  if ( cull_result == SSG_OUTSIDE )
    return ;

  for ( ssgEntity *e = getKid ( 0 ) ; e != NULL ; e = getNextKid() )
    e -> cull ( f, m, cull_result != SSG_INSIDE ) ;
}

becomes:

void ssgBranch::cull ( sgFrustum *f, sgMat4 m, int test_needed )
{
    int cull_result = cull_test ( f, m, test_needed ) ;
    
    if ( cull_result == SSG_OUTSIDE )
	return ;
	    
    if ( preDrawCB != NULL && ! (*preDrawCB)(this) )
	return ;
	    
    for ( ssgEntity *e = getKid ( 0 ) ; e != NULL ; e = getNextKid() )
	e -> cull ( f, m, cull_result != SSG_INSIDE ) ;
	    
    if ( postDrawCB != NULL )
	(*postDrawCB)(this) ;
}

For the current version I use a derived version of ssgBranch to manage
the GL_TEXTURE_GEN_[ST] states for env mapping and the glTexEnvf calls
to display the textures in different manners.

Eric.
--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

RE: [Plib-devel] Networking and TODO

[Dave M. <Dav...@dy...>]

the PLIBTODO file you made is helpful. i'll be getting involved after i hit
a milestone at work. good luck on the networking.

--Dave

> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...]On Behalf Of 
> Ben Woodhead
> Sent: Friday, August 25, 2000 9:18 AM
> To: 'pli...@li...'
> Subject: [Plib-devel] Networking and TODO
> 
> 
> Hello Everybody
> 
> I just thought I would check to see if anybody had a chance 
> to look at the
> networking code and the todo list.
> 
> Later Ben
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] NetWorking and SDL

[Ben W. <be...@bg...>]

Hello Everybody

I thought I would mention that I have been talking with Roy from SDL_net and
he is going to help me implement the Networking code, and I am still working
on the code, just been a painfull process so I have started over serveral
time.

Later Ben

Re: [Plib-devel] texture repeating

[Gil C. <g.c...@ca...>]

At 07:54 AM 8/25/00 -0500, Steve Baker wrote:
<snip>

> > Would anisotropic texturing help Curt's problems in Flightgear?
>
>Yes - it would help the 'texture going fuzzy on approach' problem...although
>whether it's worth the effort *just* for the nVidia cards....?

Good point.

I've done a little searching around, and discovered that anisotropic 
filtering is also supported by the ATI Radeon and Matrox G400 (and 
presumably on the upcoming G800).  It's not on the Voodoos or TNT/TNT2 or 
the Rage series, so it's definitely not going to be something everybody can 
use.

Gil

Re: [Plib-devel] OpenAL/plib

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

Alexander Rawass wrote:

> > On a modern machine, we could easily wipe out the 3 sound limit - and
> > increase it to (say) 32 simultaneous sounds.
> 
> You should do that - there are many people owning a very faster computer
> now.

I know it - but it's a matter of time - I don't have enough time to write
all this cool new stuff.

> But you should also care, that the end-user can run it on his old 486 as
> well - maybe by telling plibsl something like export PLIBSL_MAX_VOICES=3
> to hear only the 3 loudest sounds.

Yep.  SL already has the code to prioritize sounds (not necessarily the
loudest - the application gets to set the priorities.
 
> You mentioned OpenAL before, I didn't have time to look at it, but some
> day I've got to go to get a better Soundsystem for my game (I really need
> full 2D/3D here).

That's what OpenAL does.

> In my game, every object is (will be) one or more sound sources, the
> sound-handler knows about the positions of sound source and hearer in space
> and can therefore be calctulated, how loud the sound is and the balance between
> left/right (in 2D) or even more loudspeakers.

OpenAL does all that too.  If we added 'sound nodes' into the SSG API, you
wouldn't need to do *anything* in your game - you'd get range-dependent
volume, 3D spatialisation *and* doppler shift without writing a single line
of code.

> I intended to call an update routine like
>         update_sound(soundobject,soundobject_position,hearer_position)
> every frame, that sets balance and volume new, but including that in a
> ssg
> node would 'come more natural'. That would be really clever.

Yep...although I can't claim credit for the idea - it's been done
many times before.


-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[Plib-devel] OpenAL/plib

[Alexander R. <a_r...@in...>]

Hi,

Steve Baker wrote:
> 
> I wrote SL on a 66MHz 486 - three sounds mixed, with dynamic pitch AND
> volume envelopes seemed like a reasonable limit back then.
> 
> On a modern machine, we could easily wipe out the 3 sound limit - and
> increase it to (say) 32 simultaneous sounds.

You should do that - there are many people owning a very faster computer
now.
But you should also care, that the end-user can run it on his old 486 as
well - maybe by telling plibsl something like export PLIBSL_MAX_VOICES=3
to hear only the 3 loudest sounds.

> You *could* also hook into direct sound - or other sound API's - but there
> doesn't seem much point in doing that unless you want some of the REALLY
> fancy features like 3D sound.  If you are interested in that stuff then
> I recommend that you look at OpenAL instead of SL.
> 
> I'm somewhat tempted to abandon the current SL - re-implementing it as
> a thin layer on top of OpenAL just to allow continued support of existing
> applications. Then we could do cool things like embedding OpenAL sound
> sources as nodes in the SSG scene graph. Then you'd get automatically
> positioned 3D sound...but I just don't have the time these days.

You mentioned OpenAL before, I didn't have time to look at it, but some
day
I've got to go to get a better Soundsystem for my game (I really need
full
2D/3D here).

In my game, every object is (will be) one or more sound sources, the
sound-
handler knows about the positions of sound source and hearer in space
and can
therefore be calctulated, how loud the sound is and the balance between
left/right (in 2D) or even more loudspeakers.

I intended to call an update routine like
	update_sound(soundobject,soundobject_position,hearer_position)
every frame, that sets balance and volume new, but including that in a
ssg
node would 'come more natural'. That would be really clever.

Well - if not someone gives me a better soundsystem I can use, I have
do it for myself, getting OpenAL and using that in my game - but after
that, I probably know enough about OpenAL to put it into plib - if
someone helps me, if not someone other does it before.

But it will probably take some months until I want to do on the
Sound-System.


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-devel] texture repeating

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

Steve Baker writes:
> Old Evans&Sutherland image generators didn't have MIPmapping and used
> 'contrast clamping' to manage aliasing - it didn't work all that well,
> but it was certainly better than doing nothing.  They altered the texture
> contrast as a function of range and orientation.
> 
> I'm not sure that helps.

I might have to just say runway markings are going to suck in the
short term until you buy better hardware ...

> > Would you like the changes for ssg anyway ... they are pretty minimal ...
> 
> Yes please.

Ok, here they are ... I don't have cvs write access but the changes
are very short so I'll just post them here:

curt@lilith$ diff -cr plib-1.2.0/src/ssg/ plib-1.2.0-new/src/ssg/ 
diff -cr plib-1.2.0/src/ssg/ssg.h plib-1.2.0-new/src/ssg/ssg.h
*** plib-1.2.0/src/ssg/ssg.h    Tue Jun 27 20:34:04 2000
--- plib-1.2.0-new/src/ssg/ssg.h        Fri Aug 25 12:31:16 2000
***************
*** 442,448 ****
  public:
  
    virtual ssgBase *clone ( int clone_flags = 0 ) ;
!   ssgTexture ( char *fname, int wrapu = TRUE, int wrapv = TRUE )
    {
  #ifdef GL_VERSION_1_1
      glGenTextures ( 1, & handle ) ;
--- 442,449 ----
  public:
  
    virtual ssgBase *clone ( int clone_flags = 0 ) ;
!   ssgTexture ( char *fname, int wrapu = TRUE, int wrapv = TRUE,
!              int mipmap = TRUE )
    {
  #ifdef GL_VERSION_1_1
      glGenTextures ( 1, & handle ) ;
***************
*** 463,470 ****
      glTexEnvi ( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE ) ;
  
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR ) ;
!     glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,
!                                               GL_LINEAR_MIPMAP_LINEAR ) ;
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, wrapu ? GL_REPEAT : GL_CLAMP ) ;
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, wrapv ? GL_REPEAT : GL_CLAMP ) ;
  #ifdef GL_VERSION_1_1
--- 464,470 ----
      glTexEnvi ( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE ) ;
  
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR ) ;
!     glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, mipmap ? GL_LINEAR_MIPMAP_LINEAR : GL_LINEAR ) ;
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, wrapu ? GL_REPEAT : GL_CLAMP ) ;
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, wrapv ? GL_REPEAT : GL_CLAMP ) ;
  #ifdef GL_VERSION_1_1
***************
*** 535,540 ****
--- 535,541 ----
    char  *filename  ;
    int    wrapu ;
    int    wrapv ;
+   int    mipmap ;
  
    int colour_material_mode ;
    sgVec4 specular_colour ;
***************
*** 576,582 ****
    virtual void  setTextureFilename ( char *fname ) ;
    virtual void  setTexture ( char *fname,
                               int _wrapu = TRUE,
!                              int _wrapv = TRUE ) ;
  
    virtual GLuint getTextureHandle (void)
    {
--- 577,584 ----
    virtual void  setTextureFilename ( char *fname ) ;
    virtual void  setTexture ( char *fname,
                               int _wrapu = TRUE,
!                              int _wrapv = TRUE,
!                            int _mipmap = TRUE ) ;
  
    virtual GLuint getTextureHandle (void)
    {
***************
*** 718,724 ****
    char *getTextureFilename(void) ;
    void  setTextureFilename(char *fname) ;
  
!   void   setTexture ( char *fname, int _wrapu = TRUE, int _wrapv = TRUE ) ;
    GLuint getTextureHandle (void)   ; 
    void   setTexture ( ssgTexture *tex ) ; 
  
--- 720,727 ----
    char *getTextureFilename(void) ;
    void  setTextureFilename(char *fname) ;
  
!   void   setTexture ( char *fname, int _wrapu = TRUE, int _wrapv = TRUE,
!                     int _mipmap = TRUE ) ;
    GLuint getTextureHandle (void)   ; 
    void   setTexture ( ssgTexture *tex ) ; 
  
diff -cr plib-1.2.0/src/ssg/ssgSimpleState.cxx plib-1.2.0-new/src/ssg/ssgSimpleState.cxx
*** plib-1.2.0/src/ssg/ssgSimpleState.cxx       Fri Apr 28 00:51:06 2000
--- plib-1.2.0-new/src/ssg/ssgSimpleState.cxx   Fri Aug 25 12:31:02 2000
***************
*** 439,448 ****
    }
  }
  
! void ssgSimpleState::setTexture ( char *fname, int _wrapu, int _wrapv )
  {
!   wrapu = _wrapu ; wrapv = _wrapv ;
!   ssgTexture *tex = new ssgTexture ( fname, wrapu, wrapv ) ;
    setTexture ( tex ) ;
    delete tex ;
  }
--- 439,449 ----
    }
  }
  
! void ssgSimpleState::setTexture ( char *fname, int _wrapu, int _wrapv,
!                                 int _mipmap )
  {
!   wrapu = _wrapu ; wrapv = _wrapv ; mipmap = _mipmap ;
!   ssgTexture *tex = new ssgTexture ( fname, wrapu, wrapv, mipmap ) ;
    setTexture ( tex ) ;
    delete tex ;
  }
diff -cr plib-1.2.0/src/ssg/ssgStateSelector.cxx plib-1.2.0-new/src/ssg/ssgStateSelector.cxx
*** plib-1.2.0/src/ssg/ssgStateSelector.cxx     Fri Apr 28 00:51:12 2000
--- plib-1.2.0-new/src/ssg/ssgStateSelector.cxx Fri Aug 25 12:32:52 2000
***************
*** 125,133 ****
  }
  
  
! void ssgStateSelector::setTexture ( char *fname, int _wrapu, int _wrapv )
  {
!   getCurrentStep()->setTexture ( fname, _wrapu, _wrapv ) ;
  }
  
  char *ssgStateSelector::getTextureFilename (void)  
--- 125,134 ----
  }
  
  
! void ssgStateSelector::setTexture ( char *fname, int _wrapu, int _wrapv,
!                                   int _mipmap )
  {
!   getCurrentStep()->setTexture ( fname, _wrapu, _wrapv, _mipmap ) ;
  }
  
  char *ssgStateSelector::getTextureFilename (void)  


Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] Re: KobayashiMaru & plib

[Alexander R. <a_r...@in...>]

Hi,

Sam Stickland wrote:
> 
> I'm working on a similar game to KobayashiMaru myself, but I understand the technical challenges involved and I don't expect to ever
> fully complete the project.

I'd really would like to see more of your project - but I have to get it
running first on my system before I can start contributing :-)

> I'm tackling it in stages, creating the neccessary technology at each stage to

Like me.

> complete those goals.  So to begin with I have a
> straight up space-shooter (and this has taken me long enough! :).

Like me.

> I'm currently in the process of taking the network code from this and rewriting it into a separate generic library (something I
> should had done from the start, but hey, we live and learn).  The network library (to my surprise), is turning out to be quite
> 
> The network library shields all the nasty dead-reckoning, time-sync, latency and path extropolation problems at it's highest level.

My game is designed - in the back of my head - to be net/multiplayer.
At present, you won't find anything in the code, but it can be easily
put in.

But I have never opened a socket myself, so I'd really like not to use
the
libc-functions directly, but rather use a network library that does all
the stuff I don't know about (yet).

> This isn't fantasy.  I have this code base working, and I'll have small programs to demonstrate the library ready in the coming
> months (starting with network Pong! and getting more complex).

So, I'd really probably like to use your network-code, or ACE, or
whatever, as
long as it's easy-to-use.
Just gimme.

> Now, this is only a very tiny part of what a game like KobayashiMaru would need to achieve - and this has taken me 18 months to get
> this far. :)

EEEK!

> When the network library is fully debugged, I plan on adding a basic trading mechanism to SpaceThing - and the amount of spare time

This is something I wouldn't want to do for KobayashiMaru, cause I don't
like
that trading stuff, but I wouldn't mind if someone else would program it
(optionally).

Even better - keep the trading stuff separated from the space
fight/flight stuff,
and maybe I could simply put that in my game, too.

> I have at the moment (maybe I'll have to stay in more), this will be a while.  After that I need to add a persistant database to the
> server-side of the network library.  God knows how long that will take!
> 
> >From my point of view it's a bit of fun, and I get nice side programs at every stage - even it is shitty Pong! :)

Show me!


Alex


-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-devel] texture repeating

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

"Curtis L. Olson" wrote:
> 
> Steve Baker writes:
> > Yep - an aliasing nightmare - I don't regard that as an acceptable
> > solution.  Aliasing is *evil*.
> 
> Ok, I made the appropriate changes to ssg, but I agree, this sort of
> aliasing is evil ... I could reduce the effects by lowering the
> contrast of markings vs. surface but yuck ...

Old Evans&Sutherland image generators didn't have MIPmapping and used
'contrast clamping' to manage aliasing - it didn't work all that well,
but it was certainly better than doing nothing.  They altered the texture
contrast as a function of range and orientation.

I'm not sure that helps.

> Would you like the changes for ssg anyway ... they are pretty minimal ...

Yes please.
 
> Ok, I'm offering if you want the changes, but you are right ... the
> results in this case are not acceptable.

There *are* cases where disabling MIPmapping and linear-blending is
useful though (the Icons on the bottom of the TuxKart screen and
the text in PLIB/FNT are two examples).

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] texture repeating

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

Amit Bakshi wrote:
> 
> > Just for fun, is there an easy way to turn off mipmap generation in
> > ssg?  Perhaps for lower end cards I could just give the user a chance
> > to choose their poison ...

> I was under the impression that mipmapping does in fact speed up
> the rasterization of "far away" textured objects.

That's true under certain circumstances.

However, GL_LINEAR_MIPMAP_LINEAR requires you to read EIGHT texels
for every pixel on the screen where GL_NEAREST requires only one -
and perhaps the cache benefit vanishes under those circumstances...
so it depends somewhat on which mode you pick.

Anyway, Curt's concern is more as a way to try to control
the blurriness that's evident with MIPmapping of polygons that are
edge on - and which have strong features in the direction of foreshortening.

> This is due to the cache
> misses a full size texture would have when the texel/pixel ration gets high.

Yes - exactly.  The smaller MIPmaps come closer to fitting into the texture
hardware's cache.  For some devices (eg the Intel I810 cards that store
textures in main memory and fetch them via AGP) the effect is dramatic -
for others (like the older Voodoo's that don't have texture cache), there
is no effect.

> In fact you'll see some drivers that auto-generate mipmapped textures
> agains your will ( some NVidia drivers do/did that under Win32 ).

Hmmm - that's unacceptable IMHO.
 
-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [Plib-devel] texture repeating

[Ben W. <be...@bg...>]

> -----Original Message-----
> From: Amit Bakshi [mailto:am...@de...]
> Sent: Friday, August 25, 2000 2:32 PM
> To: pli...@li...
> Subject: Re: [Plib-devel] texture repeating
> 
> 
> > Just for fun, is there an easy way to turn off mipmap generation in
> > ssg?  Perhaps for lower end cards I could just give the 
> user a chance
> > to choose their poison ...
> > 
> > Curt.
> 
> Curt,
> 
> I was under the impression that mipmapping does in fact speed up
> the rasterization of "far away" textured objects. This is due 
> to the cache
> misses a full size texture would have when the texel/pixel 
> ration gets high.
> In fact you'll see some drivers that auto-generate mipmapped textures
> agains your will ( some NVidia drivers do/did that under Win32 ).
> 

My Impressions of this where a little different. Mipmapping is suppost to
improve rastorizing speed but I don't think for the same reason you are
talking about. Mipmapping generally uses more cache because it has several
version of the image, although usually stored in system memory and where
this speed increase is, is on the bus, Now you are transfering less data
accross the bus, and usually that is where most of the limitations come for
these days. That is why the new ATI cards have a compression algorithm for
the bus, and in 1600x1200, I have seen bench marks that have even surpased
different geforce cards.

Later Ben

Re: [Plib-devel] texture repeating

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

Steve Baker writes:
> Yep - an aliasing nightmare - I don't regard that as an acceptable
> solution.  Aliasing is *evil*.

Ok, I made the appropriate changes to ssg, but I agree, this sort of
aliasing is evil ... I could reduce the effects by lowering the
contrast of markings vs. surface but yuck ...

Would you like the changes for ssg anyway ... they are pretty minimal ...

> Sure - this is like the discussion we had the other day about changing
> texture parameters.
> 
> Any of these shoulf work:
> 
>   * Add it into ssgTexture and offer it back as an SSG enhancement.
> 
> I don't think you'll like the results though.

Ok, I'm offering if you want the changes, but you are right ... the
results in this case are not acceptable.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] texture repeating

[Amit B. <am...@de...>]

> Just for fun, is there an easy way to turn off mipmap generation in
> ssg?  Perhaps for lower end cards I could just give the user a chance
> to choose their poison ...
> 
> Curt.

Curt,

I was under the impression that mipmapping does in fact speed up
the rasterization of "far away" textured objects. This is due to the cache
misses a full size texture would have when the texel/pixel ration gets high.
In fact you'll see some drivers that auto-generate mipmapped textures
agains your will ( some NVidia drivers do/did that under Win32 ).

Re: [Plib-devel] texture repeating

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

"Curtis L. Olson" wrote:

> I notice that the X-Plane flight sim (www.x-plane.com) gets around the
> mipmap bluring problem by completely turning mipmapping off.  The
> tradeoff is the class pixel mishmash ...

Yep - an aliasing nightmare - I don't regard that as an acceptable
solution.  Aliasing is *evil*.
 
> Just for fun, is there an easy way to turn off mipmap generation in
> ssg?  Perhaps for lower end cards I could just give the user a chance
> to choose their poison ...

Sure - this is like the discussion we had the other day about changing
texture parameters.

Any of these shoulf work:

  * Create the texture yourself - pass the GL texture handle to ssgState,
    since the filter mode *is* a part of the binding, it'll be set
    how you need.

  * Let SSG load an ssgTexture - then do an 'apply' of the ssgState
    (so the texture will be the currently bound one) - change the
    glTexParameteri - and it'll stay changed when the ssgState is
    re-applied...or just:

      ssgTexture *tx = new ssgTexture ( "whatever.rgb" ) ;
      glBindTexture   ( GL_TEXTURE_2D, tx->getHandle() ) ;
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR ) ;
      glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR ) ;
      glBindTexture   ( GL_TEXTURE_2D, 0 ) ;

  * Write a derived class of ssgTexture that sets different glTexParameters.

  * Add it into ssgTexture and offer it back as an SSG enhancement.

I don't think you'll like the results though.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

[Plib-devel] Networking and TODO

[Ben W. <be...@bg...>]

Hello Everybody

I just thought I would check to see if anybody had a chance to look at the
networking code and the todo list.

Later Ben

Re: [Plib-devel] texture repeating

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

Steve Baker writes:
> Yes - hence my comment about the applicability of RIPmapping.  That's the
> simplest form of anisotropic mapping - and it would be pretty easy
> to implement on modern 3D hardware (but AFAIK, they are NOT
> currently designed to do that...although Cass's paper suggests that
> maybe nVidia DO have the relevent hardware).
> 
> Angus' implementation is also in OpenGL - but entails picking the appropriate
> map in realtime.
> 
> There are other (and better) ways to do anisotropic mapping - but all the
> other alternatives (that I'm aware of) do very bad things to pixel fill
> rates. But it's all rather academic - these things are not implemented - so
> we are somewhat screwed.
> 
> > Would anisotropic texturing help Curt's problems in Flightgear?
> 
> Yes - it would help the 'texture going fuzzy on approach' problem...although
> whether it's worth the effort *just* for the nVidia cards....?

Steve,

I notice that the X-Plane flight sim (www.x-plane.com) gets around the
mipmap bluring problem by completely turning mipmapping off.  The
tradeoff is the class pixel mishmash ...

Just for fun, is there an easy way to turn off mipmap generation in
ssg?  Perhaps for lower end cards I could just give the user a chance
to choose their poison ...

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] texture repeating

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

Gil Carter wrote:
> 
> At 11:53 PM 8/24/00 -0500, Steve wrote:
> 
> <snip>
> 
> >At work, we don't use texture for runway markings - but in the absence
> >of antialiased polygon edges, you don't have a whole lot of choice...
> >although I've been playing with antialiasing on the GeForce cards - and
> >it looks pretty good...*almost* identical to SGI's ONYX in quality -
> >perhaps even slightly better at some angles.
> 
> A chance for me to pick Steve's brains :-)
> 
> Runways are the classic application for anisotropic texture mapping aren't
> they?  Angus Dorbie's demos for Performer show it pretty nicely at
> http://www.sgi.com/software/performer/brew/anisotropic.html

Yes - hence my comment about the applicability of RIPmapping.  That's the
simplest form of anisotropic mapping - and it would be pretty easy to implement
on modern 3D hardware (but AFAIK, they are NOT currently designed to do
that...although Cass's paper suggests that maybe nVidia DO have the relevent
hardware).

Angus' implementation is also in OpenGL - but entails picking the appropriate
map in realtime.

There are other (and better) ways to do anisotropic mapping - but all the
other alternatives (that I'm aware of) do very bad things to pixel fill
rates. But it's all rather academic - these things are not implemented - so
we are somewhat screwed.

> Would anisotropic texturing help Curt's problems in Flightgear?

Yes - it would help the 'texture going fuzzy on approach' problem...although
whether it's worth the effort *just* for the nVidia cards....?


-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] texture repeating

[Gil C. <g.c...@ca...>]

At 11:53 PM 8/24/00 -0500, Steve wrote:

<snip>

>At work, we don't use texture for runway markings - but in the absence
>of antialiased polygon edges, you don't have a whole lot of choice...
>although I've been playing with antialiasing on the GeForce cards - and
>it looks pretty good...*almost* identical to SGI's ONYX in quality -
>perhaps even slightly better at some angles.

A chance for me to pick Steve's brains :-)

Runways are the classic application for anisotropic texture mapping aren't 
they?  Angus Dorbie's demos for Performer show it pretty nicely at 
http://www.sgi.com/software/performer/brew/anisotropic.html

Interestingly, Cass Everitt from nVidia has recently posted a whitepaper on 
anisotropic texture mapping in OpenGL (in MS Word format of course...) at:

http://www.nvidia.com/Marketing/Developer/DevRel.nsf/bookmark/9944854B211F6FC98825691F005C7EEF

plus a simple demo showing GL_EXT_texture_filter_anisotropic on nVidia 
hardware.  Source is available, and I think it's just a GLUT application so 
it might build under Linux.

Would anisotropic texturing help Curt's problems in Flightgear?

Thanks,

Gil

Re: [Plib-devel] texture repeating

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

"Curtis L. Olson" wrote:

> Yes, setting the wrapu / wrapv to FALSE totally fixed this particular
> problem.

Good!

>  But it didn't help with the mipmap bluring when viewing my
> runways from edge on ... or the problem where different sections of
> the runway with different textures can't always have the same ft/pixel
> ratio so the mipmapping choices don't always blend nicely from one
> section to the next.
> 
> Runways are hard to get looking nice ... :-(

Yep.  The most critical object in the scene - drawn at the worst
possible angle at a place in the scene where the polygon count is
largest and where we can least tolerate poor frame rates. Then the
white lines on black tarmac are the highest contrast thing in the
scene and the thin side-stripes are most inclined to alias.

It would be hard to pick a nastier case.

At work, we don't use texture for runway markings - but in the absence
of antialiased polygon edges, you don't have a whole lot of choice...
although I've been playing with antialiasing on the GeForce cards - and
it looks pretty good...*almost* identical to SGI's ONYX in quality -
perhaps even slightly better at some angles.

> FYI, here's what I've got so far (as viewed from a mipmap friendly
> vantage point)
> 
>     http://www.menet.umn.edu/~curt/fgfs/Gallery/Link/kmsp-runway.html

I would add a tarmac-to-grass blend into the texture at the edges of the
runway to avoid the polygon aliasing along the outer edges of the white
stripes.

> > Joining two textures is a harder problem...for which I wrote a FAQ:
> >    http://web2.airmail.net/sjbaker1/tiling_textures.html
> 
> It's probably obvious to everyone (and now to myself as well) that you
> also need to have a consistant ft/pixel ratio along the edge you are
> matching... this could be something worth mentioning in the FAQ.

I guess - I kinda thought it was obvious - but it's hard to argue that
ANYTHING is obvious in a FAQ answer.

> > It's all rather disappointing for the purist though.
> 
> This whole mipmapping scheme sucks for edge on runways which is the
> view you see them at 95% of the time ... generating "squat" textures
> (more resolution cross-wise than length-wise) helps a lot but still
> leaves a *lot* to be desired. :-(

The answer is definitely 'RIPmapping' - but it's disappointingly
implemented only rarely on 'real' hardware.
 
-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

RE: [Plib-devel] ulError buffer

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

> > > ul's ulSetError buffer is only 256 bytes long!
> > >
> > > That's a bit short IMHO.
> > >
> > 2048?
> 
> I was going to suggest 1024 - but 2048 will be OK.
> You could get really fancy and allocate more if it runs
> out.
>
1024 sounds good. i commited the change.
--> static char _ulErrorBuffer [ 1024 ] = { '\0' } ;

--Dave

Re: [Plib-devel] texture repeating

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

> "Curtis L. Olson" wrote:
> > In ssg is there a way to control whether a texture is set to "repeat"
> > or not?

Steve Baker writes:
> Sure - that's the second and third parameters of
> ssgSimpleState::setTexture(). 

Ahah, your a genius!  Whups, make that "you're".

> A classic problem - which setting non-repeating clamps will cure
> completely.

Yes, setting the wrapu / wrapv to FALSE totally fixed this particular
problem.  But it didn't help with the mipmap bluring when viewing my
runways from edge on ... or the problem where different sections of
the runway with different textures can't always have the same ft/pixel
ratio so the mipmapping choices don't always blend nicely from one
section to the next.

Runways are hard to get looking nice ... :-(

FYI, here's what I've got so far (as viewed from a mipmap friendly
vantage point)

    http://www.menet.umn.edu/~curt/fgfs/Gallery/Link/kmsp-runway.html

> Joining two textures is a harder problem...for which I wrote a FAQ:
>    http://web2.airmail.net/sjbaker1/tiling_textures.html

It's probably obvious to everyone (and now to myself as well) that you
also need to have a consistant ft/pixel ratio along the edge you are
matching... this could be something worth mentioning in the FAQ.
 
> It's all rather disappointing for the purist though.

This whole mipmapping scheme sucks for edge on runways which is the
view you see them at 95% of the time ... generating "squat" textures
(more resolution cross-wise than length-wise) helps a lot but still
leaves a *lot* to be desired. :-(

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] sending objects to hell

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

> Dave McClurg wrote:
> 
> In tuxkart/src/herring.cxx i noticed that when a herring is eaten
> it is subsequently sent to hell.  (hell means z=-1000000).

Yes - that's how it works.

> Is this
> preferred over removing the herring from the scene graph?

Not really :-)

I lifted the herring code more or less unchanged out of
Tux_AQFH.  Bear in mind that quite a bit of TuxAQFH was
written BEFORE SSG - and subsequently ported onto it!

> Is the culling in ssg efficient enough to quickly throw this
> out without much processing?

Yes. I'm really rather proud of the efficiency of field of view
culling in SSG.

There are rarely more than a dozen herring in a single level - so
even if it was inefficient, it wouldn't make a dent in performance.

There is also an argument of the form:

  * When they ARE visible (before a certain gluttonous
    Spheniscidae Linuxia gets to them), not having to
    test whether they are eaten or not saves time.

  * There are generally more uneaten herring than
    eaten....certainly in TuxKart where they reappear
    within a few seconds of being eaten. So it's
    better to optimise the case when they are NOT eaten.

But that's not why I do it...it's just ancient history.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] Re: plib-devel digest, Vol 1 #139 - 4 msgs

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

Scott LeGrand wrote:
> 
> > Have you had a look at Parsec (http://www.parsec.org)?
> >
> > I know that they don't publish their source (but IIRC they plan to
> > release the game itself for free)...
> 
> There's an embryonic edition of BattleSphere (www.battlesphere.com)
> under development right now.  The project lends itself really nicely
> to a scene graph implementation.  My only peeve is the 3 sound limit
> in sl.  In the dark future I might be sorely tempted to write a special
> windows-only edition that hooks into DirectSound for that component.
> Otherwise, the thought of writing this thing for a bunch of different
> platforms simultaneously is irresistable!

I wrote SL on a 66MHz 486 - three sounds mixed, with dynamic pitch AND
volume envelopes seemed like a reasonable limit back then.

On a modern machine, we could easily wipe out the 3 sound limit - and
increase it to (say) 32 simultaneous sounds.

You *could* also hook into direct sound - or other sound API's - but there
doesn't seem much point in doing that unless you want some of the REALLY
fancy features like 3D sound.  If you are interested in that stuff then
I recommend that you look at OpenAL instead of SL.

I'm somewhat tempted to abandon the current SL - re-implementing it as
a thin layer on top of OpenAL just to allow continued support of existing
applications. Then we could do cool things like embedding OpenAL sound
sources as nodes in the SSG scene graph. Then you'd get automatically
positioned 3D sound...but I just don't have the time these days.

   :-(

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net