plib-devel

[Plib-devel] Changing VTable triangles (+ blend and texture modes)

[Sam S. <sa...@sp...>]

Hi,

I'm currently putting together an explosion class for an ssg example
(sparks, smoke, debris that sort of thing).  It seems quite an overhead
to have this structure:

explosion
    |
    +----- ssgTransform
    |            |
    |            +------- ssgVTable (spark)
    |
    +----- ssgTransform
    |            |
    |            +------- ssgVTable (spark)
    |
    +----- ssgTransform
    |            |
    |            +------- ssgVTable (spark)
    |
   etc.

If there was a setVertex(int n, sgVec3) method in ssgVTable then I could
get rid of all transforms and individual spark nodes and just have one
ssgVTable that rendered the lot (and also one bounding sphere). ie:

explosion
    |
    +----- ssgVTable (sparks)
    |
    +----- ssgVTable (smoke)
    |
   etc.

Does it seem sensible to add this method (I'll try it when I have some
working code and test the speed difference).  The only oddity it would
have is that you'd have to destroy and recreate the display list if it's
been created (but then you shouldn't be calling setVertex on a diplay
list node now should you :) ).

Another question (should probably go to plib-users but I don't seem to
get the subscribe confirmation messages back at the moment) - blend and
texture modes.  How are these set?

There's the enable (GL_BLEND) in ssgSimpleState, but where do you set
the blend mode parameters?  Likewise for the texture environment modes.
Do you use the pre and post draw callbacks?  That seems a little bit
ugly to me - am I missing something?

Sam

ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

[Sam S. <sa...@sp...>]

Well, obviously I should had been using ssgVxtTable rather than the
obsolute ssgVTable - which means the set methods I mentioned need to be
a part of ssgSimpleList.

In my copy I've added:

  void raw_set (unsigned int n, char *thing )
  {
    if(n < total)
      memcpy ( & list [ sizeof * n ], thing, size_of ) ;
  };

in ssgSimpleList, and equivlent methods in ssgVertexArray,
ssgTexCoordArray, ssgNormalArray, ssgColourArray, ie:

  void  set ( unsigned int n , sgVec3 thing ) { raw_set ( n, (char *)
thing ) ; } ;

in ssgVertexArray.

And then in ssgVtxArrary:

  void setVertex  (int i, sgVec3 thing){ if(i<getNumVertices
())vertices ->set(i, thing)}
  void setNormal  (int i, sgVec3 thing){ if(i<getNumNormals
())normals  ->set(i, thing)}
  void setTexCoord(int i, sgVec2
hing){ if(i<getNumTexCoords())texcoords->set(i, thing)}
  void setColour  (int i, sgVec4 thing){ if(i<getNumColours
())colours  ->set(i, thing)}

If it's liked I'd appreciate this code being added to the CVS version.


I've also hacked my copy of pui so that gadget sizes can be specified in
opengl co-ordinates, rather than pixels.  It's very simple - it uses
this code from the non-glut part of pui:

static int puWindowWidth  = 400 ;
static int puWindowHeight = 400 ;

int puGetWindowHeight () { return puWindowHeight ; }
int puGetWindowWidth  () { return puWindowWidth  ; }

void puSetWindowSize ( int width, int height )
{
  puWindowWidth  = width  ;
  puWindowHeight = height ;
}

I need this because I use some of the pui gadgets (well actually
subclasses of the pui gadgets), to add controls to my HUD (this is also
coupled with calling  puGetUltimateLiveInterface () -> draw ( 0, 0 ) ;
myself rather than calling puDisplay() - as this would cause a redundant
glViewport call).

If anyone else is interested in this I'll knock up an alteration so that
it can be enabled at runtime.

Sam

Re: ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

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

Sam Stickland wrote:
 
> Well, obviously I should had been using ssgVxtTable rather than the
> obsolute ssgVTable - which means the set methods I mentioned need to be
> a part of ssgSimpleList.

Well, what was intended was that you call ssgVtxTable::getVertex(int i)
which delivers a POINTER to the i'th vertex - which you are then at
liberty to dink with. (Also 'getColour', 'getNormal' and 'getTexCoord')

This is generally faster than a 'get-a-copy-of-the-vertex/dink with it/setVertex'
mechanism.

I know this works because PPE uses it.

One other thing to beware of is that you have to make sure that the
bounding sphere stays reasonable.  So, either:

* Call recalcBSphere each frame after your leaf node has been messed with.

* Initialise the object to it's maximum size and call recalcBSphere just once
  at start of day.

Which you do depends on your application.  The first is time consuming because
recalcBSphere isn't very fast - but it generates accurate spheres which results
in less chance of all the polygons being sent to OpenGL when they are in fact
off-screen.  The second is faster per-frame but results in wasteful field-of-view
culling.

You choose!

