libgf-p51dev — P-51 Development Topics

[P51dev] Switching to Delta3D...

[Johnson, E. U. <rej...@np...>]

Hi all,
=20
P-51 is in the process of becoming "The Delta3D Open Source Game and
Simulation Engine".  In doing so, development of P51 will be
discontinued and cease to be updated.  It is recommended to migrate to
Delta3D as soon as possible.
=20
Delta3D homepage is at: http://delta3d.sourceforge.net/
Delta3D Project page is at: https://sourceforge.net/projects/delta3d/
=20
We have 2 new mailing lists: one for Developers and one just for
breaking News items. https://sourceforge.net/mail/?group_id=3D113203
=20
The new CVS is up and running and all new development should go to
Delta3D - not P51.
=20
Thanks,
Erik
=20
__________________________
Erik Johnson
Lead Software Engineer
MOVES Institute
(831) 656-2967
rejohnso <at> nps <dot> edu
=20

[P51dev] Impressive water (with source)

[Andrzej K. <ak...@np...>]

All--

     There's a really impressive water effect up at
http://graphics.cs.lth.se/theses/projects/projgrid/.  I found it through
http://www.vterrain.org/.  It includes source (not sure about licensing) and
a paper explaining the effect.

     --Andrzej

=-----
Andrzej Kapolka
The MOVES Institute
Naval Postgraduate School
M.E. Annex 280, (831) 656-2265
------=

[P51dev] New particle system parameters

[Andrzej K. <ak...@np...>]

All--

     The OSG particle system classes have some new parameters that make it
easier to create effects like explosions that emit particles in bursts,
rather than in continuous streams.  I added the new parameters to the
particle system editor and tried them out in examples/testEffects.

     The way they work is a little tricky.  Each effect has an internal
clock that goes to from 0.0 to ResetTime, then resets to 0.0.  If ResetTime
is 0.0, the clock doesn't reset.  You can change the StartTime parameter to
make the emitter generate particles only part of the time.  If you set
StartTime to 5.0 and ResetTime to 10.0, then the effect will wait five
seconds, generate particles for five seconds, wait five seconds, and so on.
If you disable the Endless parameter and set the LifeTime parameter, you get
some additional control over the emission interval.  For example,
explosion.osg has LifeTime of 0.01, a StartTime of 0.0, and a ResetTime of
6.00.  That means that it generates particles for 0.01 seconds, stops, waits
for 5.99 seconds, and then restarts.  This looping behavior makes it easier
to edit the explosion in the psEditor.

     In testEffects, I create explosions that last for five seconds using
the EffectManager.  That means that the explosions are deleted before they
have a chance to restart.

     --Andrzej

=-----
Andrzej Kapolka
The MOVES Institute
Naval Postgraduate School
M.E. Annex 280, (831) 656-2265
------=

[P51dev] CVS changes

[Johnson, E. U. <rej...@np...>]

Okay, we're back in action.
=20
We now have a isolated the FLTK Debugger GUI into it's own library
("gui_fl").  I modified all the projects to reflect this.  Basically, if
an application wants to use this GUI, it just needs to link in the
gui_fl.lib and it has access to it.  It used be built right into the
core P51 library.  The future of the GUI is under evaluation and this is
a good first step to isolate it from the rest of P51.
=20
Also, George's CloudDome class is now an integral part of the P51 core
library.  The project TestClouds is an example of how to use this fine
example of a EnvEffect.
=20
Hopefully everything still compiles and links okay after all the changes
we made!
=20
Thanks,
EJ
=20
=20
__________________________
Erik Johnson
Lead Software Engineer
MOVES Institute
(831) 656-2967
rejohnso at nps<dot>navy<dot>mil
=20
=20

[P51dev] CVS issues

[Johnson, E. U. <rej...@np...>]

Hi all,
=20
Looks like we have some conflicting CVS files which are breaking the
build.  I would suggest not updating your local source code with files
dated any newer than this morning.
=20
Thanks - I'll get this sorted out ASAP.
=20
=20
__________________________
Erik Johnson
Lead Software Engineer
MOVES Institute
(831) 656-2967
rejohnso at nps<dot>navy<dot>mil
=20
=20

[P51dev] DIS/HLA entity types

[Andrzej K. <ak...@np...>]

All--

     The DIS Data Dictionary lists the DIS/HLA (RPR-FOM) entity types.

     http://www.sisostds.org/dis-dd/entity/index.htm

     Types consist of six fields: kind, domain, country, category,
subcategory, specific, and extra.  For instance, an M1A1 tank is Kind:
Platform/Domain: Land/Category: Tank/Country: United States/Subcategory: M1
Abrams/Specific: M1A1 Abrams.

     --Andrzej

=-----
Andrzej Kapolka
The MOVES Institute
Naval Postgraduate School
M.E. Annex 280, (831) 656-2265
------=

[P51dev] ext dep release 0.0.8b

[Johnson, E. U. <rej...@np...>]

Hi all,
=20
Another day, another external dependency release.  This time its labeled
0.0.8b which includes an up-to-date version of OSG.  This new version of
OSG includes 3D .dds texture file loading.
=20
A few source code files had to change so when you grab 0.0.8b, make sure
you Update your local P51 files as well.
=20
You can get your own copy at:
https://sourceforge.net/project/showfiles.php?group_id=3D50340&package_id=
=3D
66332&release_id=3D239831
=20
Thanks!

[P51dev] External Dependencies 0.0.8a

[Johnson, E. U. <rej...@np...>]

I just released a new ext. dep. package which now includes Replicant
Body libraries that are compatible with the included OSG library.
=20
I labeled this as "0.0.8a" since this is just a fix for the previous
0.0.8.  Grab it now and update your local source code and all should be
well.  All the examples compile, link, and run correctly now!
=20
https://sourceforge.net/project/showfiles.php?group_id=3D50340&package_id=
=3D
66332
=20
=20
Thanks!
=20
=20
=20

[P51dev] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [P51dev] New Dependencies

