npsnetv-developers — Development discussion.

[npsnetv-developers] VRML does not show anymore

[luciano F. <luc...@ya...>]

Hello Folks

   I'm wondering if anything has changed in npsnetv
since the last couple days. I installed last week the
platform in my PC. Everything was working fine but for
some reason, since Monday that I cannot see any VRML
based Entity.

    I have even tried to install everything again, but
I keep gettting the error message below. For example,
when I try running the standalone application, here is
what I get:

Started /moduleContainer/j3dViewCore
Initialized
/moduleContainer/j3dViewCore/standardHeavenlyBodyView
Initialized
/moduleContainer/j3dViewCore/basicObjectView
Error applying
resource:/org/npsnet/v/entities/examples/Teapot.xml:
<Set> elemen
t contains invalid value for 'value' attribute:
'resource:///org/npsnet/v/views/
examples/teapot.wrl'
Initialized /moduleContainer/awtControllerCore
Started /moduleContainer/awtControllerCore
Initialized
/moduleContainer/awtControllerCore/pilotableCameraController
Initialized
/moduleContainer/awtControllerCore/mouseContextMenuController


  Does anyone have any idea on why this is happening?

    Thanks in advance

       Luciano Fagundes

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [npsnetv-developers] RE: Plans for NPSNET-V

[Justin C. <ju...@vl...>]

Andrzej Kapolka wrote:

>      That wouldn't quite work; they're not getting or setting system
> properties, they're just generating instances of the Properties class,
> populating them with the contents of the resources, and reading the
> properties from there.

We're also using it to locate on-disk versions of the DTDs to save doing 
remote resolution and a few other things like that too. Also, just gone 
into the build recently is the requirement for JMF to be installed as 
well so that we can handle the MovieTexture node. Adding to the list of 
things that would prevent us from doing dynamic loading are our own 
thread management, own custom network connection handling, creating our 
own ClassLoader instances and a lot more along those lines. Basically 
it's a case of Xj3D has to be installed in jre/lib/ext otherwise it 
won't be able to function. Gets worse too once we start including native 
code for Dome handling and other input devices.

-- 
Justin Couch                         http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler              http://www.yumetech.com/
Author, Java 3D FAQ Maintainer                  http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                               - Greg Bear, Slant
-------------------------------------------------------------------

Re: [npsnetv-developers] RE: Plans for NPSNET-V

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

----- Original Message -----
From: "Harney, James USA" <jwh...@np...>
To: "Kapolka, Andrzej USA" <ak...@np...>; "Couch, Justin"
<ju...@vl...>
Cc: "NPSNET-V" <nps...@li...>; "Savage"
<sa...@np...>
Sent: Tuesday, February 25, 2003 5:11 AM
Subject: [npsnetv-developers] RE: Plans for NPSNET-V


>     Would setting the various xj3d System properties in the first class
downloaded in WebStart make it play nice

     That wouldn't quite work; they're not getting or setting system
properties, they're just generating instances of the Properties class,
populating them with the contents of the resources, and reading the
properties from there.

     --Andrzej

[npsnetv-developers] RE: Plans for NPSNET-V

[Harney, J. U. <jwh...@np...>]

SnVzdGluL0FuZHJ6ZWosDQogICAgV291bGQgc2V0dGluZyB0aGUgdmFyaW91cyB4ajNkIFN5c3Rl
bSBwcm9wZXJ0aWVzIGluIHRoZSBmaXJzdCBjbGFzcyBkb3dubG9hZGVkIGluIFdlYlN0YXJ0IG1h
a2UgaXQgcGxheSBuaWNlIHdpdGhvdXQgbW9kIHRvIHRoZSBjb2RlIGJhc2Ugb3IgaXMgdGhlIG1v
ZCBBbmRyZXpqIG1lbnRpb25lZCBhIG5lY2Vzc2FyeSByZXF1aXJlbWVudCBpbiBvcmRlciB0byBk
byB0aGlzPw0KQmlnZ2VyIHBpY3R1cmUgYXMgSSBzZWUgaXQgaXMgdGhhdCB3ZSBoYXZlIHRocmVl
IGRpZmZlcmVudCBkZXBsb3ltZW50IG5lZWRzIGdlbmVyYWxseSBiYXNlZCBvbiB0aGUgYXZhaWxh
YmlsaXR5IG9mIHRoZSBjbGllbnQgbWFjaGluZXM6DQoxIC0gQ3VycmVudCBhcHBsaWNhdGlvbiBi
YXNlZCBhbmQgdGhlIHNvb24gdG8gYmUgcmVsZWFzZWQgYXBwbGV0aXplZCBmbGF2b3JzIG9mIHRo
ZSB4ajNkIGNsaWVudC4gIEdvb2QgZm9yIGZvbGtzIHRoYXQgaGF2ZSBwZXJtaXNzaW9ucyB0byBs
b2FkIGFwcHMgb24gdGhlaXIgY29tcHV0ZXIuICBGb3IgdGhlIG5hdnkgbWVhbnMgbW9zdGx5IHNo
b3JlIGR1dHkgdHlwZXMuIA0KMiAtIFdlYnN0YXJ0IGZsYXZvcnMgb2YgTlBTTkVULVYgYW5kIHRo
ZSBjbGllbnQgZm9yIHRoZSB0aW1lcyB3aGVuIHdlIGNhbiBvbmx5IGdldCBwZXJtaXNzaW9uIHRv
IGhhdmUgd2Vic3RhcnQgYW5kIHRoZSBkaXJlY3RvcmllcyB3aGVyZSBpdCBzdG9yZXMgYXBwcyBi
dXQgbm8gb3RoZXIgcGVybWlzc2lvbiB0byBsb2FkIHVwIHN0dWZmLiAgVGhpbmsgS2VuIG9uIHRo
ZSBTYXZhZ2UgbGlzdCBrbm93cyBtb3JlIG9uIHRoZSBwYWluL3JlZHRhcGUgcmVxdWlyZWQgdG8g
Z2V0IHBlcm1pc3Npb24gdG8gbG9hZCBhcHBzIHRocm91Z2ggdGhlIG5hdnkgc3lzdGVtLCBidXQg
c2ltaWxhciBwYWluIHJlY2VudGx5IGV4cGVyaWVuY2VkIGJ5IERvbiBpbiB0aGUgY2l2aWxpYW4g
c2VjdG9yIG9uIHRyYXZlbCB0cnlpbmcgdG8gZ2V0IHN0dWZmIGxvYWRlZCBvbiBvbmUgb2YgaGlz
IGNvbGxlYWd1ZXMgbWFjaGllbnMuDQozIC0gUnVubmluZyBhcyBhbiBhcHBsaWNhdGlvbiB3aXRo
IGEgbG9jYWxseSByZWZlcmVuY2VkIGpyZS4gIEJpdCBlYXNpZXIgdGhhbiAjMSBzaW5jZSB3ZSBv
bmx5IHdvcnJ5IGFib3V0IHBlcm1pc3Npb24gZm9yIGluc3RhbGxpbmcgMSB0aGluZywgdmljZSAz
IChqMnNkaywgajNkLCBhbmQgdGhlbiB0aGUgY2xpZW50KS4gIA0KIA0KV2UndmUgYmFzaWNhbGx5
IGJlZW4gbG9va2luZy91c2luZyB0aGUgY29kZWJhc2UgaW4gMiByZWdhcmRzLiAgMSBhcyB1c2Ug
YXMgdGhlIHJlbmRlcmluZyBlbmdpbmUgYmVoaW5kIGEgaGVhdmllciB3ZWlnaHQgY2xpZW50L2Zy
YW1ld29yayBpbiBOUFNORVQtViB3aGljaCBjYW4gdGhlbiBiZSB1c2VkIHRvIGRyaXZlIHZpYSBu
ZXR3b3JraW5nIG90aGVyIGNvbXBvbmVudCBiYXNlZCBjbGllbnRzIG9yIGxpZ2h0ZXJ3ZWlnaHQg
Y2xpZW50cyB1c2luZyB0aGUgWGozRCBicm93c2VyIG9yIGRlcml2YXRpb25zIG9mIGFzIHRoZWly
IHZpZXcgaW4gdGhlIGFwcGxpY2F0aW9uL2FwcGxldC93ZWJzdGFydCBjb250ZXh0LiAgDQogDQpK
YW1lcw0KIA0KDQoJPiBBbmRyemVqIEthcG9sa2Egd3JvdGU6DQoJPiA+IEFsYW4sIEp1c3Rpbi0t
DQoJPiA+DQoJPiA+ICAgICAgU2VlIGJlbG93LiAgSXMgdGhlcmUgYW55IHBhcnRpY3VsYXIgcmVh
c29uIHlvdSB1c2UNCgk+ID4gQ2xhc3NMb2FkZXIuZ2V0U3lzdGVtUmVzb3VyY2VBc1N0cmVhbSwg
YXMgb3Bwb3NlZCB0bw0KCT4gPiBnZXRDbGFzcygpLmdldFJlc291cmNlQXNTdHJlYW0sIHRvIGxv
YWQgdGhlIHZhcmlvdXMgcHJvcGVydHkgZmlsZXMgZm9yDQoJeGozZD8NCgk+DQoJPiBZZXMsIHdl
IG9ubHkgd2FudCB0byBsb2FkIGZyb20gdGhlIHNwZWNpZmljYWxseSBkZXNpZ25hdGVkIGZpbGVz
IHdlIGdpdmUNCgk+IGl0LiBUaGV5J3JlIHN5c3RlbSBsZXZlbCByZXNvdXJjZXMsIG5vdCBsb2Nh
bCBhbmQgc28gcmVxdWlyZSB0aGUgdXNlIG9mDQoJPiB0aGUgc3lzdGVtIHJlc291cmNlLiBJbiB0
aGUgbGF0ZXIgY2FzZSBpdCBjYW4gb25seSBsb2FkIGxvY2FsIHN0dWZmIGZyb20NCgk+IHRoZSBz
YW1lIEpBUiBmaWxlLCB3aGljaCBpcyBub3Qgd2hhdCB3ZSBuZWVkIGZvciB0aGUgYXBwbGljYXRp
b24gdG8gcnVuLg0KCT4NCgk+IFhqM0QgaXMgbm90IGRlc2lnbmVkIHRvIGJlIGR5bmFtaWNhbGx5
IGxvYWRlZC4gSXQgbWFrZXMgdmVyeSBoZWF2eSB1c2UNCgk+IG9mIGEgbG90IG9mIHJlc3RyaWN0
ZWQgYWNjZXNzIG1lY2hhbmlzbXMgd2hpY2ggY2FuIG9ubHkgYmUgYWxsb3dlZA0KCT4gdGhyb3Vn
aCBoYXZpbmcgaXQgaW5zdGFsbGVkIGluIHRoZSBsaWIvZXh0IGRpcmVjdG9yeS4gSXQgbXVzdCBi
ZQ0KCT4gaW5zdGFsbGVkIG9uIHRoZSB1c2VyJ3MgbWFjaGluZSB0byBmdW5jdGlvbiBjb3JyZWN0
bHkuDQoJPg0KCT4gLS0NCgk+IEp1c3RpbiBDb3VjaCAgICAgICAgICAgICAgICAgICAgICAgICBo
dHRwOi8vd3d3LnZsYy5jb20uYXUvfmp1c3Rpbi8NCgk+IEphdmEgQXJjaGl0ZWN0ICYgQml0IFR3
aWRkbGVyICAgICAgICAgICAgICBodHRwOi8vd3d3Lnl1bWV0ZWNoLmNvbS8NCgk+IEF1dGhvciwg
SmF2YSAzRCBGQVEgTWFpbnRhaW5lciAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuajNkLm9y
Zy8NCgk+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCgk+ICJIdW1hbmlzbSBpcyBkZWFkLiBBbmltYWxzIHRoaW5rLCBm
ZWVsOyBzbyBkbyBtYWNoaW5lcyBub3cuDQoJPiBOZWl0aGVyIG1hbiBub3Igd29tYW4gaXMgdGhl
IG1lYXN1cmUgb2YgYWxsIHRoaW5ncy4gRXZlcnkgb3JnYW5pc20NCgk+IHByb2Nlc3NlcyBkYXRh
IGFjY29yZGluZyB0byBpdHMgZG9tYWluLCBpdHMgZW52aXJvbm1lbnQ7IHlvdSwgd2l0aA0KCT4g
YWxsIHlvdXIgYnJhaW5zLCB3b3VsZCBiZSB1c2VsZXNzIGluIGEgbW91c2UncyB1bml2ZXJzZS4u
LiINCgk+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSBH
cmVnIEJlYXIsIFNsYW50DQoJPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJPg0KCQ0KCQ0KDQo=