Hence, I don't think we need your change...what we *do* need is better documentation!

> I've also hacked my copy of pui so that gadget sizes can be specified in
> opengl co-ordinates, rather than pixels.  It's very simple - it uses
> this code from the non-glut part of pui:
> 
> static int puWindowWidth  = 400 ;
> static int puWindowHeight = 400 ;
> 
> int puGetWindowHeight () { return puWindowHeight ; }
> int puGetWindowWidth  () { return puWindowWidth  ; }
> 
> void puSetWindowSize ( int width, int height )
> {
>   puWindowWidth  = width  ;
>   puWindowHeight = height ;
> }
> 
> I need this because I use some of the pui gadgets (well actually
> subclasses of the pui gadgets), to add controls to my HUD (this is also
> coupled with calling  puGetUltimateLiveInterface () -> draw ( 0, 0 ) ;
> myself rather than calling puDisplay() - as this would cause a redundant
> glViewport call).
> 
> If anyone else is interested in this I'll knock up an alteration so that
> it can be enabled at runtime.

I guess that's useful - so I'll certainly accept such a patch - providing
it doesn't alter the default behavior.

-- 
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: ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

[Sam S. <sa...@sp...>]

----- Original Message -----
From: Steve Baker <sjb...@ai...>
To: <pli...@li...>
Sent: Sunday, August 06, 2000 8:02 PM
Subject: Re: ssgVtxArrary and ssgSimpleList addtions + pui resize
additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and
texture modes))


> Sam Stickland wrote:
>
> > Well, obviously I should had been using ssgVxtTable rather than the
> > obsolute ssgVTable - which means the set methods I mentioned need to
be
> > a part of ssgSimpleList.
>
> Well, what was intended was that you call ssgVtxTable::getVertex(int
i)
> which delivers a POINTER to the i'th vertex - which you are then at
> liberty to dink with. (Also 'getColour', 'getNormal' and
'getTexCoord')
>
> This is generally faster than a 'get-a-copy-of-the-vertex/dink with
it/setVertex'
> mechanism.

Doh! Yes, that makes sense - I'm too used to thinking of get/set
methologies.  Actually, due to the way I'm converting my explosion class
I was already storing all the positions so I only needed a 'set'
method - it never occured to me to try 'get'.

> One other thing to beware of is that you have to make sure that the
> bounding sphere stays reasonable.  So, either:
>
> * Call recalcBSphere each frame after your leaf node has been messed
with.
>
> * Initialise the object to it's maximum size and call recalcBSphere
just once
>   at start of day.
>
> Which you do depends on your application.  The first is time consuming
because
> recalcBSphere isn't very fast - but it generates accurate spheres
which results
> in less chance of all the polygons being sent to OpenGL when they are
in fact
> off-screen.  The second is faster per-frame but results in wasteful
field-of-view
> culling.
>
> You choose!

Actually it would be nice to be able to provide the bounding sphere
myself :).   In the case of an explosion if you know the position of the
fastest moving particle you can calculate the radius of the bounding
sphere from that.

You could have a setBoundingSphere method (that would also have to dirty
all the spheres above it), but then changing an sgTransform would still
cause the explosions bounding sphere to be recalculated the expensive
way - perhaps a callback hook for bounding sphere calculations would be
best?

> Hence, I don't think we need your change...what we *do* need is better
documentation!
>
> > I've also hacked my copy of pui so that gadget sizes can be
specified in
> > opengl co-ordinates, rather than pixels.  It's very simple - it uses
> > this code from the non-glut part of pui:

[SNIP]

> > If anyone else is interested in this I'll knock up an alteration so
that
> > it can be enabled at runtime.
>
> I guess that's useful - so I'll certainly accept such a patch -
providing
> it doesn't alter the default behavior.

Nope, and it won't take very long at all to do.

Sam

Re: ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

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

Sam Stickland wrote:

> Actually it would be nice to be able to provide the bounding sphere
> myself :).   In the case of an explosion if you know the position of the
> fastest moving particle you can calculate the radius of the bounding
> sphere from that.

Hmmm - same as vertices - you can get a pointer to the bsphere:

   sgSphere *ssgEntity::getBSphere() ;
 
...then you can set the center and radius.

   sphere -> setCenter ( x, y, z ) ;
   sphere -> setRadius ( r ) ;

Finally, you have to tell the API that you messed with it:

   ssgEntity::dirtyBSphere () ;

...which will cause all the bounding spheres from there on upwards to
be dirtied and hence recalculated the next time they are rendered.

> You could have a setBoundingSphere method (that would also have to dirty
> all the spheres above it), but then changing an sgTransform would still
> cause the explosions bounding sphere to be recalculated the expensive
> way - perhaps a callback hook for bounding sphere calculations would be
> best?

Well, I think most people would just set the bsphere to the maximum
radius and leave it there.

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