[Andrzej K. <ak...@np...>]

     I fixed all of the problems below except for the one with Viewer, which
I wasn't seeing.  TestCharacter will require the new ReplicantBody libs/dlls
I sent you.

     --Andrzej

----- Original Message ----- 
From: "Johnson, Erik USA" <rej...@np...>
To: <lib...@li...>
Sent: Thursday, May 20, 2004 7:53 PM
Subject: [P51dev] New Dependencies


We have a monumental change to our external dependencies this time.
Grab the latest package of externals (precompiled under VS 7.1) at:
https://sourceforge.net/project/showfiles.php?group_id=50340&package_id=
66332

In summary: new OSG, Producer, OpenThreads, ODE, and FLTK.  Boost,
Phython, LUA, and RTI are not included in the external dependencies and
are required for some of the examples.


Portions of the P51 source code had to be modified for the new externals
so make sure to update your local copies.

Things that are broken:
-testCharacter is using an OSG method that is not found in the .dll's
("NodeVisitor()")
-testMotion exits with a "Fatal stepsize..." message
-The InfiniteTerrain's texture is not displayed correctly (clamping
problem?)
-The utility "Viewer" exits upon touching the window
-The utility BSPCompiler is referencing an OSG method which doesn't
exist anymore
-Warning messages from all physics objects (something regarding
"inertia...")


The testPython, testLUA, and testHLA projects are not included in the
examples "solution" because they rely on other, nondistributed external
dependencies.

Please give this new file release a try and let me know if anything else
is broken!

Thanks,
Erik

RE: [P51dev] New Dependencies

[Wells, D. U. <wd...@np...>]

aHR0cDovL3d3dy5qb2huZm9yc3Rlci5jb20vQ09ERVBFTkQuaHRtbA0KDQoJLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogSm9obnNvbiwgRXJpayBVU0EgDQoJU2VudDogVGh1IDUv
MjAvMjAwNCA3OjUzIFBNIA0KCVRvOiBsaWJnZi1wNTFkZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0
IA0KCUNjOiANCglTdWJqZWN0OiBbUDUxZGV2XSBOZXcgRGVwZW5kZW5jaWVzDQoJDQoJDQoJV2Ug
aGF2ZSBhIG1vbnVtZW50YWwgY2hhbmdlIHRvIG91ciBleHRlcm5hbCBkZXBlbmRlbmNpZXMgdGhp
cyB0aW1lLiAgR3JhYiB0aGUgbGF0ZXN0IHBhY2thZ2Ugb2YgZXh0ZXJuYWxzIChwcmVjb21waWxl
ZCB1bmRlciBWUyA3LjEpIGF0Og0KCWh0dHBzOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3Qvc2hv
d2ZpbGVzLnBocD9ncm91cF9pZD01MDM0MCZwYWNrYWdlX2lkPTY2MzMyDQoJIA0KCUluIHN1bW1h
cnk6IG5ldyBPU0csIFByb2R1Y2VyLCBPcGVuVGhyZWFkcywgT0RFLCBhbmQgRkxUSy4gIEJvb3N0
LCBQaHl0aG9uLCBMVUEsIGFuZCBSVEkgYXJlIG5vdCBpbmNsdWRlZCBpbiB0aGUgZXh0ZXJuYWwg
ZGVwZW5kZW5jaWVzIGFuZCBhcmUgcmVxdWlyZWQgZm9yIHNvbWUgb2YgdGhlIGV4YW1wbGVzLg0K
CSANCgkgDQoJUG9ydGlvbnMgb2YgdGhlIFA1MSBzb3VyY2UgY29kZSBoYWQgdG8gYmUgbW9kaWZp
ZWQgZm9yIHRoZSBuZXcgZXh0ZXJuYWxzIHNvIG1ha2Ugc3VyZSB0byB1cGRhdGUgeW91ciBsb2Nh
bCBjb3BpZXMuDQoJIA0KCVRoaW5ncyB0aGF0IGFyZSBicm9rZW46DQoJLXRlc3RDaGFyYWN0ZXIg
aXMgdXNpbmcgYW4gT1NHIG1ldGhvZCB0aGF0IGlzIG5vdCBmb3VuZCBpbiB0aGUgLmRsbCdzICgi
Tm9kZVZpc2l0b3IoKSIpDQoJLXRlc3RNb3Rpb24gZXhpdHMgd2l0aCBhICJGYXRhbCBzdGVwc2l6
ZS4uLiIgbWVzc2FnZQ0KCS1UaGUgSW5maW5pdGVUZXJyYWluJ3MgdGV4dHVyZSBpcyBub3QgZGlz
cGxheWVkIGNvcnJlY3RseSAoY2xhbXBpbmcgcHJvYmxlbT8pDQoJLVRoZSB1dGlsaXR5ICJWaWV3
ZXIiIGV4aXRzIHVwb24gdG91Y2hpbmcgdGhlIHdpbmRvdw0KCS1UaGUgdXRpbGl0eSBCU1BDb21w
aWxlciBpcyByZWZlcmVuY2luZyBhbiBPU0cgbWV0aG9kIHdoaWNoIGRvZXNuJ3QgZXhpc3QgYW55
bW9yZQ0KCS1XYXJuaW5nIG1lc3NhZ2VzIGZyb20gYWxsIHBoeXNpY3Mgb2JqZWN0cyAoc29tZXRo
aW5nIHJlZ2FyZGluZyAiaW5lcnRpYS4uLiIpDQoJIA0KCSANCglUaGUgdGVzdFB5dGhvbiwgdGVz
dExVQSwgYW5kIHRlc3RITEEgcHJvamVjdHMgYXJlIG5vdCBpbmNsdWRlZCBpbiB0aGUgZXhhbXBs
ZXMgInNvbHV0aW9uIiBiZWNhdXNlIHRoZXkgcmVseSBvbiBvdGhlciwgbm9uZGlzdHJpYnV0ZWQg
ZXh0ZXJuYWwgZGVwZW5kZW5jaWVzLg0KCSANCglQbGVhc2UgZ2l2ZSB0aGlzIG5ldyBmaWxlIHJl
bGVhc2UgYSB0cnkgYW5kIGxldCBtZSBrbm93IGlmIGFueXRoaW5nIGVsc2UgaXMgYnJva2VuIQ0K
CSANCglUaGFua3MsDQoJRXJpaw0KCSANCgkgDQoNCg==

