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