<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Note that in HTML a scene author cannot
rely on any imposed limit. The user can always override that value
either in the X3D by changing it after arrival in the browser but
before the parser deals with it OR changing the stored limit while
the scene is running.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Leonard Daly</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67vesQAevKsJx3YyV72-e3m9ofDo0wVCrghksvZK3hhMuA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="auto">
<div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 24, 2019,
8:14 PM Brutzman, Donald (Don) (CIV) <<a
href="mailto:brutzman@nps.edu" target="_blank"
moz-do-not-send="true">brutzman@nps.edu</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks
for the great example - impressive!<br>
<br>
Getting explicit to match your description, it looks
like the key statement is<br>
<br>
<X3D id="x3d" showLog="true" logLevel='5'
width="800px" height="600px"><br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Yes, that is the interface in the example,
attributes to the X3D root.</div>
<div dir="auto"><br>
</div>
<div dir="auto">This probably needs to stay abstract in the
abstract spec.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Browser properties could be a fitting abstract
place.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Not sure how other than XML encodings would
store such a setting.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Adding it to X3D root would seem to work for X3D
applications in a non-HTML context as well. Also makes
it easy for any author, and possible for any model (not
requiring Script node). Thus meets goal of easy
repeatability too.<br>
<br>
Is this approach (attributes on X3D root) acceptable
with everyone, including FreeWrl view3dscene and other
standalone application environments?<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">The spec. also mentions config files for
browser properties, as an example.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
If so, wondering if we are ready to tackle other
attributes on X3D element (such as id width height url)?<br>
<br>
Once we agree on basic approach, we should also discuss
whether scoping of logging is possible. Can it be
turned off for parts of scene graph, does it affect
internals within Inline and ProtoInstance, etc.<br>
</blockquote>
<div><br>
</div>
<div>In my view, it should be simple and not (very)
configurable. So I would suggest logging any ROUTE in
child name scopes, in Inlines and also in
ProtoInstances. The logging output could include a name
scope id.</div>
<div><br>
</div>
<div>This brings up control of logging by a scene author.
Would an additional maxLogLevel root property be
required ? Maybe not.</div>
<div><br>
</div>
<div>I am thinking that there would be two browser
properties, currentLogLevel (or just logLevel) and
maxLogLevel. Both are set initially to the logLevel
value provided by the scene.</div>
<div><br>
</div>
<div>currentLogLevel can then be modified by a sai browser
service. This could be done from a GUI, or from a
script. But it is not allowed to become higher than
maxLogLevel.</div>
<div><br>
</div>
<div>In order to respect logging restrictions, eg.
logLevels, in Inlines, maxLogLevel could be per name
scope, or more simply just be lowered in general by
restricted Inlines. </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Good topic for issue review on X3D Working Group call
Friday morning. Participating in the discussion and
email feedback are both welcome.<br>
</blockquote>
<div><br>
</div>
<div>I will try to come up with more specifics for spec.
purposes.</div>
<div><br>
</div>
<div>-Andreas</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
v/r Don<br>
<br>
<br>
On 10/20/2019 3:18 PM, Andreas Plesch wrote:<br>
> Here is an example implementation using a new
attribute 'logLevel' to<br>
> the X3D element, working as a browser property
interface> <br>
> <a
href="https://raw.githack.com/andreasplesch/x3dom/dcde5c67281c1a3dae6b20b1944065d24d369711/test/functional/widgetPlaneSensor.html"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://raw.githack.com/andreasplesch/x3dom/dcde5c67281c1a3dae6b20b1944065d24d369711/test/functional/widgetPlaneSensor.html</a><br>
> <br>
> logLevels 5 and higher turn on event logging.<br>
> <br>
> [For x3dom it may make sense to reserve lower
levels for system level<br>
> logging: exceptions, errors, warnings, information]<br>
> <br>
> The format here is FROM node type, node def name
(or null), field<br>
> name, field value<br>
> <br>
> Perhaps it suffices to just focus on the ROUTE
level logging since<br>
> these events are usually the only one of interest.<br>
> <br>
> The 'trace' attribute in x_ite_dom has a similar
effect (except not<br>
> restricted to ROUTEd events).<br>
> <br>
> So two implementations of such a logging feature
may not be out of reach.<br>
> <br>
> -Andreas<br>
> <br>
> On Sun, Oct 20, 2019 at 3:58 PM Andreas Plesch <<a
href="mailto:andreasplesch@gmail.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">andreasplesch@gmail.com</a>>
wrote:<br>
>><br>
>> On Sat, Oct 19, 2019 at 2:04 AM Brutzman,
Donald (Don) (CIV)<br>
>> <<a href="mailto:brutzman@nps.edu"
rel="noreferrer" target="_blank"
moz-do-not-send="true">brutzman@nps.edu</a>> wrote:<br>
>>><br>
>>> Thanks for the great analysis Andreas.<br>
>>><br>
>>> Sorry for mystery assignment... we do need
someone to take charge of this one. Can defer to
someone else if you prefer.<br>
>>><br>
>>> There is much to be said for Logger staying
directly aligned with Browser services. But, if that is
where we leave it, am expecting that logging will be
rarely used because use of Browser services requires a
Script node and adaptation code - tedious and
inconsistent. Much better for encouraging use is to
also have a consistently defined Logger node that any
author can configure or ROUTE to, in any scene, for
consistent testing and conformance/QA.<br>
>><br>
>> I would envision logging to be a browser
feature which can be set in<br>
>> the browser interface, or as a PARAM for html
as other browser<br>
>> properties: <a
href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#BrowserProperties"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#BrowserProperties</a>.<br>
>> x3dom uses an Environment node to set various
Browser options. It<br>
>> would be very easy to use. The point is that it
is easier to use than<br>
>> a Logger node because it would not require
modifying the content of<br>
>> the scene.<br>
>><br>
>> The browser option would be make a Logger node
unnecessary. So the<br>
>> spec. would not have to define a Logger node.<br>
>><br>
>>><br>
>>> Quote: "when you come to the fork in the
road, take it" - Yogi Berra<br>
>>><br>
>>> Hmmm, I guess we need to put such a Logger
node in Core profile for full generality and usefulness.<br>
>>><br>
>>> Are you saying that logLevel is for
automatic logging of all events, rather than explicitly
ROUTEd input values? Interesting possibility... if so,
once again we might achieve best of both worlds by
having one logLevel setting be for ROUTEd input values
only. That would seem to give authors both simple
flexibility and fine-grained control.<br>
>><br>
>> Yes. Only ROUTEd events was one of the
LogLevels I had listed (the first one).<br>
>><br>
>>><br>
>>> Am willing to create a Prototype that at
least creates a Script node console log illustrating
proper text outputs. (File saving not allowed in Script
node sandbox.)<br>
>><br>
>> That would be useful in any case.<br>
>><br>
>>><br>
>>> Looks like the variations of logging
support desired for a given model can all be expressed
in the Logger node itself, meaning that we wouldn't have
to modify any X3D/head/Scene parameters. Simple is
good.<br>
>><br>
>> Yes, but it is even simpler to not have to have
a Logger node. It<br>
>> would be just a matter of switching on Logging
in the browser. No<br>
>> scripting required.<br>
>><br>
>> Best, -Andreas<br>
>><br>
>>><br>
>>> I agree that we seem to be getting closer
on this one.<br>
>>><br>
>>> On 10/18/2019 12:08 PM, Andreas Plesch
wrote:<br>
>>>> I received a mystery email from the
Mantis tracker about being<br>
>>>> assigned a Logger entry. The forwarded
Mantis summary seems pretty<br>
>>>> comprehensive. It focuses on a Logger
node.<br>
>>>><br>
>>>> Another way to think about logging of
events is as a browser feature<br>
>>>> which can be enabled, parallel to a
debugger. This is how I would<br>
>>>> first think about logging. As a system
feature, not as a scene content<br>
>>>> feature. It seems counterproductive to
have to modify/augment a scene<br>
>>>> with extra nodes, scripts and routes to
enable logging.<br>
>>>><br>
>>>> So my suggestions would be to turn this
into a Browser Property or<br>
>>>> Browser Option. Scene's could hint with
a SAI script what level of<br>
>>>> logging they allow, expecting the
browser to respect the hint. Note<br>
>>>> that a Logger node would not prevent
browsers from unauthorized<br>
>>>> logging if a browser really wanted to.<br>
>>>><br>
>>>> Is the main security concern that with
logging an otherwise protected<br>
>>>> scene (perhaps by encryption) would
expose its data (geometry, raw<br>
>>>> imagery) ?<br>
>>>><br>
>>>> Enabled logging would just log output
events by nodes selected by<br>
>>>> loglevel, always to the console (which
may be recorded in a file<br>
>>>> anyways), in a standard format as
outlined in the Mantis summary.<br>
>>>> Filtering can be applied by other
tools. There are a lot of events<br>
>>>> zipping around.<br>
>>>><br>
>>>> loglevels could be combinations of:<br>
>>>> - ROUTES: only events which go through
routes<br>
>>>> - Sensors: events generated by any
Sensor<br>
>>>> - Scripts: events generated by Scripts<br>
>>>> - Interpolators/Sequencers: events
generated by those<br>
>>>> - component: events generated by all
nodes defined in a component ("Networking")<br>
>>>> - all: deluge from all nodes<br>
>>>> - none: no logging, default<br>
>>>><br>
>>>> I suppose one way to think about this
as a browser feature is to have<br>
>>>> implicit Logger nodes and routes from
all the nodes selected by<br>
>>>> loglevels. The advantage from a spec.
perspective that the mechanism<br>
>>>> does not have to be explicitly
prescribed, only the functionality.<br>
>>>><br>
>>>> So I think it boils down to:<br>
>>>><br>
>>>> a) What is the standard format of the
logging output ? Perhaps easy to define.<br>
>>>><br>
>>>> b) What is logged ? output events of
some or all nodes.<br>
>>>><br>
>>>> c) The browser service specification:<br>
>>>><br>
>>>> - it may be possible to piggy back on
setBrowserOption which uses this<br>
>>>> table: <a
href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#t-BrowserProperties"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#t-BrowserProperties</a><br>
>>>> :<br>
>>>> add a property:<br>
>>>> Name: LogLevel<br>
>>>> Description: allow logging of events to
console<br>
>>>> Range: see above<br>
>>>> Default: None<br>
>>>><br>
>>>> And perhaps a header (meta?) entry
'maxLogLevel' in the Scene to limit<br>
>>>> logging, by a Scene author:<br>
>>>> <a
href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#HeaderStatement"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#HeaderStatement</a>.<br>
>>>> Or allow resetting of the Browser
Option by the Scene with an<br>
>>>> initialize script.<br>
>>>><br>
>>>> I think once a more precise spec.
language is provided, multiple<br>
>>>> browser implementation could be quickly
had.<br>
>>>><br>
>>>> Any feedback welcome.<br>
>>>><br>
>>>> -Andreas<br>
>>>><br>
>>>> On Wed, Oct 16, 2019 at 10:27 PM
Andreas Plesch <<a
href="mailto:andreasplesch@gmail.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">andreasplesch@gmail.com</a>>
wrote:<br>
>>>>><br>
>>>>> x_ite_dom can log all out events by
adding a 'trace' attribute to the x3dcanvas element.<br>
>>>>><br>
>>>>> x3dom does not have built-in
logging . Instead, all web browsers have powerful
debuggers which can be used to follow the event flow
(and all internals). Chrome even lets you modify code
and then continue, or restart.<br>
>>>>><br>
>>>>> This also applies to x_ite.<br>
>>>>><br>
>>>>> Andreas<br>
>>>>><br>
>>>>> ---on the phone---<br>
>>>>><br>
>>>>> On Wed, Oct 16, 2019, 6:40 PM <<a
href="mailto:x3d-public-request@web3d.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">x3d-public-request@web3d.org</a>>
wrote:<br>
>>>>>><br>
>>>>>> Send x3d-public mailing list
submissions to<br>
>>>>>> <a
href="mailto:x3d-public@web3d.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">x3d-public@web3d.org</a><br>
>>>>>><br>
>>>>>> To subscribe or unsubscribe via
the World Wide Web, visit<br>
>>>>>> <a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>>>>> or, via email, send a message
with subject or body 'help' to<br>
>>>>>> <a
href="mailto:x3d-public-request@web3d.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">x3d-public-request@web3d.org</a><br>
>>>>>><br>
>>>>>> You can reach the person
managing the list at<br>
>>>>>> <a
href="mailto:x3d-public-owner@web3d.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">x3d-public-owner@web3d.org</a><br>
>>>>>><br>
>>>>>> When replying, please edit your
Subject line so it is more specific<br>
>>>>>> than "Re: Contents of
x3d-public digest..."<br>
>>>>>><br>
>>>>>><br>
>>>>>> Today's Topics:<br>
>>>>>><br>
>>>>>> 1. Re: Data logging
support in X3Dv4 (Brutzman, Donald (Don) (CIV))<br>
>>>>>><br>
>>>>>><br>
>>>>>>
----------------------------------------------------------------------<br>
>>>>>><br>
>>>>>> Message: 1<br>
>>>>>> Date: Wed, 16 Oct 2019 15:31:25
+0000<br>
>>>>>> From: "Brutzman, Donald (Don)
(CIV)" <<a href="mailto:brutzman@nps.edu"
rel="noreferrer" target="_blank"
moz-do-not-send="true">brutzman@nps.edu</a>><br>
>>>>>> To: Michalis Kamburelis <<a
href="mailto:michalis.kambi@gmail.com"
rel="noreferrer" target="_blank"
moz-do-not-send="true">michalis.kambi@gmail.com</a>><br>
>>>>>> Cc: X3D Graphics public mailing
list <<a href="mailto:x3d-public@web3d.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">x3d-public@web3d.org</a>>,
Feng Liu<br>
>>>>>> <<a
href="mailto:LIU_F@mercer.edu" rel="noreferrer"
target="_blank" moz-do-not-send="true">LIU_F@mercer.edu</a>><br>
>>>>>> Subject: Re: [x3d-public] Data
logging support in X3Dv4<br>
>>>>>> Message-ID: <<a
href="mailto:2f511aa0-9a21-1fc6-7b36-3f43114186b1@nps.edu"
rel="noreferrer" target="_blank"
moz-do-not-send="true">2f511aa0-9a21-1fc6-7b36-3f43114186b1@nps.edu</a>><br>
>>>>>> Content-Type: text/plain;
charset="utf-8"<br>
>>>>>><br>
>>>>>> Thank you very much for this
detailed information Michalis.<br>
>>>>>><br>
>>>>>> I have created Mantis issue
1263 to track this.<br>
>>>>>><br>
>>>>>> * <a
href="https://www.web3d.org/member-only/mantis/view.php?id=1263"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://www.web3d.org/member-only/mantis/view.php?id=1263</a><br>
>>>>>><br>
>>>>>> Who would like to take charge
of the issue: Next steps include:<br>
>>>>>><br>
>>>>>> - reconciling implementations
X3DOM, Castle Game Engine and adding others (X_ITE,
FreeWrl, etc.),<br>
>>>>>> - one or two example scenes
(with outputs) to confirm conformance,<br>
>>>>>> - draft specification prose,
including security considerations.<br>
>>>>>><br>
>>>>>> We can all assist via the
mailing list. Having someone in charge will help.<br>
>>>>>><br>
>>>>>> On 10/14/2019 11:58 PM,
Michalis Kamburelis wrote:<br>
>>>>>>> Hi,<br>
>>>>>>><br>
>>>>>>> Instant Reality and Castle
Game Engine implement a "Logger" node, that<br>
>>>>>>> seems in line with your
thinking :) It was indeed quite useful in some<br>
>>>>>>> cases when I wasn't sure
what/when events are generated by something.<br>
>>>>>>><br>
>>>>>>> See:<br>
>>>>>>> - <a
href="https://doc.instantreality.org/documentation/nodetype/Logger/"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://doc.instantreality.org/documentation/nodetype/Logger/</a>
( note<br>
>>>>>>> that the CSS of Instant
Reality docs seems broken for me now, but the<br>
>>>>>>> content is readable anyway)<br>
>>>>>>> - <a
href="https://castle-engine.io/x3d_extensions.php#section_ext_logger"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://castle-engine.io/x3d_extensions.php#section_ext_logger</a>
(<br>
>>>>>>> it's a long page, look at
section about "Logger" )<br>
>>>>>>><br>
>>>>>>> The principle is simple:
route *anything* to Logger's "write" field to<br>
>>>>>>> output it to
browser-specific log mechanism. A special type is<br>
>>>>>>> invented here to allow an
input event to receive any X3D field type:<br>
>>>>>>> XFAny .<br>
>>>>>>><br>
>>>>>>> I would say that adding it
to X3D spec may be reasonable (but without<br>
>>>>>>> the "logFile" field), in
the "Event Utilities" component --<br>
>>>>>>> implementing this node is
rather easy, and the usefulness is real.<br>
>>>>>>><br>
>>>>>>> Example in classic
encoding:<br>
>>>>>>><br>
>>>>>>> ```<br>
>>>>>>> DEF MyLogger Logger {<br>
>>>>>>> level 3<br>
>>>>>>> }<br>
>>>>>>> DEF MyKeySensor KeySensor {
}<br>
>>>>>>> ROUTE MyKeySensor.keyPress
TO MyLogger.write<br>
>>>>>>> ```<br>
>>>>>>><br>
>>>>>>> Complete example that works
in view3dscene:<br>
>>>>>>> <a
href="https://github.com/castle-engine/demo-models/blob/master/x3d/castle_extensions/logger.x3dv"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://github.com/castle-engine/demo-models/blob/master/x3d/castle_extensions/logger.x3dv</a><br>
>>>>>>><br>
>>>>>>> Regards,<br>
>>>>>>> Michalis<br>
>>>>>>><br>
>>>>>>> pon., 14 pa? 2019 o 19:24
Brutzman, Donald (Don) (CIV)<br>
>>>>>>> <<a
href="mailto:brutzman@nps.edu" rel="noreferrer"
target="_blank" moz-do-not-send="true">brutzman@nps.edu</a>>
napisa?(a):<br>
>>>>>>>><br>
>>>>>>>> [We explored several
points such as this during today's Web3DUX User
Experience teleconference.]<br>
>>>>>>>><br>
>>>>>>>> Data logging is a
common prerequisite for many types of measurement and
assessment.<br>
>>>>>>>><br>
>>>>>>>> Conventions for logging
via HTML and also directly via X3D need to be
considered. For example, numerous X3D sensor nodes
include the ability to generate output events triggered
by user navigation and interaction. Common data
formatting that identifies system parameters, event
source, timestamp and data streams for a given scene can
facilitate analysis. Defining and adding a logging
function to the X3D Browser object specification can
enable secure recording of information.<br>
>>>>>>>><br>
>>>>>>>> Question: do others
think that logging is important also? Am thinking that
having such a capability is important for measurable
improvements in X3Dv4.<br>
>>>>>>>><br>
>>>>>>>> all the best, Don<br>
>>>>>>>> --<br>
>>>>>>>> Don Brutzman Naval
Postgraduate School, Code USW/Br <a
href="mailto:brutzman@nps.edu" rel="noreferrer"
target="_blank" moz-do-not-send="true">brutzman@nps.edu</a><br>
>>>>>>>> Watkins 270, MOVES
Institute, Monterey CA 93943-5000 USA +1.831.656.2149<br>
>>>>>>>> X3D graphics, virtual
worlds, navy robotics <a
href="http://faculty.nps.edu/brutzman" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">http://faculty.nps.edu/brutzman</a><br>
>>>>>>>>
_______________________________________________<br>
>>>>>>>> x3d-public mailing list<br>
>>>>>>>> <a
href="mailto:x3d-public@web3d.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">x3d-public@web3d.org</a><br>
>>>>>>>> <a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> all the best, Don<br>
>>>>>> --<br>
>>>>>> Don Brutzman Naval
Postgraduate School, Code USW/Br <a
href="mailto:brutzman@nps.edu" rel="noreferrer"
target="_blank" moz-do-not-send="true">brutzman@nps.edu</a><br>
>>>>>> Watkins 270, MOVES Institute,
Monterey CA 93943-5000 USA +1.831.656.2149<br>
>>>>>> X3D graphics, virtual worlds,
navy robotics <a href="http://faculty.nps.edu/brutzman"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://faculty.nps.edu/brutzman</a><br>
>>>>>><br>
>>>>>> ------------------------------<br>
>>>>>><br>
>>>>>> Subject: Digest Footer<br>
>>>>>><br>
>>>>>>
_______________________________________________<br>
>>>>>> x3d-public mailing list<br>
>>>>>> <a
href="mailto:x3d-public@web3d.org" rel="noreferrer"
target="_blank" moz-do-not-send="true">x3d-public@web3d.org</a><br>
>>>>>> <a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> ------------------------------<br>
>>>>>><br>
>>>>>> End of x3d-public Digest, Vol
127, Issue 27<br>
>>>>>>
*******************************************<br>
>>>><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>> all the best, Don<br>
>>> --<br>
>>> Don Brutzman Naval Postgraduate School,
Code USW/Br <a href="mailto:brutzman@nps.edu"
rel="noreferrer" target="_blank"
moz-do-not-send="true">brutzman@nps.edu</a><br>
>>> Watkins 270, MOVES Institute, Monterey CA
93943-5000 USA +1.831.656.2149<br>
>>> X3D graphics, virtual worlds, navy robotics
<a href="http://faculty.nps.edu/brutzman"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://faculty.nps.edu/brutzman</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Andreas Plesch<br>
>> Waltham, MA 02453<br>
> <br>
> <br>
> <br>
<br>
<br>
all the best, Don<br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br
<a href="mailto:brutzman@nps.edu" rel="noreferrer"
target="_blank" moz-do-not-send="true">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000
USA +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a
href="http://faculty.nps.edu/brutzman" rel="noreferrer
noreferrer" target="_blank" moz-do-not-send="true">http://faculty.nps.edu/brutzman</a><br>
</blockquote>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>