[P51dev] New Dependencies

[Johnson, E. U. <rej...@np...>]

We have a monumental change to our external dependencies this time.
Grab the latest package of externals (precompiled under VS 7.1) at:
https://sourceforge.net/project/showfiles.php?group_id=3D50340&package_id=
=3D
66332
=20
In summary: new OSG, Producer, OpenThreads, ODE, and FLTK.  Boost,
Phython, LUA, and RTI are not included in the external dependencies and
are required for some of the examples.
=20
=20
Portions of the P51 source code had to be modified for the new externals
so make sure to update your local copies.
=20
Things that are broken:
-testCharacter is using an OSG method that is not found in the .dll's
("NodeVisitor()")
-testMotion exits with a "Fatal stepsize..." message
-The InfiniteTerrain's texture is not displayed correctly (clamping
problem?)
-The utility "Viewer" exits upon touching the window
-The utility BSPCompiler is referencing an OSG method which doesn't
exist anymore
-Warning messages from all physics objects (something regarding
"inertia...")
=20
=20
The testPython, testLUA, and testHLA projects are not included in the
examples "solution" because they rely on other, nondistributed external
dependencies.
=20
Please give this new file release a try and let me know if anything else
is broken!
=20
Thanks,
Erik
=20
=20

[P51dev] Nightly tar files

[Johnson, E. U. <rej...@np...>]

Hi all,
=20
For those of you who wish to use the latest P51 CVS code but have
trouble accessing the server, you now have the option of downloading a
nightly tar file containing a snapshot of CVS.
=20
At the bottom of the page
http://www.nps.navy.mil/cs/research/vissim/Engine/enginemain.html is a
link for the nightly tarball.  This file should be automatically rebuilt
every night around midnight.
=20
Hope this helps the CVS "outages"!
=20
=20

RE: [P51dev] RE: Vegetation rendering technique

[Wells, D. U. <wd...@np...>]

This is the technique I described using in my dissertation proposal.  I
think that with the advent of 256mb and 512mb cards that using silly
amounts of texture memory will be a null issue.  <As an FYI: ATI's
latest demo (with the Ruby girl) supposedly uses 249mb of texture
memory.>  An interesting thing to do with the sliced tree demo is to
change the texture setting.  For example, treedemo -texture 512 will
create some nice, but very crisp-looking trees while treedemo -texture
16 will create very fuzzy trees.  Manipulating this as a function of
distance (yup, ala mipmapping) and you can get your painterly effect.

BTW: here are the settings I have been playing with:
treedemo -number 1000 -width 1024 -height 768 -bpp32 -texture 256 -list

Feel free to play around with these settings and make sure to get above
the top of the forest to get a feel for the low-level helicopter
perspective.

BTW... these guys used TreeDruid to make the trees (a product, along any
of the others shown at http://www.vterrain.org/Plants/plantsw.html that
we should consider purchasing).

Fuzzy.

-----Original Message-----
From: Kapolka, Andrzej USA=20
Sent: Wednesday, May 12, 2004 10:14 AM
To: lib...@li...
Subject: Re: [P51dev] RE: Vegetation rendering technique


     Yes.  The demo shows the original tree mesh for comparison.  Even
in
the slicing approach, the trunk is still rendered as a mesh.

     --Andrzej

----- Original Message -----=20
From: "Johnson, Erik USA" <rej...@np...>
To: <lib...@li...>
Sent: Tuesday, May 11, 2004 5:46 PM
Subject: [P51dev] RE: Vegetation rendering technique


Where do you think one gets a hold of those tree texture "slicings"?  Is
that an actual geometry tree that's been rendered to a texture from many
different angles?



