plib-users

Re: [Plib-users] Pre/Post draw callbacks on ssgBranches.

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

Jon Anderson wrote:

> Well, when I first started, I attached all the Terrain and the Patches as
> user data on a ssgBranch and ssgVtxTable, respectively.  That  was okay to
> get it up an running, but made it clunky to use.

Yes - I can imagine.  It would also be hard to eliminate the problem of
people attaching 'conventional' ssgVtxTables to the Terrain's ssgBranch
node - which could be messy!  Obviously you can tell people not to do
that - but it would be nicer if that was something the compiler could
just toss out.
 
> >Can I see the code?  It would be easier to discuss.
> 
> I'll post it somewhere tonight.

Thanks.

I'm beginning to wonder whether you need to use SSG's mechanisms to
connect up the Patches to the Terrain at all. Would it be so terrible if
the terrain was an ssgLeaf - that happens to have the patches stored
somehow in a way that lies outside the present SSG tree structure.

Well, maybe I should hold off until I can see the code.
 
> >Not that I know of...but those are pretty simple by comparison to your
> >efforts - all you need is alternative 'cull/hot/isect' member functions
> >derived from an ssgBranch node.
> 
> Okay, that's what I thought.  I probably need to study the code a bit
> more.  I wasn't sure if these were implemented as member functions, or if
> it was an external iterator running over the tree that performed these
> functions.

No - pretty much everything in SSG happens inside the classes - it's more
flexible that way.  Each class can decide how to cull and draw itself - and
how to respond to collision tests and such like.  Virtual functions allow
each piece of functionality to be swapped out as needed by each derived
class.  That makes building things like ssgSelector nodes *really* easy
and clean.

Having said that though, OTHER packages may well be walking the tree
with external iterators - and some of the new optimisation and
transformation tools presumably do that.

If we want to model terrain using PrettyPoly, we'll need to think
rather carefully about how that fits together.
 
-- 
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-users] Pre/Post draw callbacks on ssgBranches.

[Jon A. <jan...@on...>]

>
> > It's split into two parts, a terrain class, and a patch class. Each
> > patch is just a subset of the terrain, to facilitate frustum culling. Each
> > frame, the terrain class initializes, and then tessellates each of its
> > patches.
>
>So a 'terrain' object *contains* the 'patch' objects?
>
>Is that why you need it to be an ssgBranch-derived class?

Yes.


> >  It seems like they only get called on leafs.  So I have to activate 
> the tessellating
> > outside of the normal ssgCullAndDraw().
>
>That's kindof ugly - I agree.  But if you have derived your own class, why do
>you need to mess with callbacks?  You can draw the scene whenever you like.


Well, when I first started, I attached all the Terrain and the Patches as 
user data on a ssgBranch and ssgVtxTable, respectively.  That  was okay to 
get it up an running, but made it clunky to use.

> >  This isn't so bad, except it means no culling is done prior to 
> tessellation.
>
>Yes - I think I understand.
>
>Can I see the code?  It would be easier to discuss.

I'll post it somewhere tonight.

>Not that I know of...but those are pretty simple by comparison to your
>efforts - all you need is alternative 'cull/hot/isect' member functions
>derived from an ssgBranch node.

Okay, that's what I thought.  I probably need to study the code a bit 
more.  I wasn't sure if these were implemented as member functions, or if 
it was an external iterator running over the tree that performed these 
functions.


Thanks for the suggestions,
Jon

Re: [Plib-users] Pre/Post draw callbacks on ssgBranches.

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

Jon Anderson wrote:

> I've been working on a really simple implementation of ROAM to work with
> SSG.

Very cool!

> It's split into two parts, a terrain class, and a patch class. Each
> patch is just a subset of the terrain, to facilitate frustum culling. Each
> frame, the terrain class initializes, and then tessellates each of its
> patches.

So a 'terrain' object *contains* the 'patch' objects?

Is that why you need it to be an ssgBranch-derived class?