[npsnetv-developers] Re: Plans for NPSNET-V

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

Justin--

     OK, that's pretty much the response I expected.

     In that case, I'd say that for NPSNET-V, we'll probably just switch
back to the VRML loader we used to use: vrml97.jar (a Rick Goldberg
invention, I believe?).  That one was about 300k (as opposed to 2.5 megs for
Xj3D), basically loaded everything we needed, and was easy to load
dynamically.  I forget why exactly we switched to Xj3D, but I think it was
more a show of solidarity than an actual need for any of Xj3D's features.

     The only sticking point here would be making sure that we can support
James H. and Ekrem's VRML content (mostly ships and terrain).  If need be,
we can do one "fork it and forget it" build of Xj3D, since the necessary
changes are easy to make (the below, and a slight change to Justin's URI
library to allow it to load protocol handlers from jar files), but it's not
worth throwing good effort after bad by maintaining a fork.  James and Ekrem
are graduating this quarter; if any future students want to use VRML models
with scripts and what-not from within NPSNET-V, we can always resurrect
support for the Xj3D loader.

     --Andrzej

----- Original Message -----
From: "Justin Couch" <ju...@vl...>
To: "Andrzej Kapolka" <ak...@np...>
Sent: Monday, February 24, 2003 1:46 PM
Subject: Re: Plans for NPSNET-V


> Andrzej Kapolka wrote:
> > Alan, Justin--
> >
> >      See below.  Is there any particular reason you use
> > ClassLoader.getSystemResourceAsStream, as opposed to
> > getClass().getResourceAsStream, to load the various property files for
xj3d?
>
> Yes, we only want to load from the specifically designated files we give
> it. They're system level resources, not local and so require the use of
> the system resource. In the later case it can only load local stuff from
> the same JAR file, which is not what we need for the application to run.
>
> Xj3D is not designed to be dynamically loaded. It makes very heavy use
> of a lot of restricted access mechanisms which can only be allowed
> through having it installed in the lib/ext directory. It must be
> installed on the user's machine to function correctly.
>
> --
> Justin Couch                         http://www.vlc.com.au/~justin/
> Java Architect & Bit Twiddler              http://www.yumetech.com/
> Author, Java 3D FAQ Maintainer                  http://www.j3d.org/
> -------------------------------------------------------------------
> "Humanism is dead. Animals think, feel; so do machines now.
> Neither man nor woman is the measure of all things. Every organism
> processes data according to its domain, its environment; you, with
> all your brains, would be useless in a mouse's universe..."
>                                                - Greg Bear, Slant
> -------------------------------------------------------------------
>

[npsnetv-developers] Re: Plans for NPSNET-V

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

----- Original Message -----
From: "Harney, James USA" <jwh...@np...>
To: "Kapolka, Andrzej USA" <ak...@np...>; "Savage"
<sa...@np...>
Sent: Monday, February 24, 2003 6:48 AM
Subject: RE: Plans for NPSNET-V


>   ****Back in Jan I was trying to do this, but kept getting exceptions
thrown on loading the 5-6 properties files Alan and Justin use in the
codebase when trying to load a j3d view in webstart.  All manners of cp and
proerty file placement hacking attempted.  Single xj3d.jar and multi-jar
tried as well.  Think the bootstrap method you've gone to is best for this
deployment option since once the session is intitiated with signed jars, you
can lazily download and cache on the client webstart app as needed.  As you
showed the other week, the GL4Java JCanyon demo is one of the best demos of
using webstart for real time 3D graphics.  Removal of graphics and just
running offscreen had no problem with sockets and self-signing the deployed
jars though.

     Yeah, the properties file problem pops up in NPSNET-V, too, when it
tries to download xj3d.jar for the first time (you can't add jars to the
system classloader, so NPSNET-V downloads the jar to the extensions
directory and loads it through a URLClassLoader).  Did you ask Alan and
Justin about it?  I'll take a look at the xj3d source today and see if I can
find a fix; if I can, I'll e-mail them and encourage them to use it.

     The only reason I would consider using WebStart is because of the
kernel update problem.  The problem is that one of the main ideas behind
NPSNET-V is a complete lie: the idea that the kernel and the basic property
classes (in other words, the contents of the jars that would be installed by
an InstallAnywhere installer) will never change.  In an actual deployed
system, based on a later, more stable version of the NPSNET-V kernel, I
believe it would be possible to maintain that kind of discipline--but for a
research project, it's just not worth the overhead, and I end up changing
the kernel and the property jars all the time.

     Using WebStart would provide a "free" way to ensure that users would