> -----Original Message-----
> From: Kapolka, Andrzej USA
> Sent: Friday, May 07, 2004 10:32 AM
> To: Wells, Dave USA; Rudolph Darken; Johnson, Erik USA
> Cc: Kapolka, Andrzej USA; McDowell, Perry USA; jp.jamieson;
> McDonough, J.P. USA; Prichard, Matt USA; Strom, Mark USA;
> Sullivan, Joseph USA; Ernst, Ryan USA; Tarantilis, George
> GRC; Correia, Steve USA; Salvatore, Ricardo BRA; Pursel, Ray
> USA; Mueller, Aaron USA
> Subject: Re: Vegetation rendering technique
>
>
>      Yeah, that's my guess as well.  I tried the
> (single-player) demo, but the example level is set in the
> desert, and it's a little harder to see the effect on tumbleweeds.  :)
>
>      This may not be exactly the same effect, but it's pretty
> cool, and it shows what mip-mapped/filtered billboards with
> alpha textures look like in the distance compared to the
> equivalent geometry (if you run compare-original.bat).  I
> wonder if Battlefield 1942 also blurs the mip-maps...
>
>      http://zeus.fri.uni-lj.si/~aleks/slicing-and-blending/
>
>      The downside of that approach is that it uses lots of
> textures (30 just for that tree), and it looks unnatural
> up-close from certain angles.
>
>      --Andrzej
>
> ----- Original Message -----
> From: "Wells, Dave USA" <wd...@np...>
> To: "Rudolph Darken" <da...@re...>; "Johnson, Erik USA"
> <rej...@np...>
> Cc: "Kapolka, Andrzej USA" <ak...@np...>; "McDowell, Perry USA"
> <mcd...@np...>; "jp.jamieson" <jp....@co...>;
> "McDonough, J.P. USA" <jpm...@np...>; "Prichard, Matt
> USA" <pri...@np...>; "Strom, Mark USA"
> <mw...@np...>; "Sullivan, Joseph USA"
> <jas...@np...>; "Ernst, Ryan USA" <rb...@np...>;
> "Tarantilis, George GRC" <gta...@np...>; "Correia, Steve
> USA" <jco...@np...>; "Salvatore, Ricardo BRA"
> <rsa...@np...>; "Pursel, Ray USA"
> <erp...@np...>; "Mueller, Aaron USA" <ajm...@np...>
> Sent: Friday, May 07, 2004 7:08 AM
> Subject: RE: Vegetation rendering technique
>
>
> > While what Rudy suggests is a valid consideration, I don't
> think it is the
> prime mover in these images... since the distant bunker in
> the first shot is
> still very clear.... and jaggy, which leaves out extreme anti-aliasing
> techniques.  Thus, I still believe that an alpha map is added to the
> branch's texture after the typical transparency channel has
> been set.  In my
> mind, it would be the easiest way to blend in background
> images into the
> scene, producing the fuzzy effect.  I note that in the
> telescoped image, the
> two central twigs (centerline and left of centerline) of the
> bush are mirror
> images of one another.  Thus, the effect seems to be applied
> directly to the
> texture and not solely a distance or viewport issue.  Of
> course, they could
> apply a small series of LOD'd alpha maps so that distant
> objects are very
> blurry and close objects are less so.
> >
> > "Of course, that's just my opinion. I could be wrong."  -
> Dennis Miller
> >
> > Fuzzy.
> >   -----Original Message-----=20
> >   From: Rudolph Darken [mailto:da...@re...]
> >   Sent: Fri 5/7/2004 6:23 AM
> >   To: Johnson, Erik USA
> >   Cc: Kapolka, Andrzej USA; McDowell, Perry USA;
> jp.jamieson; McDonough,
> J.P. USA; Prichard, Matt USA; Strom, Mark USA; Sullivan,
> Joseph USA; Ernst,
> Ryan USA; Tarantilis, George GRC; Wells, Dave USA; Correia, Steve USA;
> Salvatore, Ricardo BRA; Pursel, Ray USA; Mueller, Aaron USA
> >   Subject: Re: Vegetation rendering technique
> >
> >
> >   How does this idea relate to the depth of field demo that
> Fuzzy showed
> us on the new ATI cards? Duplicating this in P-51 is probably
> not the only
> issue ... doing it without a significant performance hit is critical.
> >
> >
> >   rudy
> >
> >
> >
> >
> >   On May 6, 2004, at 4:43 PM, Johnson, Erik USA wrote:
> >
> >
> >     This is the phenomena that I was speaking of yesterday.
>  In the game
> Battlefield 1942, the vegetation gets rendered, well, fuzzy.
> Feel free to
> download the one of the 1942 demos and see it for yourself.
> >     The first person to duplicate this behavior in P51 wins a free
> T-Shirt*.
> >
> http://www.nps.navy.mil/cs/Research/vissim/MOUT/Reference%20Im
> ages/thumbnails/index.htm
> >     -Erik
> >     *T-Shirt limited to stock on hand.
> >
> >
> >     __________________________
> >     Erik Johnson
> >     Lead Software Engineer
> >     MOVES Institute
> >     (831) 656-2967
> >     rejohnso at nps<dot>navy<dot>mil
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=3Ddnemail3
_______________________________________________
LibGF-P51Dev mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libgf-p51dev



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to=20
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
_______________________________________________
LibGF-P51Dev mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libgf-p51dev

RE: [P51dev] Gamasutra article on fast blurring

[Johnson, E. U. <rej...@np...>]

Interesting...  Isn't this closely related to an "imposter"?  That is,
replacing actual geometry with a billboard that's textured to look like
the geometry?

Hmm...OSG has billboard...and render to texture functionality...


Thanks for the link!



-----Original Message-----
From: lib...@li...
[mailto:lib...@li...] On Behalf Of Kapolka,
Andrzej USA
Sent: Thursday, May 13, 2004 4:51 PM
To: lib...@li...
Subject: [P51dev] Gamasutra article on fast blurring

All--

     I ran across a Gamasutra article on fast blurring techniques.  The
last
of the four tricks presented might be the one they used in Battlefield
1942.

     http://www.gamasutra.com/features/20010209/evans_01.htm

     --Andrzej

=3D-----
Andrzej Kapolka
The MOVES Institute
Naval Postgraduate School
M.E. Annex 280, (831) 656-2265
------=3D



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick
_______________________________________________
LibGF-P51Dev mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libgf-p51dev

[P51dev] Gamasutra article on fast blurring

[Andrzej K. <ak...@np...>]

All--

     I ran across a Gamasutra article on fast blurring techniques.  The last
of the four tricks presented might be the one they used in Battlefield 1942.

     http://www.gamasutra.com/features/20010209/evans_01.htm

     --Andrzej

=-----
Andrzej Kapolka
The MOVES Institute
Naval Postgraduate School
M.E. Annex 280, (831) 656-2265
------=

[P51dev] P-51 Online Name Survey

[Johnson, E. U. <rej...@np...>]

Please vote for your favorite project name at:
=20
http://www.opinionpower.com/Surveys/161014976.html
=20
Thanks!
-Erik
=20
(Sorry if you received this message twice.  I want to make sure it got
to everyone!)
=20
=20
__________________________
Erik Johnson
Lead Software Engineer
MOVES Institute
(831) 656-2967
rejohnso at nps<dot>navy<dot>mil
=20
=20

RE: [P51dev] RE: Vegetation rendering technique

[Prichard, M. U. <pri...@np...>]

The impression I got from skimming the article was the "slicings" were
rendered from an actual model. So you have to have the chicken before
the egg sort of thing.
-matt

-----Original Message-----
From: lib...@li...
[mailto:lib...@li...] On Behalf Of Kapolka,
Andrzej USA
Sent: Wednesday, May 12, 2004 10:14 AM
To: lib...@li...
Subject: Re: [P51dev] RE: Vegetation rendering technique


     Yes.  The demo shows the original tree mesh for comparison.  Even