>  After all have been tessellated, it then renders them.  It
> tessellates them all at once so that it can match edges, and avoid cracks
> in the terrain.

I get it.

> I've implemented the terrain class as an ssgBranch class, and the patches.
> But any pre or post callbacks don't get called on branches.

That's true - because of the sorting of transparency issues we discussed
about a week ago.

However, in your case, you know that all your daughter nodes have the
same ssgState (presumably) - so they'll either all be translucent - or
none of them - so it ought to be safe to use pre-/post- callbacks.

>  It seems like they only get called on leafs.  So I have to activate the tessellating
> outside of the normal ssgCullAndDraw().

That's kindof ugly - I agree.  But if you have derived your own class, why do
you need to mess with callbacks?  You can draw the scene whenever you like.

>  This isn't so bad, except it means no culling is done prior to tessellation.

Yes - I think I understand.

Can I see the code?  It would be easier to discuss.

> Does anybody have any suggestions on  how to go about this?

I think you just need to go a little deeper into the code - you can
(in principal) do the same things that an ssgLeaf does inside an ssgBranch
or vice-versa.

>  Also, has
> anybody every tried to integrate any higherlevel organization like
> quadtrees or octrees into SSG?

Not that I know of...but those are pretty simple by comparison to your
efforts - all you need is alternative 'cull/hot/isect' member functions
derived from an ssgBranch node.

-- 
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-users] Pre/Post draw callbacks on ssgBranches.

[Jon A. <jan...@on...>]

Hi,

I've been working on a really simple implementation of ROAM to work with 
SSG.  It's split into two parts, a terrain class, and a patch class. Each 
patch is just a subset of the terrain, to facilitate frustum culling. Each 
frame, the terrain class initializes, and then tessellates each of its 
patches.  After all have been tessellated, it then renders them.  It 
tessellates them all at once so that it can match edges, and avoid cracks 
in the terrain.

I've implemented the terrain class as an ssgBranch class, and the patches. 
But any pre or post callbacks don't get called on branches.  It seems like 
they only get called on leafs.  So I have to activate the tessellating 
outside of the normal ssgCullAndDraw().  This isn't so bad, except it means 
no culling is done prior to tessellation.

Does anybody have any suggestions on  how to go about this?  Also, has 
anybody every tried to integrate any higherlevel organization like 
quadtrees or octrees into SSG?

Jon

Re: [Plib-users] VRML Support in SSG?

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

At 03:34 PM 9/15/00 -0700, you wrote:
>I have some .wrl files that I got from NASA, and would like to use them in
>SSG (PLIB 1.3.0). I don't know much (read: anything) about VRML, but already
>came across a bug in SSG reading VRML files. The VRMLtop_tags struct is
>missing a { NULL, NULL } at the end.
>
>In any event, after fixing that, I tried reading in one of these files, and
>there was a lot of stuff spewing to the log. I don't know if I'm just
>missing files to go with the .wrl file, or if SSG doesn't support VRML 2.0
>(as the file claims to be).

At the moment, the VRML loaders are unfinished.  The current priority is 
VRML1, as most CAD and modelling packages will handle that, with fewer 
working with VRML2.  I'm responsible for both loaders, but schedules at 
work are making it tough to get much done on them at the moment.

In the short term, the easiest way to get VRML content into SSG is via one 
of the other mature loaders such as the 3DS loader.  Convert your VRML 
content to 3D Studio format in an external package such as 3D Studio Max, 
and then load it in with the 3DS loader instead.

I can convert the models for you if you don't have Max or another program 
which can do the conversions for you.  Let me know offline if you need me 
to help out.

Regards,

Gil
---------------------------------------------------------------------
3D Graphics Programmer
CSIRO Minesite Imaging Group
Pinjarra Hills, QLD, AUSTRALIA
http://www.dem.csiro.au/research/imaging

"Experience is something you don't get until just after you need it"
---------------------------------------------------------------------

Re: [Plib-users] Foundation

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

Alexander Rawass wrote:

> I stumbled over foundation.sourceforge.net, another Space Sim that uses
> plib for his GUI.
> Probably another project for Steve's Logo page.

Yes - I'll ask the author.

Actually, I think it's rather cool that there are projects that are
using PLIB without the PLIB developers being aware of it.  It suggests
that the library is 'going mainstream'.

-- 
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-users] Foundation

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

Hi,

I stumbled over foundation.sourceforge.net, another Space Sim that uses
plib for his GUI.
Probably another project for Steve's Logo page.



Alex

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

[Plib-users] VRML Support in SSG?

[Rick M. <rm...@la...>]

I have some .wrl files that I got from NASA, and would like to use them in
SSG (PLIB 1.3.0). I don't know much (read: anything) about VRML, but already
came across a bug in SSG reading VRML files. The VRMLtop_tags struct is
missing a { NULL, NULL } at the end.

In any event, after fixing that, I tried reading in one of these files, and
there was a lot of stuff spewing to the log. I don't know if I'm just
missing files to go with the .wrl file, or if SSG doesn't support VRML 2.0
(as the file claims to be).

Any ideas? Please respond to me as I am getting the digest.

TIA,


------------------------------------------------------------
Roderick Mann                 rm...@la...nsspam

Re: [plib-users] XGL

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

Devrim Erdem wrote:
>
> VRML had the same problem and they have solved it by introducing wgz
> which is simply wrl+gz.

It didn't 'solve' the problem - it was a mere bandaid for a gushing wound.

The XGL web site contains a file for two green cubes.  It's 250 lines
of text - and 5Kbytes.

AC3D (which has another ASCII format) takes just over 1Kbytes for the
same thing. VRML takes 1.7Kbytes *WITHOUT* using the 'cube' primitive
(which would be cheating).  Those files compress down to 320 and 520
bytes respectively. The XGL file compresses down to 630 bytes.

It's even worse than that in fact.  The two cubes XGL file has very
nice 'round number' vertex coordinates, colours, etc.  If this was
truly arbitary geometry, the numbers would need many more digits
to specify them - the file size would be much larger - and would compress
much less efficiently.  When I tested two cubes in VRML and AC3D, I
deliberately used non-exact vertex coordinates in order to get a more
realistic test.

The SSG (binary) file for the same thing is 266 bytes...including texture
coordinates, per-vertex normals and colours - which were absent from the
XGL, AC3D and VRML versions.

Tuxkart (for example) has 1.3 Mb of AC3D files.  If I used XGL, (presuming
that the cubes example is typical) that would extend to perhaps 10Mb!
If I switched to SSG, I could get it down to about 0.2Mb.

People do happily download 2Mb OpenSource games.  They think twice about
downloading 11Mb games.

> The only thing that might be interesting is that there are other scene
> graph APIs around and wouldn't it be nice if all of these APIs build
> loaders for XGL instead or VRML, 3DS etc. Every API has a group of
> people trying to build loaders. Most of these loaders have problems.
> Most of the file formats are simply not good enough for realtime 3d.

It's my view that we first need to produce a standard scene graph API.

Until that is done, there is no prospect of having a standard 3D file
format - or even a very great degree or interoperability between file
formats and API's.

-- 
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-users] XGL

[Devrim E. <de...@in...>]

> Devrim Erdem <de...@in...> wrote:
>
> > http://www.xglspec.org
> >
> >The ultimate solution to the loader problems ?
>
> Why should this solve problems for us?
> The other formats will still be around.
> I personally am sceptical about XML-based
> 3D-formats since they are ascii
> and I fear quite large. Yesterday I spoke
> to someone who uses X3D, another XML-based
> 3D format. He said size wouldnt be a problem
> for X3D, but I am not convinced.

VRML had the same problem and they have solved it by introducing wgz
which is simply wrl+gz.