always have the latest version of the kernel and property classes.  The
alternative is basically using a nanokernel, or kernel loader, that would
provide much of the same function as WebStart: it would check some
configurable location for the latest version of the kernel and property
jars, downloading newer versions when necessary, using cached versions
otherwise.  There's some advantage to using the nanokernel approach anyway,
because it would be possible to tie it in to the standard update mechanisms
(i.e., you could upgrade the kernel at run time as soon as you discover a
new version of it--an option that WebStart doesn't provide).

>   *******I didn't realize til Ekrem showed me the other day that his XSFP
basic ship controller can be used for all ships with DIS, etc.  Will update
my example apps to refelect this week, and work with Ekrem on putting in
some of the basic dynamics stuff we've been doing in my thesis the last
month or so.  Think the one thing for an authoring standpoint that would be
really-useful/guiici would be to expose a particle system effects module.
Yumetech's impl has been up and down for use in the x3d/vrml loader, so I'd
say a NPSNET extension with the same params til there's is up would be a
major attractor since most cool effects are done with them after playing
super modeler-tool-master this quarter with Ken, Steve, Ekrem, and Fuzzy.

     I agree, that would be cool, and it might not be too hard to implement.
I'll have to take a look at the parameters that Yumetech's implementation
offers.

     --Andrzej

[npsnetv-developers] Plans for NPSNET-V

[Kapolka, A. U. <ak...@np...>]

All--

     Last week, Don B. asked me to outline for the group my plans for =
NPSNET-V.

     My main priority at the moment is fleshing out the browser/builder =
application.  In the near future, I'd like to get to the point where a =
potential end user can very easily download the browser (using an =
InstallAnywhere installer or WebStart), connect to and participate in =
existing worlds, and create and publish additional worlds.  I'm =
targeting the upcoming CVE-focused special issue of Presence as a paper =
venue.  The title of the paper will be something along the lines of, "A =
Dynamically Extensible Platform for Browsing, Building, Hosting, and =
Publishing Component-Based Networked Virtual Worlds."

     Other priorities mostly involve making sure that it will be =
possible to include engaging content in the worlds.  This means adding =
support for physical modeling (including collision detection and =
response), improved control mechanisms, provisions for user avatars, =
etc.  My vision of success for this is basically NPSNET-IV: a =
multicast-based virtual world with several different types of pilotable =
vehicles, simple terrain, simple area of interest management, etc.

     At some point, I'm going to have to start focusing heavily on my =
thesis project, the XRTI (http://www.npsnet.org/~npsnet/xrti).  When =
complete, this will provide an abstracted, type-safe, extensible means =
of communicating state information between peers that's =
backwards-compatible with the HLA.

     I've also agreed to work with Rudy and his group on their efforts.  =
To this end, I'll probably start attending their meetings on Tuesdays =
instead of the Savage ones.  I'll continue meeting on Friday with Brian, =
Don M., and anyone else interested in discussing NPSNET-V on a regular =
basis.

     --Andrzej

Re: [npsnetv-developers] Linux Test Results

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

----- Original Message -----
From: "Jan Koehnlein" <koe...@tu...>
To: "NPSNET-V" <nps...@li...>
Sent: Tuesday, January 14, 2003 7:50 AM
Subject: [npsnetv-developers] Linux Test Results


> Hi,
>
> I did some further testing under Linux. This time I used the CVS
> snapshot. Here's what I found out
>
>     * There is a problem with the NPSNETV_HOME variable in the
>       bootstrap.xml file. The PATH has to start with a "/" character
>       which leads to a "file:////..." URL in the archive attribute of
>       the StandardResourceManager. As a result, the archive can't be
>       located. As a quick fix I removed one of the  slashes, but this
>       won't work under windows. Could not figure out where to fix this
>       in the Java sources.

     That's a problem.  I guess what I can do is change the "archive"
attribute to accept either a URL or a path name, then change bootstrap.xml
to read archive="${npsnetv.home}/archives/resource.jar".

>     * I wrote some shell-scripts to replace the bat-files (see
attachment).

     Thanks!  I'll put them in the CVS repository.

> The applications are hard to test as long as I don't know what they
> should do.

     They're basically all very simple tests.  If they don't generate error
messages and nothing too bizarre shows up in the window, then they're
probably working.  The "jspi" tests won't work at all in Linux, however;
they rely on the Elumens drivers, which are only available for Windows and
Irix.

> Most of them work now, but the scene stays quite gray.  The problem
> seems to be related to the sun (StandardHeavenlyBody) and the camera. If
> I transform the sun until I can see the flares, I can scale the camera
> to render the scene. Strange. Could also be a bug in the Linux
> implementation of Java3D (face culling, bounding spheres, influencing
> bounds or so).

     That is strange.  Hopefully in the future we'll be able to get a Linux
box up and running here to work on some of these issues.

     --Andrzej

[npsnetv-developers] Linux Test Results

[Jan K. <koe...@tu...>]

Hi,

I did some further testing under Linux. This time I used the CVS 
snapshot. Here's what I found out

    * There is a problem with the NPSNETV_HOME variable in the
      bootstrap.xml file. The PATH has to start with a "/" character
      which leads to a "file:////..." URL in the archive attribute of
      the StandardResourceManager. As a result, the archive can't be
      located. As a quick fix I removed one of the  slashes, but this
      won't work under windows. Could not figure out where to fix this
      in the Java sources.
    * I wrote some shell-scripts to replace the bat-files (see attachment).

The applications are hard to test as long as I don't know what they 
should do.

Most of them work now, but the scene stays quite gray.  The problem 
seems to be related to the sun (StandardHeavenlyBody) and the camera. If 
I transform the sun until I can see the flares, I can scale the camera 
to render the scene. Strange. Could also be a bug in the Linux 
implementation of Java3D (face culling, bounding spheres, influencing 
bounds or so).

Regards
Jan.

-- 
Jan Köhnlein                     Arbeitsbereich Technische Informatik VI
Wissenschaftlicher Mitarbeiter   TU Hamburg-Harburg  		
e-mail: koe...@tu...  Schwarzenbergstr. 95, Raum 2083
Tel.: (+49) 40 / 42878 - 3433    21071 Hamburg

Re: [npsnetv-developers] Working examples

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

----- Original Message -----
From: "Jan Koehnlein" <koe...@tu...>
To: <nps...@li...>
Sent: Monday, January 13, 2003 8:23 AM
Subject: [npsnetv-developers] Working examples


> -----------
> aden_view.xml:
> no errors but black window
> ------------

     I get the same result.  This was one of James Harney's test
applications, and I suspect the problem may be with the VRML file (or the
placement of it within the scene).

> dis_networking.xml:
> works fine, except the teapots explode before you can steer them.
> Setting armageddonMode to false solves the problem.
> ------------

     That's the expected behavior.  The teapots aren't really blowing up,
it's just that they're colocated with the test explosions being set off by
the explosion manager.  It's tricky to manipulate the teapots when that's
the case, because clicking on the window tends to select the explosions.

> xfsp_networking.xml:
> ...
> Error applying
> resource:/org/npsnet/v/applications/tests/xfsp_networking_a.xml:
> Couldn't find appropriate property/mapping for <ccei:Set value="1.0"
> name="nearClipDistance" />
> Error applying
> resource:/org/npsnet/v/applications/tests/xfsp_networking_a.xml:
> Couldn't find appropriate property/mapping for <ccei:Set value="1000.0"
> name="farClipDistance" />

     Whoops, that was due to an egregious error on my part.  I'm fixing it
in the CVS build now.

> Loading failed: resource:/org/npsnet/v/views/platforms/surface/FlagPic.gif

     This file was in the resources directory, but wasn't included in the
manifest.  Fixing that now.

> Initialized /client_a/j3dViewCore/landView
> Index does not match coordIndex

     This is some non-fatal error from the Xj3D loader.

> Loading failed: resource:/org/npsnet/v/views/terrain/water512.jpg

     I'm not getting this error, but it may have something to do with
something I had screwed up earlier (and have recently fixed in the CVS
build) in terms of MIME types.

> Set Protocol in StandardXFSPController with url
> org.dom4j.util.UserDataElement@c59ad5 [Element: <xfsp attributes: []/>]
> userData: null
> ...
> <same for client_b>

     I'm pretty sure this is normal, but you'd have to ask Ekrem (who wrote
the XFSP code).

> Windows appear but everything apart the sky vanishes within a second.

     That's not normal, on the other hand.  You should see two ships on a
static textured water surface.  As in the DIS test, if you move the left
ship in the left window, you should see it move in the right window as well,
and vice-versa.

> The other xfsp examples fail.

     When I run xfspYildiz.xml, it seems to work, although I only see the
XFSP sender; the DIS sender seems to be invisible.  xfspIITSEC.xml seems to
work fine for me.

> Generally, some of the resources are found and others are not,
> especially the textures. Maybe I have misconfigured the system?  I admit
> that I do not run Windows but Linux with JDK 1.4.1 and Java3D 1.3.

     Well, thanks for being the first to test it with Linux!  I don't think
you've misconfigured the system.  Since the textures are a particular
problem, I think the MIME type issue that I mentioned above may have
something to do with the errors that you're getting.

     --Andrzej

[npsnetv-developers] Working examples

[Jan K. <koe...@tu...>]

Hi all,

which of the examples in resource:///org/npsnet/v/applications/test 
should actually work?

Here are some results on my machine.

-----------
aden_view.xml:
	no errors but black window
------------
dis_networking.xml:
	works fine, except the teapots explode before you can steer them. 
Setting armageddonMode to false solves the problem.
------------
java3dFish_view.xml:
	works
------------
xfsp_networking.xml:
...
Error applying 
resource:/org/npsnet/v/applications/tests/xfsp_networking_a.xml: 
Couldn't find appropriate property/mapping for <ccei:Set value="1.0" 
name="nearClipDistance" />
Error applying 
resource:/org/npsnet/v/applications/tests/xfsp_networking_a.xml: 
Couldn't find appropriate property/mapping for <ccei:Set value="1000.0" 
name="farClipDistance" />
...
Loading failed: resource:/org/npsnet/v/views/platforms/surface/FlagPic.gif
...
Initialized /client_a/j3dViewCore/landView
Index does not match coordIndex
Loading failed: resource:/org/npsnet/v/views/terrain/water512.jpg
...
Set Protocol in StandardXFSPController with url
org.dom4j.util.UserDataElement@c59ad5 [Element: <xfsp attributes: []/>] 
userData: null
...
<same for client_b>

Windows appear but everything apart the sky vanishes within a second.
--------------

The other xfsp examples fail.

Generally, some of the resources are found and others are not, 
especially the textures. Maybe I have misconfigured the system?  I admit 
that I do not run Windows but Linux with JDK 1.4.1 and Java3D 1.3.

Regards
Jan.

-- 
Jan Köhnlein                     Arbeitsbereich Technische Informatik VI
Wissenschaftlicher Mitarbeiter   TU Hamburg-Harburg  		
e-mail: koe...@tu...  Schwarzenbergstr. 95, Raum 2083
Tel.: (+49) 40 / 42878 - 3433    21071 Hamburg

[npsnetv-developers] "2.0" release

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

All--

     I put a "2.0" release of NPSNET-V (binary and source zips) on the
SourceForge site on Christmas Eve, before I went on vacation.  I also
updated the web site (http://www.npsnet.org/~npsnet/v).  I didn't have time
to make an announcement then, so I'm doing it now.

     My main focus of development has been the browser application (on
Windows, you can launch it with binaries/browser.bat).  At the moment, you
can use the browser to view and configure the modules loaded in the
framework, and to browse and view available resources.  So far, I've written
content handlers for images, text (plain, rich, or HTML, using the Swing
components that Sun provides), and NPSNET-V configurations.  The next step
is adding support for entities and worlds, but there are a few things I need
to work on before I can do that.

     One change that will affect James H.'s work relates to the
configuration elements necessary to open viewports.  In
applications/tests/java3d_view.xml., for example, I replaced

            <fei:Module class="org.npsnet.v.views.j3d.J3DViewCore">

                <ccei:Target name="modelCore"/>

                <ccei:Viewport title="NPSNET-V: Java 3D View Test"
                               xPos="128"
                               yPos="16"
                               camera="modelCore/pilotableCamera"/>

            </fei:Module>

     with

            <fei:Module class="org.npsnet.v.views.j3d.J3DViewCore">

                <ccei:Target name="modelCore"/>

                <ccei:Viewports>

                    <ccei:Viewport title="NPSNET-V: Java 3D View Test"
                                   xPos="128"
                                   yPos="16"
                                   camera="modelCore/pilotableCamera"/>

                </ccei:Viewports>

            </fei:Module>

     The rationale behind doing so is basically to make sure that reapplying
the view core's configuration doesn't open a new window.

     --Andrzej

=-----
Andrzej Kapolka, ak...@np...
The MOVES Institute
Naval Postgraduate School
Spanagel 253-B, (831) 656-2253
------=

[npsnetv-developers] Re: What happened to NPSNET-V

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

----- Original Message -----
From: "Jan Koehnlein" <koe...@tu...>
To: <ak...@np...>
Sent: Wednesday, December 18, 2002 4:29 AM
Subject: Re: What happened to NPSNET-V


> sorry for bothering you with my previous email. I found the
> "-configuration" switch so it worked at last.

     Glad you got it working!

> Still I'd be interested in finding out, which way NPSNET-V is heading.
> I'd also welcome some documentation about the architecture, about the
> applications in the test-directory and how to the LDAP server correctly.

     Our strategy regarding LDAP has changed quite a bit.  Before, we were
using it as a database for serialized Java objects (entities and protocols).
Now, we're using it as a database for resource metadata: the locations and
attributes of resources such as images, VRML files, and XML application,
entity, and world configurations.

     So, when you browse the resources available to you, the
StandardResourceManager module combines the resources contained in the local
archives (the archives and archives/cache directories) with the resources
published on all known LDAP servers to provide you with a unified set of
resources to choose from.

     Anyway, the long and short of the matter is that you don't have to set
up your own LDAP server (although you can, if you want to publish resource
metadata yourself).  We're planning on setting up a public server soon, at
which point we can point configurations/bootstrap.xml to that and allow
people to obtain the newest versions of resources as they're released.

     --Andrzej

[npsnetv-developers] Re: What happened to NPSNET-V

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

----- Original Message -----
From: "Jan Koehnlein" <koe...@tu...>
To: <ak...@np...>
Sent: Wednesday, December 18, 2002 2:00 AM
Subject: What happened to NPSNET-V


> I remember having seen a bit more ;-) (BTW, the setup instructions seem
> to be a little bit out-of-date)

     Sorry about that!  I've been meaning to update them (and the web site)
for a while now.  I'm hoping to do that and put out a "2.0" release on
SourceForge before Christmas.

> I have tried to figure out which way the project is heading but I could
> not even understand what NPSNET-V actually *is* at the moment. It looks
> much more like an editor for 3D scenes than an architecture for DVEs. I
> noticed that you have stripped some --- at least for me --- interesting
> parts like Fishworld and AOIM.

     Yes.  I don't think *any* source code remains from when NPSNET-V
included FishWorld and the AOIM code.  After the students who worked on
those aspects (Dave Washington and Scott Wathen, respectively) graduated, I
decided that a massive rewrite was necessary to achieve the goals that we
had set for the NPSNET-V project.

     I've attached a paper that I wrote for the CVE 2002 conference that
documents the component framework, which is the foundation of the new
architecture.  In a nutshell, the idea is that applications should be
constructed as hierarchical federations of loosely coupled modules rooted at
an invariant microkernel.  All modules support XML
configuration/serialization, and all modules aside from the kernel can be
"hot-swapped"--that is, replaced with updated versions at run-time.

     I'm also attaching the presentation I gave at the CVE conference (and
at the MOVES Open House in August), which outlines some of our plans for the
project.  The "3D editor" aspect is a big part of those plans.  As a
principal driving application, I'm working on a generalized browser/builder
tool that will allow users to create and publish applications, entities, and
worlds by combining and configuring modules.

> Also, the overall structure seems to have changed significantly. Is
> there any general documentation about the new architecture? The javadocs
> do not tell to much about it. The vrtp mailing list hasn't had any input
> on NPSNET since March.

     We decided to switch to a SourceForge hosted list (npsnetv-developers,
see http://sourceforge.net/mail/?group_id=46176), in part because the vrtp
list was originally created for discussion of issues broader than NPSNET-V.
However, you won't see many messages on the archives of that list either.
At the moment, I'm pretty much developing NPSNET-V in isolation (although
working with a couple of students doing related projects who are graduating
next quarter), so it feels a little strange to make announcements when I
know no one's listening.  If you subscribe to that list, though, I'll have
an excuse to be more verbose.  :)

     I'll try to include more general documentation as time goes on.  The