in
the slicing approach, the trunk is still rendered as a mesh.

     --Andrzej

----- Original Message -----=20
From: "Johnson, Erik USA" <rej...@np...>
To: <lib...@li...>
Sent: Tuesday, May 11, 2004 5:46 PM
Subject: [P51dev] RE: Vegetation rendering technique


Where do you think one gets a hold of those tree texture "slicings"?  Is
that an actual geometry tree that's been rendered to a texture from many
different angles?



> -----Original Message-----
> From: Kapolka, Andrzej USA
> Sent: Friday, May 07, 2004 10:32 AM
> To: Wells, Dave USA; Rudolph Darken; Johnson, Erik USA
> Cc: Kapolka, Andrzej USA; McDowell, Perry USA; jp.jamieson;
> McDonough, J.P. USA; Prichard, Matt USA; Strom, Mark USA;
> Sullivan, Joseph USA; Ernst, Ryan USA; Tarantilis, George
> GRC; Correia, Steve USA; Salvatore, Ricardo BRA; Pursel, Ray
> USA; Mueller, Aaron USA
> Subject: Re: Vegetation rendering technique
>
>
>      Yeah, that's my guess as well.  I tried the
> (single-player) demo, but the example level is set in the
> desert, and it's a little harder to see the effect on tumbleweeds.  :)
>
>      This may not be exactly the same effect, but it's pretty
> cool, and it shows what mip-mapped/filtered billboards with
> alpha textures look like in the distance compared to the
> equivalent geometry (if you run compare-original.bat).  I
> wonder if Battlefield 1942 also blurs the mip-maps...
>
>      http://zeus.fri.uni-lj.si/~aleks/slicing-and-blending/
>
>      The downside of that approach is that it uses lots of
> textures (30 just for that tree), and it looks unnatural
> up-close from certain angles.
>
>      --Andrzej
>
> ----- Original Message -----
> From: "Wells, Dave USA" <wd...@np...>
> To: "Rudolph Darken" <da...@re...>; "Johnson, Erik USA"
> <rej...@np...>
> Cc: "Kapolka, Andrzej USA" <ak...@np...>; "McDowell, Perry USA"
> <mcd...@np...>; "jp.jamieson" <jp....@co...>;
> "McDonough, J.P. USA" <jpm...@np...>; "Prichard, Matt
> USA" <pri...@np...>; "Strom, Mark USA"
> <mw...@np...>; "Sullivan, Joseph USA"
> <jas...@np...>; "Ernst, Ryan USA" <rb...@np...>;
> "Tarantilis, George GRC" <gta...@np...>; "Correia, Steve
> USA" <jco...@np...>; "Salvatore, Ricardo BRA"
> <rsa...@np...>; "Pursel, Ray USA"
> <erp...@np...>; "Mueller, Aaron USA" <ajm...@np...>
> Sent: Friday, May 07, 2004 7:08 AM
> Subject: RE: Vegetation rendering technique
>
>
> > While what Rudy suggests is a valid consideration, I don't
> think it is the
> prime mover in these images... since the distant bunker in
> the first shot is
> still very clear.... and jaggy, which leaves out extreme anti-aliasing
> techniques.  Thus, I still believe that an alpha map is added to the
> branch's texture after the typical transparency channel has
> been set.  In my
> mind, it would be the easiest way to blend in background
> images into the
> scene, producing the fuzzy effect.  I note that in the
> telescoped image, the
> two central twigs (centerline and left of centerline) of the
> bush are mirror
> images of one another.  Thus, the effect seems to be applied
> directly to the
> texture and not solely a distance or viewport issue.  Of
> course, they could
> apply a small series of LOD'd alpha maps so that distant
> objects are very
> blurry and close objects are less so.
> >
> > "Of course, that's just my opinion. I could be wrong."  -
> Dennis Miller
> >
> > Fuzzy.
> >   -----Original Message-----=20
> >   From: Rudolph Darken [mailto:da...@re...]
> >   Sent: Fri 5/7/2004 6:23 AM
> >   To: Johnson, Erik USA
> >   Cc: Kapolka, Andrzej USA; McDowell, Perry USA;
> jp.jamieson; McDonough,
> J.P. USA; Prichard, Matt USA; Strom, Mark USA; Sullivan,
> Joseph USA; Ernst,
> Ryan USA; Tarantilis, George GRC; Wells, Dave USA; Correia, Steve USA;
> Salvatore, Ricardo BRA; Pursel, Ray USA; Mueller, Aaron USA
> >   Subject: Re: Vegetation rendering technique
> >
> >
> >   How does this idea relate to the depth of field demo that
> Fuzzy showed
> us on the new ATI cards? Duplicating this in P-51 is probably
> not the only
> issue ... doing it without a significant performance hit is critical.
> >
> >
> >   rudy
> >
> >
> >
> >
> >   On May 6, 2004, at 4:43 PM, Johnson, Erik USA wrote:
> >
> >
> >     This is the phenomena that I was speaking of yesterday.
>  In the game
> Battlefield 1942, the vegetation gets rendered, well, fuzzy.
> Feel free to
> download the one of the 1942 demos and see it for yourself.
> >     The first person to duplicate this behavior in P51 wins a free
> T-Shirt*.
> >
> http://www.nps.navy.mil/cs/Research/vissim/MOUT/Reference%20Im
> ages/thumbnails/index.htm
> >     -Erik
> >     *T-Shirt limited to stock on hand.
> >
> >
> >     __________________________
> >     Erik Johnson
> >     Lead Software Engineer
> >     MOVES Institute
> >     (831) 656-2967
> >     rejohnso at nps<dot>navy<dot>mil
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=3Ddnemail3
_______________________________________________
LibGF-P51Dev mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libgf-p51dev



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to=20
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
_______________________________________________
LibGF-P51Dev mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libgf-p51dev

Re: [P51dev] RE: Vegetation rendering technique

[Andrzej K. <ak...@np...>]

     Yes.  The demo shows the original tree mesh for comparison.  Even in