The only thing that might be interesting is that there are other scene
graph APIs around and wouldn't it be nice if all of these APIs build
loaders for XGL instead or VRML, 3DS etc. Every API has a group of
people trying to build loaders. Most of these loaders have problems.
Most of the file formats are simply not good enough for realtime 3d.

I expect to see a resistance from API and loader developers, but
wouldn't that be nice if we had one "extendible" file format ?

Existance of good GPL'ed XML parsers is also a good point.

> I have no idea whether XGL is/will be a
> good format. But I would be EXTREMELY
> surprised if it would
> replace the many other formats.

I agree.

/*===============================================
M. Devrim Erdem            de...@in...
Software Engineering

info(+)TRON, Turkey
Tel: +90 216 4921002, Ext 138
Fax: +90 216 3432132
Http://www.infotron-tr.com
Http://www.machsim.com/devrimerdem
===============================================*/

Re: [Plib-users] SSG without X on server

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

Alexander Rawass wrote:

> On these game servers, where a TuxFleet server will run, it should'nt be
> necessary for the admins of these game servers to start TuxFleet servers
> while running X - I want to make a server-only version of TuxFleet, that
> never tries to open a window or to connect itself to the current
> X-Display.

I've had this problem too. I wrote (but cannot distribute) a 'dummy' X
and 'dummy OpenGL' library that has stub functions for every call that
PLIB uses.  It's a lot of typing - but virtually zero brain effort.
 
> SSG wants a glContext, and (I think) the GL wants to have a running X.
> Correct me if I am wrong.

That's correct.
 
> Can I use GL without the GL wanting to connect to a X-Display?
> Could the collision checking routines of SSG be used without having to
> init GL?

Well if you don't initialise it, bad things will happen - and the initialisation
entails some OpenGL calls...but more mundanely, you won't even be able to link
the code without libGL.so being included...that won't be there on your server.
 
> Any ideas? I hope you understand what I meant.

Well, there are probably two options:

1) Write dummy OpenGL and X routines to link to. (Actually, I don't think SSG
   makes any X calls - just OpenGL).

2) Take a copy of SSG and hack out all the non-collision-detection parts.

Obviously, (1) is time consuming - but it's simple and doesn't put a 'fork' in
the SSG development pathway.  (2) is probably less typing and would be more
space-efficient at runtime.

Go with (1).

Good luck.

-- 
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-users] SSG without X on server

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

Hi,

I realized that I will soon stumble over the following problem:

I want my game to run as well without any net as well to run in a
client/server
mode for multiplayer games.

But I do not only want the server to be run on the machines of the
end-users,
but (in the far future) also on dedicated game-servers, if possible.

On these game servers, where a TuxFleet server will run, it should'nt be
necessary for the admins of these game servers to start TuxFleet servers
while running X - I want to make a server-only version of TuxFleet, that
never tries to open a window or to connect itself to the current
X-Display.

At the moment, this could be possible - because now, I am doing only
collision checking on 'Shield Level', and for that I do not need any
SSG-routines, and for the game logic to run, I also do not need GL/SSG.

BUT!

As soon as I implement collision checking on 'Hull Level' (meaning, I
have to 
use the collision-checking-routines from SSG) I will have a problem for
my server.

SSG wants a glContext, and (I think) the GL wants to have a running X.
Correct me if I am wrong.

So, on a server-only machine, there be no X, so there will be no GL, so
SSG
wont initialize, so I can't do collision checking on vertex level.

Can I use GL without the GL wanting to connect to a X-Display?
Could the collision checking routines of SSG be used without having to
init GL?

A solution could be to start a vnc (virtual X-server) on the server and
let
the TuxFleet server connect to this - this probably wouldn't be slower,
since the TuxFleet server opens a window.

Any ideas? I hope you understand what I meant.


Alex

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

[Plib-users] Problems with puInput

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

Hi,

I am using puInput Fields in the Net-Part of my GuiMenu (see screenshot
tuxfleet.sourceforge.net/gifs/screenshot-gui-connect.gif)