javadocs could almost be considered dangerous, because only a subset of the
classes and interfaces included with NPSNET-V are intended to present an
API, so to speak: those are the ones in the kernel, properties, and services
sub-packages.  At the moment, the best way to figure things out is to look
at the examples (especially the applications under
resources/org/npsnet/v/applications/tests).

> If there is a working version, could you put an archive online? From the
> CVS snapshot it is hard to spot the active parts because there are lots
> of unused old directories and files. Maybe I have checked out the wrong
> module, is it still "npsnetv"?

     The module on SourceForge is indeed "npsnetv".  There shouldn't be any
unused directories or files in it, however (unless you browse it using the
web interface, in which case you'll see quite a few deleted directories).

     Thanks for your interest, and please contact me (or use the SourceForge
list) if you have any questions or comments in the future!

     --Andrzej

Re: [npsnetv-developers] Bootstrapping, paths

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

     It shouldn't affect your work much, since you can still load
applications from non-archived files (you just have to put a
"-configuration" in front of them on the command line).

     However, if you want a better way to invoke NPSNET-V than calling the
main method, I reorganized the kernel a little to let you do something like
this:

     Kernel kernel = Kernel.getKernel();  // Creates, initializes, and
starts the kernel if it doesn't exist

     kernel.applyConfiguration( (URL of your application file) );

     I went ahead and made the kernel load "configurations/bootstrap.xml" by
default (you can turn it off with the "-nobootstrap" option) just to make
things simpler.

     --Andrzej

----- Original Message -----
From: "Harney, James" <jwh...@np...>
To: "Kapolka, Andrzej" <ak...@np...>
Sent: Wednesday, December 11, 2002 10:45 AM
Subject: RE: [npsnetv-developers] Bootstrapping, paths


> [npsnetv-developers] Bootstrapping, pathsAfter I wrap up some things will
probably need to chat to see how best to transfer over the method I've been
using of using a stylesheet to generate npsnet v application files from my
UI native xml and then invoke.  Pretty cool work.  Talk to you later, James
>   -----Original Message-----
>   From: Kapolka, Andrzej
>   Sent: Wed 12/11/2002 9:40 AM
>   To: NPSNET-V
>   Cc:
>   Subject: [npsnetv-developers] Bootstrapping, paths
>
>
>   All--
>
>        I've been threatening to do this for a while, but I finally moved
the
>   application XML files into the resource system in order to allow a more
>   complete bootstrapping mechanism.  Now, the only XML configuration file
that
>   lives outside of a jar is configurations/bootstrap.xml, which simply
loads
>   the StandardResourceManager and points it at an LDAP server (the
>   StandardResourceManager still uses the archives and archives/cache
>   directories for locally stored resource archives).
>
>        Upon being loaded and configured, the first thing the
>   StandardResourceManager does is look for newer versions of itself,
upgrading
>   itself if possible.  The end result is that we can make a minimal
>   distribution of NPSNET-V with only four jars: kernel.jar,
properties.jar,
>   services.jar, and resource.jar (total size: about 150k).  Everything
else
>   can be downloaded from the web, assuming the user can connect to our
LDAP
>   and web servers.  And since the applications are part of the resource
>   hierarchy, we can change them after deployment; users with a clear line
to
>   the LDAP server will automatically download the latest versions.
>
>        I also changed the path configuration in order to eliminate the
need to
>   run NPSNET-V from its installation directory (c:\npsnetV, for instance).
>   The file "npsnetV.bat" now resides in a binaries directory, and uses the
>   environment variables JAVA_HOME and NPSNETV_HOME to locate java.exe,
>   kernel.jar, and bootstrap.xml.  If the NPSNET-V binaries directory were
in
>   your path and you wanted to run the DIS networking test, you'd type
>
>        npsnetV -configuration
>   resource:///org/npsnet/v/applications/tests/dis_networking.xml
>
>        from anywhere.  The batch files basically convert this into
>
>

      %JAVA_HOME%\jre\bin\java -Xmx256m -Dnpsnetv.home="%NPSNETV_HOME%" -jar
>   %NPSNETV_HOME%\archives\kernel.jar -configuration
>   %NPSNETV_HOME%\configurations\bootstrap.xml -configuration
>   resource:///org/npsnet/v/applications/tests/dis_networking.xml
>
>        The need for "-configuration" is new, too; its purpose is to better
>   allow modules other than the kernel to parse command line arguments.
>
>        Obviously, this is more awkward than the previous approach for
invoking
>   configurations on the command line, but the next item on my list is a
basic
>   browser application that we will be able to use to browse and open
>   resources, including configurations.
>
>        --Andrzej
>
>   =-----
>   Andrzej Kapolka, ak...@np...
>   The MOVES Institute
>   Naval Postgraduate School
>   Spanagel 253-B, (831) 656-2253
>   ------=
>
>
>
>
>   -------------------------------------------------------
>   This sf.net email is sponsored by:
>   With Great Power, Comes Great Responsibility
>   Learn to use your power at OSDN's High Performance Computing Channel
>   http://hpc.devchannel.org/
>
>
>

[npsnetv-developers] Bootstrapping, paths

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

All--

     I've been threatening to do this for a while, but I finally moved the
application XML files into the resource system in order to allow a more
complete bootstrapping mechanism.  Now, the only XML configuration file that
lives outside of a jar is configurations/bootstrap.xml, which simply loads
the StandardResourceManager and points it at an LDAP server (the
StandardResourceManager still uses the archives and archives/cache
directories for locally stored resource archives).

     Upon being loaded and configured, the first thing the
StandardResourceManager does is look for newer versions of itself, upgrading
itself if possible.  The end result is that we can make a minimal
distribution of NPSNET-V with only four jars: kernel.jar, properties.jar,
services.jar, and resource.jar (total size: about 150k).  Everything else
can be downloaded from the web, assuming the user can connect to our LDAP
and web servers.  And since the applications are part of the resource
hierarchy, we can change them after deployment; users with a clear line to
the LDAP server will automatically download the latest versions.

     I also changed the path configuration in order to eliminate the need to
run NPSNET-V from its installation directory (c:\npsnetV, for instance).
The file "npsnetV.bat" now resides in a binaries directory, and uses the
environment variables JAVA_HOME and NPSNETV_HOME to locate java.exe,
kernel.jar, and bootstrap.xml.  If the NPSNET-V binaries directory were in
your path and you wanted to run the DIS networking test, you'd type

     npsnetV -configuration
resource:///org/npsnet/v/applications/tests/dis_networking.xml

     from anywhere.  The batch files basically convert this into

     %JAVA_HOME%\jre\bin\java -Xmx256m -Dnpsnetv.home="%NPSNETV_HOME%" -jar
%NPSNETV_HOME%\archives\kernel.jar -configuration
%NPSNETV_HOME%\configurations\bootstrap.xml -configuration
resource:///org/npsnet/v/applications/tests/dis_networking.xml

     The need for "-configuration" is new, too; its purpose is to better
allow modules other than the kernel to parse command line arguments.

     Obviously, this is more awkward than the previous approach for invoking
configurations on the command line, but the next item on my list is a basic
browser application that we will be able to use to browse and open
resources, including configurations.

     --Andrzej

=-----
Andrzej Kapolka, ak...@np...
The MOVES Institute
Naval Postgraduate School
Spanagel 253-B, (831) 656-2253
------=

Re: [npsnetv-developers] Updates

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

James--

     I think it's best not to change all the entities to "file:..." URLs,
but rather to wait until loading from jars or resource URLs works in Xj3D.
Putting explicit file paths in there may work as a quick hack, but it will
break very easily in the mode of operation that NPSNET-V is actually
intended for (that is, installing only the kernel and downloading all other
resources on-the-fly as needed into a local cache).

     I'll take a quick look at Justin's URL-handling stuff and see if I can
find out what's breaking.

     --Andrzej

----- Original Message -----
From: "Harney, James" <jwh...@np...>
To: "NPSNET-V" <nps...@li...>
Sent: Wednesday, October 30, 2002 3:00 AM
Subject: [npsnetv-developers] Updates




Hi,
   Hadn't used the list in a while, so here you go...

--Currently til today we had no texture loading with the open source
vrml/x3d loader.  Now do but with a few catches currently:
   - Can not load any 3D from a jar.  This is temporarily worked around
by changing the scene reference in the entity xml file located in the
 npsnetv/resources/org/npsnet/v/entities... subtree by changing the
scene reference to something like:
<ccei:Scene
url="file:/resources/org/npsnet/v/views/platforms/surface/DDGArleighBurk
e.wrl"/>
where before the file would be reference like
<ccei:Scene
name="org/npsnet/v/views/platforms/surface/DDGArleighBurke.wrl"/>

Note you'll want to avoid a reference like file:/c:/npsnetv/resources...
Because it 1 assumes you're on a windows box, and 2 if one's playing in
Red Hat (Rick Goldbergs devl OS), then will die an ugly death.

For Andrezj, did not know if you wanted all the current entities changed
to this or to revert back to the previous xj3d build where we get no
textures but jar file access.  If you want to stay with the texture
loading capability for now (didn't know if you needed jar access in the
short term (next few weeks) for any planned work ), then just let me
know and I'll update teapot, AUV, spherical mine, and any fish Don M.
has in from the recent posts so they will work.  Have posted the new jar
temporarily so Ekrem and anyone else interested can get to if you don't
want it there til jars are working.

--Port Hueneme has a water texture now. I have a simple texture
animation in it that looks even nicer, but the texture transform scale
field is not yet exposed for runtime changing with behaviours on, so
you'll have to load in a different context to few it moving.  Once they
get it in, we can turn behaviours on in the loader code and have it
moving, etc.

--J3DAtmosphere if included in the xml decl as infinite atmosphere will
give you a decent Universal Media background from Web3D.org similar to
the newly proposed X3D Bacground2 node (not implemented by Xj3D yet).
Working on exposing the texture setting in the xml as well as the BG
color, etc.

--Looking to get Pearl Harbor incorporated once Claude finishes up some
scaling work with John Locke.

James



--


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

[npsnetv-developers] Updates

[Harney, J. <jwh...@np...>]

Hi,
   Hadn't used the list in a while, so here you go...

--Currently til today we had no texture loading with the open source
vrml/x3d loader.  Now do but with a few catches currently:
   - Can not load any 3D from a jar.  This is temporarily worked around
by changing the scene reference in the entity xml file located in the=20
 npsnetv/resources/org/npsnet/v/entities... subtree by changing the
scene reference to something like:
<ccei:Scene
url=3D"file:/resources/org/npsnet/v/views/platforms/surface/DDGArleighBur=
k
e.wrl"/>
where before the file would be reference like
<ccei:Scene
name=3D"org/npsnet/v/views/platforms/surface/DDGArleighBurke.wrl"/>

Note you'll want to avoid a reference like file:/c:/npsnetv/resources...
Because it 1 assumes you're on a windows box, and 2 if one's playing in
Red Hat (Rick Goldbergs devl OS), then will die an ugly death.

For Andrezj, did not know if you wanted all the current entities changed
to this or to revert back to the previous xj3d build where we get no
textures but jar file access.  If you want to stay with the texture
loading capability for now (didn't know if you needed jar access in the
short term (next few weeks) for any planned work ), then just let me
know and I'll update teapot, AUV, spherical mine, and any fish Don M.
has in from the recent posts so they will work.  Have posted the new jar
temporarily so Ekrem and anyone else interested can get to if you don't
want it there til jars are working.

--Port Hueneme has a water texture now. I have a simple texture
animation in it that looks even nicer, but the texture transform scale
field is not yet exposed for runtime changing with behaviours on, so
you'll have to load in a different context to few it moving.  Once they
get it in, we can turn behaviours on in the loader code and have it
moving, etc.

--J3DAtmosphere if included in the xml decl as infinite atmosphere will
give you a decent Universal Media background from Web3D.org similar to
the newly proposed X3D Bacground2 node (not implemented by Xj3D yet).
Working on exposing the texture setting in the xml as well as the BG
color, etc.

--Looking to get Pearl Harbor incorporated once Claude finishes up some
scaling work with John Locke.

James =20



--

[npsnetv-developers] CVS and MS XP

[Harney, J. <jwh...@np...>]

Hi,
  Ekrem and I have found in XP to get WinCVS 1.3 Beta 6 to work (where
beta 8 doesn't play nice with ssh), one must install WinCVS 1.2,
Then install WinCVS 1.3 Beta 6.
Then set up ssh.
Then set up cvs root, etc.
Then will work.  If you still have problems then it will be with the CVS
root setup, ssh setup, or inputting incorrect module syntax for checking
out modules.

Trying to install 1.3 Beta 6 w/o the existence of 1.2 in XP results in
space aliens attacking and no CVS on XP on Dell laptops.

Different note, was wondering when Don B. or Don M. were going to be
able to
Post DJV?

Beta Version of the X3D Installer made with the ZeroG sw is posted as
it's own module.  This is just the .exe, if you want the prettier
appletized version can be accessed from inside the firewall at:
http://intranet.nps.navy.mil/MV4250Students/Harney.html

Will do a Mac version of it tomorrow and post on the intranet site. =20

James

[npsnetv-developers] FW: [source] Xj3D Dev Snapshot Released

[Harney, J. <jwh...@np...>]

FYI,
   Xj3D info.  M-6 will be out soon.  Developer's build link here for
those interested. James

-----Original Message-----
From: Couch, Justin=20
Sent: Wednesday, September 04, 2002 5:39 PM
To: so...@we...
Cc: J3D Interest List
Subject: [source] Xj3D Dev Snapshot Released

It's up finally.

As usual, this is a development snapshot so use at your own risk. We've=20
given this one a little more testing than some of our others, but there=20
are still some untested bits.

The major change here is that we completely rewrote the event model.=20
It's now so fast that we're seeing some other weird bugs in Java3D's=20
rendering on mouse drag events (We also have a _far_ less complete=20
OpenGL renderer for the Mac users). Because these changes are so=20
fundamental, there are bound to be things that we've overlooked. We'd=20
appreciate any feedback people can give us on stuff that used to=20
previously work and now doesn't, and off course stuff that still doesn't

work.

You can get the latest snapshot from here:

http://www.xj3d.org/snapshots.html

--=20
Justin Couch                         http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler              http://www.yumetech.com/
Author, Java 3D FAQ Maintainer                  http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
                                               - Greg Bear, Slant
-------------------------------------------------------------------

[npsnetv-developers] Quad-Tree collision detection

[Harney, J. <jwh...@np...>]

Hi,

   Problem I am expecting to encounter while expanding the number of
entities in my thesis work is the waste of cycles when doing the
standard n^2 collision detection, even when simplifying to just checking
on radii intersection. =20

=20

Reading through one of the Xtreme Games programming books edited by
Andre Lamothe, the author presents the concept + exemplar of using Quad
trees for this similar to the AOI research from a few quarters back in
the previous version of NPSNET V.

=20

Looks like the same manner of good enough testing with the radii can be
used within the Quadtree example they demo, but still take advantage of
not checking collisions w/all entities and all entities with land when
operating on the sea w/no terrain following requirement.

Checks still done on client side if networking.

Wondering if anyone had thoughts on using this?  IE, don't mess with
unless expansion impacts performance enough needs to be utilized, tried
it and x is painful, etc.

=20

James=20

[npsnetv-developers] Loading NPSNET Java3D view in one's application

[Harney, J. <jwh...@np...>]

Hi,

   Below is the current syntax that I'm using for loading auto generated
npsnetv scenes into the content frame of my thesis application for
reference by anyone interested.

Many thanks to Andrezj again for assistance with the below.

=20

            Example input string would be something like:=20

            String [] inputString =3D
{"applications/atfp/myNPSNETView.xml"};

Then,=20

=20

            //Invoke the kernel        =20

            Kernel.main(inputString);

=20

//Get a handle to the Kernel

            myKernel =3D Kernel.getKernel();

=20

          //Get a handle to the J3DViewCore in the npsnet file...Node
naming convention here must match your app or write code to discover it

            J3DViewCore avc =3D
(J3DViewCore)myKernel.getModuleNamed("Simulation/j3dViewCore/");

       =20

           =20

            //Now get a handle to the J3DViewport

            J3DViewport av =3D (J3DViewport)avc.newComponentViewport();

 =20

            //We don't have a camera, and the code will crap itself if
we don't give it one, so we select one we put in

            //to the NPSNET V application file...

         //*********Note the syntax for this camera must match ones
application or add code to see what cameras are available.  Since I'm
only

            //worried about loading scenes I create, this switching
camera is in each and every one with the same syntax. Also the Container
name

            //remains the same, and would need to be switched to match
one's syntax

            //Also, if you define a viewport to have a JFrame, that will
still load...short answer to this for my stuff is to remove the
declarative portion of the J3DViewport that

            //creates the JFrame. =20

           //If you do not set a camera to the component then you will
run into many exceptions being thrown since it's expected to have a
camera. =20

=20

            Camera myCamera =3D
(Camera)myKernel.getModuleNamed("/Simulation/modelCore/SwitchingCameraSi
mulationBlue");

           =20

            //Now set the camera

            av.setCamera(myCamera);

       =20

=20

            //Get a handle to the Canvas3D Andrezj's created for us


            c =3D (Canvas3D) av.getCanvasComponent();

           =20

            //Now add it to our JFrames content pane...note that this is
a very painful area. See http://www.j3d.org/faq for=20

            //the faq details on Java 3D in Swing...short answer is to
not assume a given capability til doing heavy weight +

            //lightweight Swing component calculus.

=20

            //my3DContainer.add( c, BorderLayout.CENTER);

           =20

           =20

            parent.getContentPane().add(c, BorderLayout.CENTER);

=20

=20

=20

=20

=20

Notes:  This code works no problem if loading into a standard JFrame
w/no other components beneath the Canvas3D.  When loading ontop of
existing components you will

Experience a delay of a few seconds.  Currently working on work arounds
for this.

=20

If you have any questions, or have better ways to do stuff just holler.
Thanks again to Andrezj for the assistance with figuring out the above.

=20

Different note, Xj3D M-6 due out this weekend.  Besides the graphics
portion, Rick Goldberg of Anazilla.com has done up a VecMath library
that can be used w/o Java3D (he worked on Sun's implementation of same
before) that might be usable in this codebase to allow the OpenGl, text,
and 2D views to be run w/o java3d deployment. =20

=20

=20

James

RE: [npsnetv-developers] CVS and Xj3D

[Harney, J. <jwh...@np...>]

SGksDQogICBUcmllZCB1c2luZyBodHRwLCBmaWxlLCBhbmQgdGhlIGJlbG93IHdpdGggdGhlIHNh
bWUgZmFpbHVyZSBvbiB0aGUgamFyIGFjY2Vzc2luZyBvZiB0aGUgdGV4dHVyZSBmaWxlLiAgU2Ft
ZSB0cmFjZSBhcyBiZWZvcmUuIENhbiByZXNlbmQgYXQgYW5vdGhlciB0aW1lLiAgSmFtZXMNCg0K
CS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEthcG9sa2EsIEFuZHJ6ZWogDQoJ
U2VudDogVGh1IDgvMTUvMjAwMiAxMDozOSBBTSANCglUbzogSGFybmV5LCBKYW1lczsgTlBTTkVU
LVYgDQoJQ2M6IA0KCVN1YmplY3Q6IFJFOiBbbnBzbmV0di1kZXZlbG9wZXJzXSBDVlMgYW5kIFhq
M0QNCgkNCgkNCgkgDQoJICAgICBNYWtpbmcgYSB3ZWVrbHkgemlwIG1ha2VzIHNlbnNlLCBhbHRo
b3VnaCBpdCB3b3VsZCBwcm9iYWJseSBiZSBiZXR0ZXIganVzdCB0byB1c2UgU291cmNlRm9yZ2Un
cyBwYWNrYWdlIHB1Ymxpc2hpbmcgZnVuY3Rpb25hbGl0eSAoYXMgb3Bwb3NlZCB0byBwdXR0aW5n
IHRoZSB6aXAgaW4gdGhlIENWUyByZXBvc2l0b3J5KS4gIEkgaW5zdGFsbGVkIEluc3RhbGxBbnl3
aGVyZSB1bmRlciBEb24ncyBsaWNlbnNlLCBidXQgSSBoYXZlbid0IHJlYWxseSBjaGVja2VkIGl0
IG91dCB5ZXQuDQoJIA0KCSAgICAgU2VlbXMgbGlrZSBmb3IgeW91ciByZWxhdGl2ZSBVUkxzLCB5
b3Ugb3VnaHQgbm90IHRvIHVzZSBhIHByb3RvY29sIChiZWNhdXNlIHRoZSBwcm90b2NvbCB1c2Vk
IGZvciB0aGUgcmVzb3VyY2VzIGlzICJqYXI6IikuICBJbnN0ZWFkLCBqdXN0IHB1dCB0aGUgcmVs
YXRpdmUgcGF0aDogIm15dGV4dHVyZXMvdGV4dHVyZS5qcGciDQoJIA0KCSAgICAgLS1BbmRyemVq
DQoNCgkJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJCUZyb206IEhhcm5leSwgSmFtZXMg
DQoJCVNlbnQ6IFdlZCA4LzE0LzIwMDIgMTA6NDggUE0gDQoJCVRvOiBLYXBvbGthLCBBbmRyemVq
OyBOUFNORVQtViANCgkJQ2M6IA0KCQlTdWJqZWN0OiBbbnBzbmV0di1kZXZlbG9wZXJzXSBDVlMg
YW5kIFhqM0QNCgkJDQoJCQ0KDQoJCUFueSB0aG91Z2h0cyBvbiB0aGUgZm9sbG93aW5nOg0KCQkx
KSBNYWtpbmcgYSB3ZWVrbHkgemlwIG9mIGEpIHNvdXJjZSwgYikgc291cmNlICsgYmluYXJpZXMg
dG8gcG9zdCBpbiB0aGUgY3ZzIGZvciBmb2xrcyB0byBiZSBhYmxlIHRvIGRvd25sb2FkIGRpcmVj
dGx5IHcvbyBoYXZpbmcgdG8gZ28gdGhyb3VnaCB0aGUgc2V0dXAgcHJvY2VzcyB3L0FudCwgT3Bl
bi1HbCA0IEphdmEsIGFuZCBDVlMuIEZpZ3VyZSBpbiB0aGlzIG1hbm5lciBtaWdodCBtYWtlIHRo
ZSByZWNydWl0bWVudCBvZiBuZXcgc3R1ZGVudHMgLyBvdGhlciBkZXZlbG9wZXJzIGEgYml0IGVh
c2llcg0KCQkyKSBXaGVuIHRvIHJlbGVhc2UgYSBmbGF2b3Igd2l0aCB0aGUgbmV3IGhpZ2ggc3Bl
ZWQgaW5zdGFsbGVyIERvbiBCLiBhY3F1aXJlZCBlYXJsaWVyIHRoaXMgd2Vlaz8gIEkga25vdyBB
bmRyZXpqIGhhZCBtZW50aW9uZWQgZG9jdW1lbnRhdGlvbiB3b3JrIG5lZWRpbmcgdG8gYmUgZG9u
ZS4gIENvdWxkIGl0ZW1pemUgdGhlIHRvIGRvIGxpc3Qgb24gdGhpcyBhbW9uZ3N0IG91cnNlbHZl
cywgc2V0IGEgZGF0ZSBmb3IgY29tcGxldGlvbiBhbmQgQW5kcmV6aiBhbmQgRG9uIE0uIHJldmll
dywgdGhlbiBnbyB0byBwcmVzcyBtYXliZT8gDQoJCQ0KCQlYajNEIC0tIFRleHR1cmUgbG9hZGlu
ZyBkb3duIHRvIHByb2JsZW1zIHdpdGggYWNjZXNzaW5nIHRoZW0gaW4gdGhlIGphcnJlZCByZXNv
dXJjZS4gIFdpbGwgYXR0ZW1wdCBhIGZldyBpdGVyYXRpb25zIG9uIGhvdyBJIHJlZmVyZW5jZSB0
aGVtIGluIHRoZSBYM0QvVnJtbCBmaWxlcyAoaWUgaHR0cDovLyJteVRleHR1cmUucG5nIiwgImZp
bGU6Ly9vcmcvbnBzbmV0L3YvcGxhdGZvcm1zL3N1cmZhY2Uvdmlld3MvbXlUZXh0dXJlLnBuZywN
CgkJImh0dHA6Ly8uLi4NCgkJZXRjDQoJCWFuZCByZXBvcnQgb24gYW55IHN1Y2Nlc3MuDQoJCQ0K
CQlBbGFuIGhhcyBnb3R0ZW4gdGhlbSB0byBsb2FkIG5vdyBpbiB0aGUgWGozRCBqYXZhM2QgbG9h
ZGVyIGV4ZW1wbGFyIHdpdGggdGhlIE01KyBzdHVmZiBoZSBzZW50IHRoZSBvdGhlciBkYXkuDQoJ
CQ0KCQlKYW1lcw0KCQkNCgkJDQoJCQ0KCQkNCgkJDQoJCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQoJCUZyb206IEthcG9sa2EsIEFuZHJ6ZWoNCgkJU2VudDogV2VkIDgvMTQvMjAwMiA5OjQ5
IEFNDQoJCVRvOiBOUFNORVQtVg0KCQlDYzoNCgkJU3ViamVjdDogW25wc25ldHYtZGV2ZWxvcGVy
c10gUmU6IE5QU05FVCBzdHVmZg0KCQkNCgkJDQoJCQ0KCQkgICAgICAgIEphbWVzLS0NCgkJICAg
ICAgIA0KCQkgICAgICAgICAgICAgVGhpcyBoYXMgY29tZSB1cCBtYW55IHRpbWVzIGJlZm9yZS4g
IFRoZSByZWFzb24gd2UgaGF2ZW4ndCBkZWZpbmVkIGENCgkJICAgICAgICBEVEQgb3Igc2NoZW1h
IGZvciB0aGUgTlBTTkVULVYgY29uZmlndXJhdGlvbiBmb3JtYXQgaXMgdGhlIHNhbWUgcmVhc29u
IEFudA0KCQkgICAgICAgIGJ1aWxkIGZpbGVzIGRvbid0IGhhdmUgc2NoZW1hcy0tYmVjYXVzZSB5
b3UgY2FuIGFkZCBuZXcgdHlwZXMgb2YgZWxlbWVudHMgb24NCgkJICAgICAgICB0aGUgZmx5LCBl
dmVuIGluIHRoZSBtaWRkbGUgb2YgcGFyc2luZyBhIHNpbmdsZSBjb25maWd1cmF0aW9uIGZpbGUu
ICBBbGwgb2YNCgkJICAgICAgICB0aGUgY29uZmlndXJhdGlvbiB0YWdzIGFyZSB2YWxpZGF0ZWQg
bWFudWFsbHktLWZvciBleGFtcGxlLCBpZiB5b3UgZG9uJ3QNCgkJICAgICAgICBpbmNsdWRlIGEg
cmVxdWlyZWQgYXR0cmlidXRlLCBpdCdzIHRoZSBhcHBsaWNhdGlvbiByYXRoZXIgdGhhbiB0aGUg
cGFyc2VyDQoJCSAgICAgICAgdGhhdCBpc3N1ZXMgYW4gZXJyb3IgbWVzc2FnZS4NCgkJICAgICAg
IA0KCQkgICAgICAgICAgICAgVGhhdCBzYWlkLCBJIGhhdmVuJ3QgbG9va2VkIHRvbyBkZWVwbHkg
aW50byB1c2luZyBzY2hlbWFzIHJhdGhlciB0aGFuDQoJCSAgICAgICAgRFREcy4gIENvbmZpZ3Vy
YXRpb24gZG9jdW1lbnRhdGlvbiB3aWxsIGhlbHAsIGJ1dCBpdCB3b3VsZCBiZSBuaWNlIHRvDQoJ
CSAgICAgICAgdmFsaWRhdGUgdGhlIHRhZ3MgYXV0b21hdGljYWxseS4NCgkJICAgICAgIA0KCQkg
ICAgICAgICAgICAgLS1BbmRyemVqDQoJCSAgICAgICANCgkJICAgICAgICAtLS0tLSBPcmlnaW5h
bCBNZXNzYWdlIC0tLS0tDQoJCSAgICAgICAgRnJvbTogIkhhcm5leSwgSmFtZXMiIDxqd2hhcm5l
eUBucHMubmF2eS5taWw+DQoJCSAgICAgICAgVG86ICJLYXBvbGthLCBBbmRyemVqIiA8YWthcG9s
a0BucHMubmF2eS5taWw+DQoJCSAgICAgICAgU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTQsIDIw
MDIgODo1NSBBTQ0KCQkgICAgICAgIFN1YmplY3Q6IE5QU05FVCBzdHVmZg0KCQkgICAgICAgDQoJ
CSAgICAgICANCgkJICAgICAgICBOUFNORVQgc3R1ZmZIZXksDQoJCSAgICAgICAgICAgICBXYXMg
d29uZGVyaW5nIGlmIHlvdSB0aG91Z2h0IGl0IG5lY2Vzc2FyeSB0byBkZWZpbmUgYSBTY2hlbWEg
b3IgRFRELCBvcg0KCQkgICAgICAgIGJvdGggZm9yIHRoZSBYTUwgYXBwIGZpbGVzIGZvciBOUFNO
RVQ/ICBTdW4gZG9lcyBhIHNpbWlsYXIgdGhpbmcgd2l0aCBKTkxQDQoJCSAgICAgICAgYnV0IHJl
cXVpcmVzIG5vIGRlY2xhcmF0aW9uIG9mIGl0IGluIGluc3RhbmNlIGRvY3VtZW50cywgY2hlY2tz
IHdpdGhpbiB0aGUNCgkJICAgICAgICBXZWJzdGFydCBBUEkuICBJZiBzbywgSSBjb3VsZCBnaXZl
IHRoZSBmaXJzdCB2ZXJzaW9uIGEgc2hvdCBpZiB5b3Ugd2FudC4NCgkJICAgICAgICBMb29raW5n
IGJhY2sgb3ZlciB0aGUgM21pbGxpb24gZW1haWxzIG9yIHNvIEkndmUgYnVnZ2VkIHlvdSB3aXRo
LCBhIGxvdCBkZWFsDQoJCSAgICAgICAgd2l0aCB0aGUgYXJlYSBvZiBhbGxvd2FibGUgb3IgY29y
cmVjdCBzeW50YXggaW4gdGhlIGFwcCBmaWxlIGFuZCB0aGlzIG1pZ2h0DQoJCSAgICAgICAgYWlk
IG90aGVycy4gIERpZG4ndCBrbm93IGlmIHlvdSB3ZXJlIGFscmVhZHkgZG9pbmcgYXMgcGFydCBv
ZiB0aGUgY29uZmlnDQoJCSAgICAgICAgZG9jcyBvciBub3QuICBUYWxrIHRvIHlvdSBsYXRlciwg
SmFtZXMNCgkJICAgICAgIA0KCQkgICAgICAgDQoJCSAgICAgICANCgkJICAgICAgIA0KCQkgICAg
ICAgDQoJCSAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KCQkgICAgICAgIFRoaXMgc2YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBi
eTogRGljZSAtIFRoZSBsZWFkaW5nIG9ubGluZSBqb2IgYm9hcmQNCgkJICAgICAgICBmb3IgaGln
aC10ZWNoIHByb2Zlc3Npb25hbHMuIFNlYXJjaCBhbmQgYXBwbHkgZm9yIHRlY2ggam9icyB0b2Rh
eSENCgkJICAgICAgICBodHRwOi8vc2Vla2VyLmRpY2UuY29tL3NlZWtlci5lcGw/cmVsX2NvZGU9
MzENCgkJICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KCQkgICAgICAgIG5wc25ldHYtZGV2ZWxvcGVycyBtYWlsaW5nIGxpc3QNCgkJICAgICAg
ICBucHNuZXR2LWRldmVsb3BlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQoJCSAgICAgICAgaHR0
cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vbnBzbmV0di1kZXZlbG9w
ZXJzDQoJCSAgICAgICANCgkJDQoJCU4YAemailgndeKYvEgzU2Fq7K6IGiV1cmjhnrUeF3krFREE
4bKGaQjhqacaJyjhr5sCcQfhrK3HoQID3abJtgfqmah4y6bJtgcr57myyq3Hosu226J5Acm325Yr
d3rgsZ1165aKIA0KDQo=

RE: [npsnetv-developers] CVS and Xj3D

[Kapolka, A. <ak...@np...>]

IA0KICAgICBNYWtpbmcgYSB3ZWVrbHkgemlwIG1ha2VzIHNlbnNlLCBhbHRob3VnaCBpdCB3b3Vs
ZCBwcm9iYWJseSBiZSBiZXR0ZXIganVzdCB0byB1c2UgU291cmNlRm9yZ2UncyBwYWNrYWdlIHB1
Ymxpc2hpbmcgZnVuY3Rpb25hbGl0eSAoYXMgb3Bwb3NlZCB0byBwdXR0aW5nIHRoZSB6aXAgaW4g
dGhlIENWUyByZXBvc2l0b3J5KS4gIEkgaW5zdGFsbGVkIEluc3RhbGxBbnl3aGVyZSB1bmRlciBE
b24ncyBsaWNlbnNlLCBidXQgSSBoYXZlbid0IHJlYWxseSBjaGVja2VkIGl0IG91dCB5ZXQuDQog
DQogICAgIFNlZW1zIGxpa2UgZm9yIHlvdXIgcmVsYXRpdmUgVVJMcywgeW91IG91Z2h0IG5vdCB0
byB1c2UgYSBwcm90b2NvbCAoYmVjYXVzZSB0aGUgcHJvdG9jb2wgdXNlZCBmb3IgdGhlIHJlc291
cmNlcyBpcyAiamFyOiIpLiAgSW5zdGVhZCwganVzdCBwdXQgdGhlIHJlbGF0aXZlIHBhdGg6ICJt
eXRleHR1cmVzL3RleHR1cmUuanBnIg0KIA0KICAgICAtLUFuZHJ6ZWoNCg0KCS0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEhhcm5leSwgSmFtZXMgDQoJU2VudDogV2VkIDgvMTQv
MjAwMiAxMDo0OCBQTSANCglUbzogS2Fwb2xrYSwgQW5kcnplajsgTlBTTkVULVYgDQoJQ2M6IA0K
CVN1YmplY3Q6IFtucHNuZXR2LWRldmVsb3BlcnNdIENWUyBhbmQgWGozRA0KCQ0KCQ0KDQoJQW55
IHRob3VnaHRzIG9uIHRoZSBmb2xsb3dpbmc6DQoJMSkgTWFraW5nIGEgd2Vla2x5IHppcCBvZiBh
KSBzb3VyY2UsIGIpIHNvdXJjZSArIGJpbmFyaWVzIHRvIHBvc3QgaW4gdGhlIGN2cyBmb3IgZm9s
a3MgdG8gYmUgYWJsZSB0byBkb3dubG9hZCBkaXJlY3RseSB3L28gaGF2aW5nIHRvIGdvIHRocm91
Z2ggdGhlIHNldHVwIHByb2Nlc3Mgdy9BbnQsIE9wZW4tR2wgNCBKYXZhLCBhbmQgQ1ZTLiBGaWd1
cmUgaW4gdGhpcyBtYW5uZXIgbWlnaHQgbWFrZSB0aGUgcmVjcnVpdG1lbnQgb2YgbmV3IHN0dWRl
bnRzIC8gb3RoZXIgZGV2ZWxvcGVycyBhIGJpdCBlYXNpZXINCgkyKSBXaGVuIHRvIHJlbGVhc2Ug
YSBmbGF2b3Igd2l0aCB0aGUgbmV3IGhpZ2ggc3BlZWQgaW5zdGFsbGVyIERvbiBCLiBhY3F1aXJl
ZCBlYXJsaWVyIHRoaXMgd2Vlaz8gIEkga25vdyBBbmRyZXpqIGhhZCBtZW50aW9uZWQgZG9jdW1l
bnRhdGlvbiB3b3JrIG5lZWRpbmcgdG8gYmUgZG9uZS4gIENvdWxkIGl0ZW1pemUgdGhlIHRvIGRv
IGxpc3Qgb24gdGhpcyBhbW9uZ3N0IG91cnNlbHZlcywgc2V0IGEgZGF0ZSBmb3IgY29tcGxldGlv
biBhbmQgQW5kcmV6aiBhbmQgRG9uIE0uIHJldmlldywgdGhlbiBnbyB0byBwcmVzcyBtYXliZT8g
DQoJDQoJWGozRCAtLSBUZXh0dXJlIGxvYWRpbmcgZG93biB0byBwcm9ibGVtcyB3aXRoIGFjY2Vz
c2luZyB0aGVtIGluIHRoZSBqYXJyZWQgcmVzb3VyY2UuICBXaWxsIGF0dGVtcHQgYSBmZXcgaXRl
cmF0aW9ucyBvbiBob3cgSSByZWZlcmVuY2UgdGhlbSBpbiB0aGUgWDNEL1ZybWwgZmlsZXMgKGll
IGh0dHA6Ly8ibXlUZXh0dXJlLnBuZyIsICJmaWxlOi8vb3JnL25wc25ldC92L3BsYXRmb3Jtcy9z
dXJmYWNlL3ZpZXdzL215VGV4dHVyZS5wbmcsDQoJImh0dHA6Ly8uLi4NCglldGMNCglhbmQgcmVw
b3J0IG9uIGFueSBzdWNjZXNzLg0KCQ0KCUFsYW4gaGFzIGdvdHRlbiB0aGVtIHRvIGxvYWQgbm93
IGluIHRoZSBYajNEIGphdmEzZCBsb2FkZXIgZXhlbXBsYXIgd2l0aCB0aGUgTTUrIHN0dWZmIGhl
IHNlbnQgdGhlIG90aGVyIGRheS4NCgkNCglKYW1lcw0KCQ0KCQ0KCQ0KCQ0KCQ0KCS0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQoJRnJvbTogS2Fwb2xrYSwgQW5kcnplag0KCVNlbnQ6IFdlZCA4
LzE0LzIwMDIgOTo0OSBBTQ0KCVRvOiBOUFNORVQtVg0KCUNjOg0KCVN1YmplY3Q6IFtucHNuZXR2
LWRldmVsb3BlcnNdIFJlOiBOUFNORVQgc3R1ZmYNCgkNCgkNCgkNCgkgICAgICAgIEphbWVzLS0N
CgkgICAgICAgDQoJICAgICAgICAgICAgIFRoaXMgaGFzIGNvbWUgdXAgbWFueSB0aW1lcyBiZWZv
cmUuICBUaGUgcmVhc29uIHdlIGhhdmVuJ3QgZGVmaW5lZCBhDQoJICAgICAgICBEVEQgb3Igc2No
ZW1hIGZvciB0aGUgTlBTTkVULVYgY29uZmlndXJhdGlvbiBmb3JtYXQgaXMgdGhlIHNhbWUgcmVh
c29uIEFudA0KCSAgICAgICAgYnVpbGQgZmlsZXMgZG9uJ3QgaGF2ZSBzY2hlbWFzLS1iZWNhdXNl
IHlvdSBjYW4gYWRkIG5ldyB0eXBlcyBvZiBlbGVtZW50cyBvbg0KCSAgICAgICAgdGhlIGZseSwg
ZXZlbiBpbiB0aGUgbWlkZGxlIG9mIHBhcnNpbmcgYSBzaW5nbGUgY29uZmlndXJhdGlvbiBmaWxl
LiAgQWxsIG9mDQoJICAgICAgICB0aGUgY29uZmlndXJhdGlvbiB0YWdzIGFyZSB2YWxpZGF0ZWQg
bWFudWFsbHktLWZvciBleGFtcGxlLCBpZiB5b3UgZG9uJ3QNCgkgICAgICAgIGluY2x1ZGUgYSBy
ZXF1aXJlZCBhdHRyaWJ1dGUsIGl0J3MgdGhlIGFwcGxpY2F0aW9uIHJhdGhlciB0aGFuIHRoZSBw
YXJzZXINCgkgICAgICAgIHRoYXQgaXNzdWVzIGFuIGVycm9yIG1lc3NhZ2UuDQoJICAgICAgIA0K
CSAgICAgICAgICAgICBUaGF0IHNhaWQsIEkgaGF2ZW4ndCBsb29rZWQgdG9vIGRlZXBseSBpbnRv
IHVzaW5nIHNjaGVtYXMgcmF0aGVyIHRoYW4NCgkgICAgICAgIERURHMuICBDb25maWd1cmF0aW9u
IGRvY3VtZW50YXRpb24gd2lsbCBoZWxwLCBidXQgaXQgd291bGQgYmUgbmljZSB0bw0KCSAgICAg
ICAgdmFsaWRhdGUgdGhlIHRhZ3MgYXV0b21hdGljYWxseS4NCgkgICAgICAgDQoJICAgICAgICAg
ICAgIC0tQW5kcnplag0KCSAgICAgICANCgkgICAgICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug
LS0tLS0NCgkgICAgICAgIEZyb206ICJIYXJuZXksIEphbWVzIiA8andoYXJuZXlAbnBzLm5hdnku
bWlsPg0KCSAgICAgICAgVG86ICJLYXBvbGthLCBBbmRyemVqIiA8YWthcG9sa0BucHMubmF2eS5t
aWw+DQoJICAgICAgICBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNCwgMjAwMiA4OjU1IEFNDQoJ
ICAgICAgICBTdWJqZWN0OiBOUFNORVQgc3R1ZmYNCgkgICAgICAgDQoJICAgICAgIA0KCSAgICAg
ICAgTlBTTkVUIHN0dWZmSGV5LA0KCSAgICAgICAgICAgICBXYXMgd29uZGVyaW5nIGlmIHlvdSB0
aG91Z2h0IGl0IG5lY2Vzc2FyeSB0byBkZWZpbmUgYSBTY2hlbWEgb3IgRFRELCBvcg0KCSAgICAg
ICAgYm90aCBmb3IgdGhlIFhNTCBhcHAgZmlsZXMgZm9yIE5QU05FVD8gIFN1biBkb2VzIGEgc2lt
aWxhciB0aGluZyB3aXRoIEpOTFANCgkgICAgICAgIGJ1dCByZXF1aXJlcyBubyBkZWNsYXJhdGlv
biBvZiBpdCBpbiBpbnN0YW5jZSBkb2N1bWVudHMsIGNoZWNrcyB3aXRoaW4gdGhlDQoJICAgICAg
ICBXZWJzdGFydCBBUEkuICBJZiBzbywgSSBjb3VsZCBnaXZlIHRoZSBmaXJzdCB2ZXJzaW9uIGEg
c2hvdCBpZiB5b3Ugd2FudC4NCgkgICAgICAgIExvb2tpbmcgYmFjayBvdmVyIHRoZSAzbWlsbGlv
biBlbWFpbHMgb3Igc28gSSd2ZSBidWdnZWQgeW91IHdpdGgsIGEgbG90IGRlYWwNCgkgICAgICAg
IHdpdGggdGhlIGFyZWEgb2YgYWxsb3dhYmxlIG9yIGNvcnJlY3Qgc3ludGF4IGluIHRoZSBhcHAg
ZmlsZSBhbmQgdGhpcyBtaWdodA0KCSAgICAgICAgYWlkIG90aGVycy4gIERpZG4ndCBrbm93IGlm
IHlvdSB3ZXJlIGFscmVhZHkgZG9pbmcgYXMgcGFydCBvZiB0aGUgY29uZmlnDQoJICAgICAgICBk
b2NzIG9yIG5vdC4gIFRhbGsgdG8geW91IGxhdGVyLCBKYW1lcw0KCSAgICAgICANCgkgICAgICAg
DQoJICAgICAgIA0KCSAgICAgICANCgkgICAgICAgDQoJICAgICAgICAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJICAgICAgICBUaGlzIHNm
Lm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IERpY2UgLSBUaGUgbGVhZGluZyBvbmxpbmUgam9i
IGJvYXJkDQoJICAgICAgICBmb3IgaGlnaC10ZWNoIHByb2Zlc3Npb25hbHMuIFNlYXJjaCBhbmQg
YXBwbHkgZm9yIHRlY2ggam9icyB0b2RheSENCgkgICAgICAgIGh0dHA6Ly9zZWVrZXIuZGljZS5j
b20vc2Vla2VyLmVwbD9yZWxfY29kZT0zMQ0KCSAgICAgICAgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCgkgICAgICAgIG5wc25ldHYtZGV2ZWxvcGVycyBt
YWlsaW5nIGxpc3QNCgkgICAgICAgIG5wc25ldHYtZGV2ZWxvcGVyc0BsaXN0cy5zb3VyY2Vmb3Jn
ZS5uZXQNCgkgICAgICAgIGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3Rp
bmZvL25wc25ldHYtZGV2ZWxvcGVycw0KCSAgICAgICANCgkNCglOGAHpmopYJ3XimLxIM1Nhauyu
iBoldXJo4Z61Hhd5KxURBOGyhmkI4amnGico4a+bAnEH4aytx6ECA92mybYH6pmoeMumybYHK+e5
ssqtx6LLttuieQHJt9uWK3d64LGddeuWiiANCg0K

[npsnetv-developers] CVS and Xj3D

[Harney, J. <jwh...@np...>]

QW55IHRob3VnaHRzIG9uIHRoZSBmb2xsb3dpbmc6DQoxKSBNYWtpbmcgYSB3ZWVrbHkgemlwIG9m
IGEpIHNvdXJjZSwgYikgc291cmNlICsgYmluYXJpZXMgdG8gcG9zdCBpbiB0aGUgY3ZzIGZvciBm
b2xrcyB0byBiZSBhYmxlIHRvIGRvd25sb2FkIGRpcmVjdGx5IHcvbyBoYXZpbmcgdG8gZ28gdGhy
b3VnaCB0aGUgc2V0dXAgcHJvY2VzcyB3L0FudCwgT3Blbi1HbCA0IEphdmEsIGFuZCBDVlMuIEZp
Z3VyZSBpbiB0aGlzIG1hbm5lciBtaWdodCBtYWtlIHRoZSByZWNydWl0bWVudCBvZiBuZXcgc3R1
ZGVudHMgLyBvdGhlciBkZXZlbG9wZXJzIGEgYml0IGVhc2llcg0KMikgV2hlbiB0byByZWxlYXNl
IGEgZmxhdm9yIHdpdGggdGhlIG5ldyBoaWdoIHNwZWVkIGluc3RhbGxlciBEb24gQi4gYWNxdWly
ZWQgZWFybGllciB0aGlzIHdlZWs/ICBJIGtub3cgQW5kcmV6aiBoYWQgbWVudGlvbmVkIGRvY3Vt
ZW50YXRpb24gd29yayBuZWVkaW5nIHRvIGJlIGRvbmUuICBDb3VsZCBpdGVtaXplIHRoZSB0byBk
byBsaXN0IG9uIHRoaXMgYW1vbmdzdCBvdXJzZWx2ZXMsIHNldCBhIGRhdGUgZm9yIGNvbXBsZXRp
b24gYW5kIEFuZHJlemogYW5kIERvbiBNLiByZXZpZXcsIHRoZW4gZ28gdG8gcHJlc3MgbWF5YmU/
ICANCiANClhqM0QgLS0gVGV4dHVyZSBsb2FkaW5nIGRvd24gdG8gcHJvYmxlbXMgd2l0aCBhY2Nl
c3NpbmcgdGhlbSBpbiB0aGUgamFycmVkIHJlc291cmNlLiAgV2lsbCBhdHRlbXB0IGEgZmV3IGl0
ZXJhdGlvbnMgb24gaG93IEkgcmVmZXJlbmNlIHRoZW0gaW4gdGhlIFgzRC9Wcm1sIGZpbGVzIChp
ZSBodHRwOi8vIm15VGV4dHVyZS5wbmciLCAiZmlsZTovL29yZy9ucHNuZXQvdi9wbGF0Zm9ybXMv
c3VyZmFjZS92aWV3cy9teVRleHR1cmUucG5nLA0KImh0dHA6Ly8uLi4NCmV0YyANCmFuZCByZXBv
cnQgb24gYW55IHN1Y2Nlc3MuDQogDQpBbGFuIGhhcyBnb3R0ZW4gdGhlbSB0byBsb2FkIG5vdyBp
biB0aGUgWGozRCBqYXZhM2QgbG9hZGVyIGV4ZW1wbGFyIHdpdGggdGhlIE01KyBzdHVmZiBoZSBz
ZW50IHRoZSBvdGhlciBkYXkuDQogDQpKYW1lcw0KIA0KIA0KIA0KIA0KIA0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0gDQpGcm9tOiBLYXBvbGthLCBBbmRyemVqIA0KU2VudDogV2VkIDgvMTQv
MjAwMiA5OjQ5IEFNIA0KVG86IE5QU05FVC1WIA0KQ2M6IA0KU3ViamVjdDogW25wc25ldHYtZGV2
ZWxvcGVyc10gUmU6IE5QU05FVCBzdHVmZg0KDQoNCg0KCUphbWVzLS0NCgkNCgkgICAgIFRoaXMg
aGFzIGNvbWUgdXAgbWFueSB0aW1lcyBiZWZvcmUuICBUaGUgcmVhc29uIHdlIGhhdmVuJ3QgZGVm
aW5lZCBhDQoJRFREIG9yIHNjaGVtYSBmb3IgdGhlIE5QU05FVC1WIGNvbmZpZ3VyYXRpb24gZm9y
bWF0IGlzIHRoZSBzYW1lIHJlYXNvbiBBbnQNCglidWlsZCBmaWxlcyBkb24ndCBoYXZlIHNjaGVt
YXMtLWJlY2F1c2UgeW91IGNhbiBhZGQgbmV3IHR5cGVzIG9mIGVsZW1lbnRzIG9uDQoJdGhlIGZs
eSwgZXZlbiBpbiB0aGUgbWlkZGxlIG9mIHBhcnNpbmcgYSBzaW5nbGUgY29uZmlndXJhdGlvbiBm
aWxlLiAgQWxsIG9mDQoJdGhlIGNvbmZpZ3VyYXRpb24gdGFncyBhcmUgdmFsaWRhdGVkIG1hbnVh
bGx5LS1mb3IgZXhhbXBsZSwgaWYgeW91IGRvbid0DQoJaW5jbHVkZSBhIHJlcXVpcmVkIGF0dHJp
YnV0ZSwgaXQncyB0aGUgYXBwbGljYXRpb24gcmF0aGVyIHRoYW4gdGhlIHBhcnNlcg0KCXRoYXQg
aXNzdWVzIGFuIGVycm9yIG1lc3NhZ2UuDQoJDQoJICAgICBUaGF0IHNhaWQsIEkgaGF2ZW4ndCBs
b29rZWQgdG9vIGRlZXBseSBpbnRvIHVzaW5nIHNjaGVtYXMgcmF0aGVyIHRoYW4NCglEVERzLiAg
Q29uZmlndXJhdGlvbiBkb2N1bWVudGF0aW9uIHdpbGwgaGVscCwgYnV0IGl0IHdvdWxkIGJlIG5p
Y2UgdG8NCgl2YWxpZGF0ZSB0aGUgdGFncyBhdXRvbWF0aWNhbGx5Lg0KCQ0KCSAgICAgLS1BbmRy
emVqDQoJDQoJLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KCUZyb206ICJIYXJuZXksIEph
bWVzIiA8andoYXJuZXlAbnBzLm5hdnkubWlsPg0KCVRvOiAiS2Fwb2xrYSwgQW5kcnplaiIgPGFr
YXBvbGtAbnBzLm5hdnkubWlsPg0KCVNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE0LCAyMDAyIDg6
NTUgQU0NCglTdWJqZWN0OiBOUFNORVQgc3R1ZmYNCgkNCgkNCglOUFNORVQgc3R1ZmZIZXksDQoJ
ICAgICBXYXMgd29uZGVyaW5nIGlmIHlvdSB0aG91Z2h0IGl0IG5lY2Vzc2FyeSB0byBkZWZpbmUg
YSBTY2hlbWEgb3IgRFRELCBvcg0KCWJvdGggZm9yIHRoZSBYTUwgYXBwIGZpbGVzIGZvciBOUFNO
RVQ/ICBTdW4gZG9lcyBhIHNpbWlsYXIgdGhpbmcgd2l0aCBKTkxQDQoJYnV0IHJlcXVpcmVzIG5v
IGRlY2xhcmF0aW9uIG9mIGl0IGluIGluc3RhbmNlIGRvY3VtZW50cywgY2hlY2tzIHdpdGhpbiB0
aGUNCglXZWJzdGFydCBBUEkuICBJZiBzbywgSSBjb3VsZCBnaXZlIHRoZSBmaXJzdCB2ZXJzaW9u
IGEgc2hvdCBpZiB5b3Ugd2FudC4NCglMb29raW5nIGJhY2sgb3ZlciB0aGUgM21pbGxpb24gZW1h
aWxzIG9yIHNvIEkndmUgYnVnZ2VkIHlvdSB3aXRoLCBhIGxvdCBkZWFsDQoJd2l0aCB0aGUgYXJl
YSBvZiBhbGxvd2FibGUgb3IgY29ycmVjdCBzeW50YXggaW4gdGhlIGFwcCBmaWxlIGFuZCB0aGlz
IG1pZ2h0DQoJYWlkIG90aGVycy4gIERpZG4ndCBrbm93IGlmIHlvdSB3ZXJlIGFscmVhZHkgZG9p
bmcgYXMgcGFydCBvZiB0aGUgY29uZmlnDQoJZG9jcyBvciBub3QuICBUYWxrIHRvIHlvdSBsYXRl
ciwgSmFtZXMNCgkNCgkNCgkNCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJVGhpcyBzZi5uZXQgZW1haWwgaXMgc3BvbnNvcmVk
IGJ5OiBEaWNlIC0gVGhlIGxlYWRpbmcgb25saW5lIGpvYiBib2FyZA0KCWZvciBoaWdoLXRlY2gg
cHJvZmVzc2lvbmFscy4gU2VhcmNoIGFuZCBhcHBseSBmb3IgdGVjaCBqb2JzIHRvZGF5IQ0KCWh0
dHA6Ly9zZWVrZXIuZGljZS5jb20vc2Vla2VyLmVwbD9yZWxfY29kZT0zMQ0KCV9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJbnBzbmV0di1kZXZlbG9wZXJz
IG1haWxpbmcgbGlzdA0KCW5wc25ldHYtZGV2ZWxvcGVyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQN
CglodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9ucHNuZXR2LWRl
dmVsb3BlcnMNCgkNCg0K