the slicing approach, the trunk is still rendered as a mesh.

     --Andrzej

----- Original Message ----- 
From: "Johnson, Erik USA" <rej...@np...>
To: <lib...@li...>
Sent: Tuesday, May 11, 2004 5:46 PM
Subject: [P51dev] RE: Vegetation rendering technique


Where do you think one gets a hold of those tree texture "slicings"?  Is
that an actual geometry tree that's been rendered to a texture from many
different angles?



> -----Original Message-----
> From: Kapolka, Andrzej USA
> Sent: Friday, May 07, 2004 10:32 AM
> To: Wells, Dave USA; Rudolph Darken; Johnson, Erik USA
> Cc: Kapolka, Andrzej USA; McDowell, Perry USA; jp.jamieson;
> McDonough, J.P. USA; Prichard, Matt USA; Strom, Mark USA;
> Sullivan, Joseph USA; Ernst, Ryan USA; Tarantilis, George
> GRC; Correia, Steve USA; Salvatore, Ricardo BRA; Pursel, Ray
> USA; Mueller, Aaron USA
> Subject: Re: Vegetation rendering technique
>
>
>      Yeah, that's my guess as well.  I tried the
> (single-player) demo, but the example level is set in the
> desert, and it's a little harder to see the effect on tumbleweeds.  :)
>
>      This may not be exactly the same effect, but it's pretty
> cool, and it shows what mip-mapped/filtered billboards with
> alpha textures look like in the distance compared to the
> equivalent geometry (if you run compare-original.bat).  I
> wonder if Battlefield 1942 also blurs the mip-maps...
>
>      http://zeus.fri.uni-lj.si/~aleks/slicing-and-blending/
>
>      The downside of that approach is that it uses lots of
> textures (30 just for that tree), and it looks unnatural
> up-close from certain angles.
>
>      --Andrzej
>
> ----- Original Message -----
> From: "Wells, Dave USA" <wd...@np...>
> To: "Rudolph Darken" <da...@re...>; "Johnson, Erik USA"
> <rej...@np...>
> Cc: "Kapolka, Andrzej USA" <ak...@np...>; "McDowell, Perry USA"
> <mcd...@np...>; "jp.jamieson" <jp....@co...>;
> "McDonough, J.P. USA" <jpm...@np...>; "Prichard, Matt
> USA" <pri...@np...>; "Strom, Mark USA"
> <mw...@np...>; "Sullivan, Joseph USA"
> <jas...@np...>; "Ernst, Ryan USA" <rb...@np...>;
> "Tarantilis, George GRC" <gta...@np...>; "Correia, Steve
> USA" <jco...@np...>; "Salvatore, Ricardo BRA"
> <rsa...@np...>; "Pursel, Ray USA"
> <erp...@np...>; "Mueller, Aaron USA" <ajm...@np...>
> Sent: Friday, May 07, 2004 7:08 AM
> Subject: RE: Vegetation rendering technique
>
>
> > While what Rudy suggests is a valid consideration, I don't
> think it is the
> prime mover in these images... since the distant bunker in
> the first shot is
> still very clear.... and jaggy, which leaves out extreme anti-aliasing
> techniques.  Thus, I still believe that an alpha map is added to the
> branch's texture after the typical transparency channel has
> been set.  In my
> mind, it would be the easiest way to blend in background
> images into the
> scene, producing the fuzzy effect.  I note that in the
> telescoped image, the
> two central twigs (centerline and left of centerline) of the
> bush are mirror
> images of one another.  Thus, the effect seems to be applied
> directly to the
> texture and not solely a distance or viewport issue.  Of
> course, they could
> apply a small series of LOD'd alpha maps so that distant
> objects are very
> blurry and close objects are less so.
> >
> > "Of course, that's just my opinion. I could be wrong."  -
> Dennis Miller
> >
> > Fuzzy.
> >   -----Original Message----- 
> >   From: Rudolph Darken [mailto:da...@re...]
> >   Sent: Fri 5/7/2004 6:23 AM
> >   To: Johnson, Erik USA
> >   Cc: Kapolka, Andrzej USA; McDowell, Perry USA;
> jp.jamieson; McDonough,
> J.P. USA; Prichard, Matt USA; Strom, Mark USA; Sullivan,
> Joseph USA; Ernst,
> Ryan USA; Tarantilis, George GRC; Wells, Dave USA; Correia, Steve USA;
> Salvatore, Ricardo BRA; Pursel, Ray USA; Mueller, Aaron USA
> >   Subject: Re: Vegetation rendering technique
> >
> >
> >   How does this idea relate to the depth of field demo that
> Fuzzy showed
> us on the new ATI cards? Duplicating this in P-51 is probably
> not the only
> issue ... doing it without a significant performance hit is critical.
> >
> >
> >   rudy
> >
> >
> >
> >
> >   On May 6, 2004, at 4:43 PM, Johnson, Erik USA wrote:
> >
> >
> >     This is the phenomena that I was speaking of yesterday.
>  In the game
> Battlefield 1942, the vegetation gets rendered, well, fuzzy.
> Feel free to
> download the one of the 1942 demos and see it for yourself.
> >     The first person to duplicate this behavior in P51 wins a free
> T-Shirt*.
> >
> http://www.nps.navy.mil/cs/Research/vissim/MOUT/Reference%20Im
> ages/thumbnails/index.htm
> >     -Erik
> >     *T-Shirt limited to stock on hand.
> >
> >
> >     __________________________
> >     Erik Johnson
> >     Lead Software Engineer
> >     MOVES Institute
> >     (831) 656-2967
> >     rejohnso at nps<dot>navy<dot>mil
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=dnemail3
_______________________________________________
LibGF-P51Dev mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libgf-p51dev

[P51dev] RE: Vegetation rendering technique

[Johnson, E. U. <rej...@np...>]

Where do you think one gets a hold of those tree texture "slicings"?  Is
that an actual geometry tree that's been rendered to a texture from many
different angles?