The puInput Fields react on keypresses, I can move, edit, delete, when I
press return this puInput field gets deactivated, and another one
gets activated and the callback function called.

But I couldn't get to react puInput on Mouseclicks.

Any idea what I could have done wrong?

I got plib from cvs, but found no puInput examples there.
(I also noticed that doc/index.html is somehow Steve Baker's private
index
page from woodsoup, and not the plib index page?)

For my puInput, I've done (see
tuxfleet.sourceforge.net/doxygen/html/class_GuiMenu.html#a15)
  if((ptype & PUCLASS_INPUT)==PUCLASS_INPUT){
    ((puInput *)pob)->acceptInput();
    pob->setValue(vdefault);
    pob->setLegend(vdefault);
    //    pob->setStyle(PUSTYLE_SMALL_BEVELLED);
    pob->setCallback( cb_net_input_c );
  }
and (see tuxfleet.sourceforge.net/doxygen/html/class_Engine.html#a31)
    glutKeyboardFunc       ( keyboard_c ) ;
    glutSpecialFunc ( special_c);
    glutMouseFunc(mouseevent_c);
    glutMotionFunc(motionevent_c);
    glutPassiveMotionFunc(motionevent_c);

Any ideas what I missed?



Alex

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

Re: [Plib-users] Editing rgb & rgba's

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

"Gouthas, Themie" wrote:
 
> What image editor do people use for editing .rgba files?

GIMP...it's a truly *great* OpenSource tool - somewhat like
PhotoShop (so I'm told) - but free and rapidly pulling ahead of
PhotoShop in terms of features.  GIMP has been ported to Windoze
too - although it's definitely better under Linux.

BTW: I should point out that there has been a change in the use
of the '.rgba' extension.

ORIGINALLY:  The 'SGI' or 'Haeberli' Image file format used
at least 6 different extensions:

    .bw    -- Black and white - One bit per pixel monochrome.
    .int   -- Intensity - Eight bits per pixel monochrome.
    .inta  -- Intensity/alpha - Eight bits per pixel monochrome
              plus eight bits of Alpha (Transparency).
    .img   -- Colour-mapped '256 colour mode' - 8 bits per pixel.
    .rgb   -- Red/Green/Blue - Eight bits per component 'truecolour'.
    .rgba  -- Red/Green/Blue/Alpha - Truecolour + Alpha 8/8/8/8.

However, these were all the same file *format* - and for any well
written application, the extension is irrelevent.

Over the last few years, people (and tools) seem to have given up
all those extensions and settled on *just* '.rgb' for all of those
various modes.  GIMP, XV, AC3D - and all the other tools that I use
now seem to use '.rgb' only...so I've switched to giving them that
extension also.

Adding to the confusion for my Tux_AQFH game was that the older
versions of AC3D couldn't read RGB-Alpha images correctly.  That
made life absolute hell - so, to get around that I made TWO files
for each map that needed Alpha - one (called '.rgb') had no Alpha
planes and was listed in the model for AC3D's benefit - the other
(called '.rgba') had Alpha and was the one my game code would read.
Handily, this fit the old convention.

Anyway, I should go back and rename all those files because more
recent releases of AC3D can cope with alpha-maps - and it's a pain
to duplicate all the files like that!

-- 
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-users] Editing rgb & rgba's

[Gouthas, T. <the...@ds...>]

What image editor do people use for editing .rgba files?

Re: [Plib-users] TuxFleet 0.3.1 available

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

Hi,

Steve Baker wrote:
> 
> Alexander Rawass wrote:
> 
> > TuxFleet 0.3.1 is available from my Homepage or FTP-Space.
> 
> I think you can stop cross-posting TuxFleet messages to the PLIB lists
> now...it's off-topic unless there is something specific you need to ask about
> PLIB.

You are completely right there - but on the other hand, posting to
tuxfleet-list
is yet very much alike talking to a wall (nearly no readers), so posting
to plib-users is the only chance for me now to get feedback from anyone.

But ok, I'll stop it, exept for plib-related questions.


Alex

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

Re: [Plib-users] TuxFleet 0.3.1 available

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

Alexander Rawass wrote:

> TuxFleet 0.3.1 is available from my Homepage or FTP-Space.

I think you can stop cross-posting TuxFleet messages to the PLIB lists
now...it's off-topic unless there is something specific you need to ask about
PLIB.

Thanks.

-- 
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-users] Re: Tuxfleet on Mac

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