> -----Original Message-----
> From: Kapolka, Andrzej USA=20
> Sent: Friday, May 07, 2004 10:32 AM
> To: Wells, Dave USA; Rudolph Darken; Johnson, Erik USA
> Cc: Kapolka, Andrzej USA; McDowell, Perry USA; jp.jamieson;=20
> McDonough, J.P. USA; Prichard, Matt USA; Strom, Mark USA;=20
> Sullivan, Joseph USA; Ernst, Ryan USA; Tarantilis, George=20
> GRC; Correia, Steve USA; Salvatore, Ricardo BRA; Pursel, Ray=20
> USA; Mueller, Aaron USA
> Subject: Re: Vegetation rendering technique
>=20
>=20
>      Yeah, that's my guess as well.  I tried the=20
> (single-player) demo, but the example level is set in the=20
> desert, and it's a little harder to see the effect on tumbleweeds.  :)
>=20
>      This may not be exactly the same effect, but it's pretty=20
> cool, and it shows what mip-mapped/filtered billboards with=20
> alpha textures look like in the distance compared to the=20
> equivalent geometry (if you run compare-original.bat).  I=20
> wonder if Battlefield 1942 also blurs the mip-maps...
>=20
>      http://zeus.fri.uni-lj.si/~aleks/slicing-and-blending/
>=20
>      The downside of that approach is that it uses lots of=20
> textures (30 just for that tree), and it looks unnatural=20
> up-close from certain angles.
>=20
>      --Andrzej
>=20
> ----- Original Message -----
> From: "Wells, Dave USA" <wd...@np...>
> To: "Rudolph Darken" <da...@re...>; "Johnson, Erik USA"
> <rej...@np...>
> Cc: "Kapolka, Andrzej USA" <ak...@np...>; "McDowell, Perry USA"
> <mcd...@np...>; "jp.jamieson" <jp....@co...>;=20
> "McDonough, J.P. USA" <jpm...@np...>; "Prichard, Matt=20
> USA" <pri...@np...>; "Strom, Mark USA"=20
> <mw...@np...>; "Sullivan, Joseph USA"
> <jas...@np...>; "Ernst, Ryan USA" <rb...@np...>;=20
> "Tarantilis, George GRC" <gta...@np...>; "Correia, Steve=20
> USA" <jco...@np...>; "Salvatore, Ricardo BRA"=20
> <rsa...@np...>; "Pursel, Ray USA"
> <erp...@np...>; "Mueller, Aaron USA" <ajm...@np...>
> Sent: Friday, May 07, 2004 7:08 AM
> Subject: RE: Vegetation rendering technique
>=20
>=20
> > While what Rudy suggests is a valid consideration, I don't=20
> think it is the
> prime mover in these images... since the distant bunker in=20
> the first shot is
> still very clear.... and jaggy, which leaves out extreme anti-aliasing
> techniques.  Thus, I still believe that an alpha map is added to the
> branch's texture after the typical transparency channel has=20
> been set.  In my
> mind, it would be the easiest way to blend in background=20
> images into the
> scene, producing the fuzzy effect.  I note that in the=20
> telescoped image, the
> two central twigs (centerline and left of centerline) of the=20
> bush are mirror
> images of one another.  Thus, the effect seems to be applied=20
> directly to the
> texture and not solely a distance or viewport issue.  Of=20
> course, they could
> apply a small series of LOD'd alpha maps so that distant=20
> objects are very
> blurry and close objects are less so.
> >
> > "Of course, that's just my opinion. I could be wrong."  -=20
> Dennis Miller
> >
> > Fuzzy.
> >   -----Original Message-----=20
> >   From: Rudolph Darken [mailto:da...@re...]
> >   Sent: Fri 5/7/2004 6:23 AM
> >   To: Johnson, Erik USA
> >   Cc: Kapolka, Andrzej USA; McDowell, Perry USA;=20
> jp.jamieson; McDonough,
> J.P. USA; Prichard, Matt USA; Strom, Mark USA; Sullivan,=20
> Joseph USA; Ernst,
> Ryan USA; Tarantilis, George GRC; Wells, Dave USA; Correia, Steve USA;
> Salvatore, Ricardo BRA; Pursel, Ray USA; Mueller, Aaron USA
> >   Subject: Re: Vegetation rendering technique
> >
> >
> >   How does this idea relate to the depth of field demo that=20
> Fuzzy showed
> us on the new ATI cards? Duplicating this in P-51 is probably=20
> not the only
> issue ... doing it without a significant performance hit is critical.
> >
> >
> >   rudy
> >
> >
> >
> >
> >   On May 6, 2004, at 4:43 PM, Johnson, Erik USA wrote:
> >
> >
> >     This is the phenomena that I was speaking of yesterday.=20
>  In the game
> Battlefield 1942, the vegetation gets rendered, well, fuzzy. =20
> Feel free to
> download the one of the 1942 demos and see it for yourself.
> >     The first person to duplicate this behavior in P51 wins a free
> T-Shirt*.
> >
> http://www.nps.navy.mil/cs/Research/vissim/MOUT/Reference%20Im
> ages/thumbnails/index.htm
> >     -Erik
> >     *T-Shirt limited to stock on hand.
> >
> >
> >     __________________________
> >     Erik Johnson
> >     Lead Software Engineer
> >     MOVES Institute
> >     (831) 656-2967
> >     rejohnso at nps<dot>navy<dot>mil
>=20
>=20

[P51dev] testInput/ParticleSystem

[Andrzej K. <ak...@np...>]

All--

     I checked in a testInput example that demonstrates how to create a set
of remappable controls using LogicalInputDevice and the new InputMapper
class, which listens to an entire set of devices simultaneously to determine
which feature the user wants to use for the mapping.  Click the buttons next
to the feature names to remap the actions.

     I also checked in a new ParticleSystem class, which should be useful