Hi,

Jonathan Wight wrote:
> 
> Anyone working on a MacOS version?

Yes/No.

TuxFleet was written to be completely platform indepentent, so it should
be
quite easy to compile it on a Mac (you maybe don't even need to port
it).

The only things TuxFleet needs to compile are
a) a POSIX-environment to compile/run in
   every unix has that by default, and windows has that with cygwin
   you propably need only a gcc compiler for Mac and assorted sets of
   libraries/tools
b) a GL library
   this could be a native Mac GL library as well as MesaGL

You then would have to compile plib for MacOS (as far as I know, this
should
work), and then TuxFleet.

I don't have a Mac or access to a Mac, so I can't do it,
but I think it should be pretty easy for someone with a Mac and a
gcc-compiler
to build a working Mac-binary.

Any Mac-Developer (maybe you?) is invited to do the job and dump the
resulting
binary in the incoming-Directory of my FTP-Space - I can't.

Or even better: buy me a Mac :-)))))




Alex

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

[Plib-users] TuxFleet 0.3.1 available

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

Hi,

TuxFleet 0.3.1 is available from my Homepage or FTP-Space.

TuxFleet 0.3.1 is available as source and binaries for i386-linux and
i386-beos5.

The Beos-Binary comes without Sound or Net support.

Most noticeable changes:

written a very basic not fully working GUI for Net/Multiplayer.



ChangeList:

tuxfleet-0.3.1     06 Sep 2000 
        server doesn't open own window anymore 
        server calculates frames at given rate, not unlimited frames 
        client sends back fps info 
        can record films (only in client-mode) by saving the data the
client
	 receives onto disk 
        changed mission format a bit: the player isnt any more given as
KI Player,
	 but as 'set defaultplayer <flightgroup>' 
        most mission have no defaultplayer yet - ship nr. 1 is used
there 
        written a GUI for net-connection 
        created a user tux...@us... (a mail
account like
	 that of Santa Claus) 
        net works for exactly one client 
        variable soft_cursor enables puSoftCursor 


Alex


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

Re: [Plib-users] reference counting and simpleStates

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

"Gouthas, Themie" wrote:
> 
> I noticed when attaching states to tri-strip leaf nodes, that even though
> simpleState derrives from ssgBase, the reference count is unchanged
> and when a scene tree is deleted, the attached ssGsimpleState remains
> allocated.
> 
> Is this a deliberate design feture or a bug?

Coincidentally - I noticed this just last weekend,  I briefly looked at
fixing it - and it's not entirely simple.  I'm also a little concerned
that fixing it will actually break some programs - so we have to tread
carefully and work with our end-users.

The scenario that concerns me is the kind of thing that TuxKart does:

  * Load a set of textures, etc and populate a default set of
    ssgSimpleStates (whose refcounts will now be zero - right?).

  * Load the first racetrack - tell the loader not to create
    materials - but to refer them to the app.  The ref count
    of all those ssgSimpleStates will be incremented,

  * At the end of the race, we delete the scene graph and
    load the next racetrack.  Unfortunately deleting the
    scene graph would decrement the ssgSimpleState's ref
    count to zero...which would make SSG delete them...(which
    it doesn't do right now because of the SSG bug) so
    when the next racetrack is loaded...KABLOOIE!!

So - we *do* need to fix this - but we need to check with
our application authors to ensure that they do an extra 'ref'
to ssgSimpleState's that they need to keep.

This could happen in more subtle ways in packages like FGFS
which pages the scenery from disk on-the-fly.

It's simple enough to fix in the application - but we DO
have to sync up with those guys.

You'll notice that some of the fixes are in the CVS version
right now - but commented out.

-- 
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-users] reference counting and simpleStates

[Gouthas, T. <the...@ds...>]

I noticed when attaching states to tri-strip leaf nodes, that even though
simpleState derrives from ssgBase, the reference count is unchanged 
and when a scene tree is deleted, the attached ssGsimpleState remains
allocated.

Is this a deliberate design feture or a bug?

[Plib-users] re: Quaternion rotations

[Michael K. <mk...@fu...>]

This was passed to the developers list today, sorry for the delay in
responding - I have added myself to the users list now so I can answer any
further questions  =)

Thats a neat way of rotating with quaternions, I think its cool that it
works - but its not the best way to do it   =)

If you dig into the quaternion code you will find:

inline void sgRotQuat ( sgQuat dst, const SGfloat angle, const sgVec3 axis )
{
  sgQuat q ;

  sgAngleAxisToQuat ( q, angle, axis ) ;
  sgPostMultQuat ( dst, q ) ;
  sgNormaliseQuat ( dst ) ;
} ;


As you can see when you want to rotate a quaternion the axis vector gets
combined with the angle to make a new rotation quaternion - and then it
*post* multiplies the two of them together.

Because of the complex math behind quaternions  Q1 x Q2  is NOT equal to Q2
x Q1.

So if a post multiply rotates around the worlds axis, what could a pre
multiply do? It rotates around the local axis of course!

void sgPreRotQuat ( sgQuat dst, const SGfloat angle, const sgVec3 axis )
{
  sgQuat q ;
  sgAngleAxisToQuat ( q, angle, axis ) ;
  sgPreMultQuat ( dst, q ) ;
  sgNormaliseQuat ( dst ) ;
}


So why isnt there a PreRotQuat function (or something with a much better
name) in SG? Oversight I suppose. Nobody has been using them so it hasn't
been missed. Before we add something to SG I think we need to come up with a
clear name for the rotations that will convey what they do. Just calling
them sgPreRotQuat and sgPostRotQuat isn't very clear.

What about sgWorldRotQuat (for post), and sgLocalRotQuat (for pre) ?

-Michael Kurth



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Bob Hammond
Sent: Saturday, September 02, 2000 1:30 PM
To: pli...@li...
Subject: [Plib-users] Quaternion rotations


Hi,

I downloaded the latest CVS version of plib and found the new quaternion
demo (with the two rotating cubes).  This demo rotates the quaternions
around the world axes (using sgRotQuat(..) ).

How can I use quaternions to rotate an object around it's axes?  I've got an
idea that might work.  Say I want to rotate around the x axis, I convert my
quaternion to a matrix, extract the first column and use this as the vector
passed to sgRotQuat.

Ie.

sgMat4 tmpMat ;
sgQuatToMat ( tmpMat, myQuat ) ; // Make the matrix from the quaternion
sgRotQuat ( myQuat, 5.0, tmpMat [0] ) ; // Rotate 5 degress around objects x
axis

Since we're only using the first row of the matrix the above can probably be
simplified.

Will this work? Is there anything else I need to know (stuff that might bite
me in the ass?) ?

Re: [Plib-users] Performance Benchmarks

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

> Aaron Drew wrote:
> 
> I'm just wondering if any performance benchmarks have been done with plib?

No - when I first wrote it, the overheads in PLIB were *negligable* compared to the
time consumed in OpenGL doing vertex transforms - so there wasn't much point in leaning
on the optimisation.

Now we have hardware T&L, it would be interesting to see where the cycles are going.

Informal testing I've done at work suggest that even with a GeForce-2, providing you
have an 'equivelently modern' CPU (say a 450MHz or so), PLIB is still not the bottleneck.

> From the website its hard to see if plib comes with any standard visibility algorithm support
> like portals, bsp trees or octrees.

No portals - although it would be moderately easy to add a portal mechanism...we discussed that
a couple of days ago.