for persistent effects like smoke trails and wakes (as opposed to
short-lived effects like explosions, for which the EffectManager is better
suited).  ParticleSystem hides the awkwardness of manipulating osgParticle
systems (usually you want to move only the emitter, not the entire group)
behind an interface like that of Object.  You call LoadFile to load a
particle system, SetEnabled to enable or disable the emitter, and
SetParentRelative to enable or disable parent-relative mode (in which, for
example, the smoke coming out of a train's smokestack moves with the train
instead of lingering behind).  ParticleSystem is Transformable, so you can
attach particle systems to Objects, etc.  I added a ParticleSystem to
testEffects to demonstrate.

     --Andrzej

=-----
Andrzej Kapolka
The MOVES Institute
Naval Postgraduate School
M.E. Annex 280, (831) 656-2265
------=

[P51dev] Fw: Network requirements for MMOGs

[Andrzej K. <ak...@np...>]

----- Original Message ----- 
From: "Rudolph P. Darken" <da...@np...>
To: "Andrzej Kapolka" <ak...@np...>
Cc: "Erik Johnson USA" <rej...@np...>
Sent: Monday, April 05, 2004 7:45 PM
Subject: Re: Network requirements for MMOGs


> Andrzej,
> 
> This is great. You should copy this to the P-51 list so it gets 
> archived.
> 
> Thanks!
> rudy
> 
> 
> On Apr 5, 2004, at 1:59 PM, Andrzej Kapolka wrote:
> 
> > Geoff, Ted, Rudy--
> >
> >      Here's an outline of what, from my perspective, an ideal MMOG
> > network would look like, including some very rough numbers.
> >
> >      High scalability is crucial; otherwise, you can't really claim 
> > that the
> > games are "massively multiplayer."  Being able to support hundreds of
> > thousands of entities/clients in the same continuous space would be 
> > ideal.
> > Note that that doesn't mean that everyone receives updates from 
> > hundreds of
> > thousands of entities at once, because that would use far too much 
> > bandwidth
> > and processing power on the client side.  Clients should only receive
> > updates from entities in their areas of interest, which may include 
> > spatial
> > regions ("I only want to know about entities in my house") and 
> > functional
> > categories ("I only want to know about entities as big or bigger than a
> > human being"), among other groupings.  Aggregation is key, too--that 
> > is, the
> > ability to transform updates from several "soldier" entities into one 
> > update
> > from a "squad" entity, and so on.  At the network level, achieving 
> > effective
> > area of interest and aggregation management depends on the ability to
> > rapidly create, destroy, and reorganize distribution groups 
> > (equivalent to
> > multicast groups).  As an example, consider a scenario where a large 
> > number
> > of entities suddently converge on a small spatial region.  Once the 
> > number
> > of entities in that region increases beyond a certain threshold, the
> > application may be forced to subdivide the region into smaller 
> > distribution
> > groups in order to avoid exceeding the clients' bandwidth with entity
> > updates.  Ideally, subdividing the space and notifying all affected 
> > clients
> > shouldn't take more than 500ms or so.
> >
> >      Low latency is important for most multiplayer games.  Ideally, an
> > update sent from one client should reach all clients affected by it in 
> > under
> > 100ms.  The page at http://www.bluesnews.com/guide/lag.htm describes 
> > how
> > latency (ping time) affects gameplay for highly interactive games like
> > Quake.
> >
> >      High bandwidth to client is important for games in which many 
> > highly
> > dynamic (i.e., unpredictable) entities interact in the same region of
> > interest, or games where clients must download large amounts of data 
> > from
> > the server (such as terrain files).  Something like 1.5 Mbps (T1 speed)
> > would be ideal.
> >
> >      Security is an issue with any game open to the public.  It's 
> > important
> > to ensure that a malfunctioning or malicious client can't bring the 
> > system
> > down, give a player an unfair advantage, or otherwise corrupt the game.
> > This is more of an application-level issue, but I thought I'd include 
> > it
> > because it also affects the design of the network (it usually rules 
> > out pure
> > peer-to-peer topologies).  Some games may have other security 
> > requirements,
> > such as protecting sensitive information.
> >
> >      So, in summary:
> >
> >      High scalability (100,000 clients)
> >      Rapid reconfigurability (topology changes in 500ms or less)
> >      Low latency (100ms)
> >      High bandwidth (1.5Mbps)
> >      Plus some provisions for trust/security.
> >
> >      --Andrzej
> >
> > =-----
> > Andrzej Kapolka
> > The MOVES Institute
> > Naval Postgraduate School
> > M.E. Annex 280, (831) 656-2265
> > ------=
> >
> >
> 

[P51dev] New External Dep's (0.0.7)

[Johnson, E. U. <rej...@np...>]

Hi all,=20
=20
Just uploaded a new external depencency release which includes the GUI
files.  Get yours now at:
=20
https://sourceforge.net/project/showfiles.php?group_id=3D50340&package_id=
=3D
66332
=20
=20
Update your local CVS copy and you will find a new class for handling
the GUI as well as a testGUI project.
=20
=20
=20

[P51dev] New External Dependencies

[Johnson, E. U. <rej...@np...>]

Just uploaded the lastest version of the external dependencies (0.0.5).
You'll need this to use the new P51 Character Library.
=20
Here are the changes:
Version 0.0.5
-Pulled RTI library
-Upgraded TinyXML to 2.2.1
-Added ReplicantBody, CAL3D, ConfigScript

=20

[P51dev] P51 Application Base Component Library

[Johnson, E. U. <rej...@np...>]

Just wanted to announce the birth of the P51 Application Base Components
Library ("P-51ABC").   This separate library will contain higher level
functionality by combining the lower level P51 pieces together.  Think
"Application-level" features versus low level features.
=20
The first piece included in this library is the P51ABC::Application
class.  This is a very generic, base application that will be extended
and tweaked as time goes on. Right now, all it does is tie the Camera,
Scene, and Window together.  Additional features will include mapping
input devices to user-defined "actions" as well as adding hooks for
user-defined routines.
=20
The P51ABC Library will eventually also contain such high level
components such as drop-in Environments, networking strategies, and menu
systems.
=20
Thats all for now!
=20