No BSP trees - the thing that PLIB implements is better (unless you are trying to
render without a Z buffer - in which case I don't think you should be using PLIB
at all).

Octrees are really just a way of using what PLIB already does.

> If I were to implement an octree using plib, would it typically be a single
> ssgNode object or rather a separate node for each octree volume with some
> sort of a custom intelligent (much more complex than the class I think is
> called ssgSelector) branch class that would look after these issues?

You could either have a single ssgBranch node - with (up to) eight other
ssgNode's beneath it - and allow SSG to do FOV culling...or you could derive
a class from ssgBranch that would do fancier culling given that it has more
information about the structure of the model than ssgBranch does.
 
-- 
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-users] Performance Benchmarks

[Aaron D. <ri...@ho...>]

I'm just wondering if any performance benchmarks have been done with =
plib? Profiler output would also be handy.=20

From the website its hard to see if plib comes with any standard =
visibility algorithm support like portals, bsp trees or octrees. If I =
were to implement an octree using plib, would it typically be a single =
ssgNode object or rather a separate node for each octree volume with =
some sort of a custom intelligent (much more complex than the class I =
think is called ssgSelector) branch class that would look after these =
issues?=20

Regards,
Aaron Drew

Re: [Plib-users] max number of surfaces per model

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

Alexander Rawass wrote:

> > > max number of surfaces per model?
> > > max total size of textures per model?

> So, what would you say to him?

I would say "this is nothing to do with me - please ask the question
on the TuxFleet mailing list".
 
The problem is that you might have a 66MHz 486 with no 3D graphics card,
or you might have a Freon-cooled overclocked 1.13MHz P4 that Intel
forgot to recall with a 4x AGP and GeForce-2-ULTRA.

The difference in performance is at LEAST 10,000:1 ...probably more.

So, what hardware are you allowing as your usable range?

How many of these ships are you planning to draw?

What range of frame rates do you think you can tolerate?

What LOD mechanisms will you use?

Do you think you will be fill-limited or poly-limited or bus limited
or CPU limited or .... ?

I think you have to run your application with cubes in place of space
ships - then again with 10,000 (tiny) random triangles - and see where
in that range is a 'reasonable' frame rate on the range of machines you
want to support.


> Please make the following assumptions:
> 1) the HudObjects using glut have been replaced or switched off and
> therefore
>    take up not much cpu time
> 2) my code that does the game logic takes up from 0.001 to 0.005 secs
> each frame
> 3) the rest of the time is ssgCullAndDraw

Well, if you want to run at (say) 30Hz, and you want quite a lot of
spaceships, I'd tell your artist to aim for 1000 triangles at the topmost
level of detail - and provide 200, 50 and 10 triangle versions also so that
on crappy hardware, they only see the 50 polygon versions when they are
up close - and the 10 triangle versions at a distance - but on really good
hardware, they'll see the 1000 triangle version all the way out until the
object covers just one pixel.
 
> I personally just cant image how many polygons a suitable object should
> have,
> how many polygons plibssg can render (if not slowed down by game code or
> huds)?

It's **MUCH** more subtle than that - the number of OpenGL state changes
makes a difference - the average length of triangle strips you are able
to form makes a difference....all sorts of factors.

No two games are remotely alike.
 
> > This answer may not satisfy you, so let me just explain with some
> > examples
> > what I mean:
> >
> > Have a look at the bee (data/bee.ac). It's my favorite model, it looks
> > so *cute* :-)

(If that's the one from Tux_AQFH, my (then) 7 year old son made it!)

My best advice is that the artist and the programmer have to work closely
together on this process.

The artist (being artistic) may want to put more polygons into planets
and nebulea and comets and 'gaseous anomalies' and have textured "Borg
tetrahedrons"...or he may want planets that are 20 triangle icosahedrons
(ick!) and 10,000 triangle ships....that's why he's the artist and you
are the 'mere programmer' :-)

There is no good answer to this.

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