[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
{Spam?} RE: [www-vrml] some questions about X3D
Hi,
For information, here's the header definition for my CortoLink ExternProto
(could be simplified in x3D).
Mostly aimed a multiScreening (1 master / n slaves), it's been used for
small MU systems.
To turn a model into a MS (multi screen) display, just break inner ROUTES,
and relink them thru the Proto.
Extensible Proto definition makes it possible to add any number of eventIns
and Out in the Proto/ExternProto definitions, without otherwise change in
Proto code.
This scheme allows to avoid having extra fanIn/fanOut (or parser) glue logic
to author (either in the Proto or in the model scripts), gives more atomic
messages, enables multiple begin/endUpdate events (just define as much as
you like, and use them to trigger message gates).
Usually, authoring the shift from a single display to multiple displays is
easy (break and relink Route statements) providing direct node access from
script is replaced by corresponding routing statements beforehand.
Connecting to any other application / server / webService is immediate too
(for a developer !...).
There again, I can see no problem in porting to this x3D, providing COM
access in the script body ...
Otherwise, supporting this means leaving IE for HTML, and developping a
dedicated VR sandbox, providing extra services (easy enough for any
developer).
Eric.
'-----------------------------------------------------------------------
#VRML V2.0 utf8
PROTO VP_Linker # since you may have several versions of this on the same
computer, you may like to give different names : it's possible.
[
####### Customizable Area #########
#
# The interesting stuff starts here : you may add, modify, remove
any event in the following part
#
# following fields can be named whatever you want, providing that :
# eventOut names are ending with "_changed"
# there are matching eventIns and Outs
# you can add any number of those events, of the following types :
# SFVec2f
# SFVec3f
# SFRotation
# SFString
# SFInt32
# SFFloat
# SFColor
# SFBool
# SFTime (internal clocks synch mechanism is provided)
# MFTypes will be handled in the future if needed.
# In this example a set of events is used, just remove / add events
to suit your needs
#-----------------------------------------------------------
eventIn SFVec3f vec3f
eventOut SFVec3f vec3f_changed
eventIn SFFloat flot
eventOut SFFloat flot_changed
eventIn SFColor color
eventOut SFColor color_changed
eventIn SFRotation rot
eventOut SFRotation rot_changed
eventIn SFBool bool
eventOut SFBool bool_changed
eventIn SFInt32 int
eventOut SFInt32 int_changed
eventIn SFString str
eventOut SFString str_changed
#-----------------------------------------------------------
######## ATTENTION events of the custom area must be reflected in
Script below !!!! #########
####### End of Customizable Area #########
###### Caution Area ######## Handle with care ...
# next fields are used to link to a peculiar server (machine)
# default adress is intended for tests (all clients and server on
the same local machine)
# replace hostname by the network name (or IP adress) on wich the
server application is located
# Name field can be whatever you want (are ?)
field SFString HostName "127.0.0.1" # 127.0.0.1 is the adress of
your machine (the one you're using to read this), so with this setting, the
server ought to run on this machine !
field SFString Name "Mickey Mouse" # Set this to whatever suits you
eventOut SFString Connected # I'm connected (found the server) and
initializing stuffs
eventOut SFBool upAndRunning # OK, ready to go. Avoid sending
(continuous) events before connection ...
# use this to enable transferts.
# Screen synchronisation is, by definition an asymetric function :
there is the screen you want other screens to synchronize to, and, the other
screens.
# let's call the first 'master', and the others 'slaves', or
'source' and 'sinks' (as you prefer)
# following fields are used for position and attitude information
exchange
field SFBool positionTracking FALSE # this switches position
tracking on master and/or slaves displays (if False then user position is
ignored, not read and not set)
field SFBool positionUpdatesSource FALSE # set to TRUE for the
'master' display.
# note : please, define only one master, otherwise be prepared to
face conflicts ... (seems evident though ...)
# hint : usually a given display (read : computer) is always master
or slave (source or sink) : why not setting it here in Proto definition ?,
so all referring wrls on the machine will be set at once ?
# same goes for following fields ...
field SFTime timeStep 0 # interval beetween two position readings in
seconds
# if 0 : continuous
reading (much better ... but needs computer horsepower)
# you may, or may not want slaves screens to look in the same
direction
# usually, for multiscreen applications, you don't ... here's the
place to set this.
# I'll leave you the trig, screen measurement, screen orientation
tweaking, screen case thickness accounting, fov setting ...
# if you don't move the screen around, adjust those settings here,
in the ExternProto definition
field SFFloat camFov 0.785398
field SFVec3f camPos 0 0 0
field SFRotation camOrient 0 0 1 0
eventOut SFVec3f userPos
eventOut SFRotation userOrient
# Do not instanciate more than one PROTO in a single VRML model
(unless you really like challenges)
]
{
Script
{
####### Customizable Area #########
# All custom events *must* be repeated here
# this is definetely necessary for correct handling
# (and avoiding computer crashes / nervous
breakdown)
#----------------------------------------------
eventIn SFVec3f vec3f IS vec3f
eventOut SFVec3f vec3f_changed IS vec3f_changed
eventIn SFFloat float IS flot
eventOut SFFloat float_changed IS flot_changed
eventIn SFColor color IS color
eventOut SFColor color_changed IS color_changed
eventIn SFRotation rot IS rot
eventOut SFRotation rot_changed IS rot_changed
eventIn SFBool bool IS bool
eventOut SFBool bool_changed IS bool_changed
eventIn SFInt32 int IS int
eventOut SFInt32 int_changed IS int_changed
eventIn SFString str IS str
eventOut SFString str_changed IS str_changed
#------------------------------------------------
###### Stand Off ! area #########
# following lines shouldn't be changed
# (for avoiding computer BSOD and user frustration)
field SFString HostName IS HostName
field SFString Name IS Name
eventOut SFString Connected IS Connected
eventOut SFBool upAndRunning IS upAndRunning
field SFTime timeStep IS timeStep
field SFBool positionUpdatesSource IS
positionUpdatesSource
field SFBool positionTracking IS positionTracking
field SFFloat camFov IS camFov
field SFVec3f camPos IS camPos
field SFRotation camOrient IS camOrient
eventOut SFVec3f userPos IS userPos
eventOut SFRotation userOrient IS userOrient
url "nativescript:
libuid=CortoVRCliPlug;
scriptid=Script;
file-win32-x86=CortoVRCliPlug.dll
"
}
}
# Notes / restrictions
# Though this application may run thru the internet, it hasn't been build
for this.
# lag time, network load, may prevent it from delivering expected results.
# This application is usually harmless, but I will not be held responsible
any damage, nervous breakdown, or paracetamol over dose.
# If you encounter difficulties just send me a mail ( eric@geovrml.com ).
# If you can't set cameras to cover your screens area, read the spec
concerning viewpoints and FOV, dig back your college cheat sheets about
trigonometry, renew your calculator batteries, clean up your plastic ruler,
call a friend, try a rough estimate and guess, have a nap, read again the
specs. But please don't ask me (unless you're living in the South of France,
and call me for a drink first).
# Oh, and if this makes you think about a killer app, and you need someone
to talk to about it : don't hesitate ... eric@geovrml.com :)
# Linking in/out from/to another software / sensor driver / actuator
driver, the mechanism is identical
# you just need to implement a tiny plug interface able to directly
feed-to / read-from the server
# this information isn't provided in this package.
# You may either ask me to develop the bit of software needed or ask me
about the needed interface implementation.
# You may also check below for such softwares that already exists or are
on their way :
# in the nursery (december 2003):
# dynamic 3D intervisibility calculation and display (planned
adaptation of previous work)
# 2.5D best path finder (shortest path with obstacle avoidance,
best gradient pick) (planned adaptation of previous work)
# a Boeing/Cessna/Jet flight dynamics engine system (adaptable to
any kind of plane -not helicopters- thru look up tables), to fly around in
your (geo?) models :) (planned adaptation of previous work)
# available (december 2003)
# game control pad interface (any as long as it's plug and play),
similar to EMIExtDevHandler (those using it will know :) )
# Microsoft Flight Simulator link (position and attitude). Less
performing imho than my flight dynamics engine, but available and versatile.
# position is long/lat, available in cartesian Lambert
conformal conic for french users (Lambert II étendu). Other local cartesian
projections on demand.
# on demand :
# external 2D control panel (designed on demand), using any
gauges, compasses, indicators, sliders, LED matrix, switches, rock buttons
etc, you're dreamin about (from car driving to plane cockpit, going thru
industrial machinery interface)
'--------------------------------------------------------------
-----Message d'origine-----
De : owner-www-vrml@web3d.org [mailto:owner-www-vrml@web3d.org] De la part
de Paul Aslin
Envoyé : vendredi 3 septembre 2004 08:58
À : 'www-vrml'
Objet : Re: [www-vrml] some questions about X3D
Wouldn't it make more sense to provide a ECMA script Browser call which
would send data packets to the remote server ?
Say:
Brower.sendDataPacket(data,server,port,method,loginID);
where method is UDP etc. presumably we can use use eventsProcessed or
Brower.addRoute... to receive infomation.
See that way developers would be free to implement whatever systems they
needed, as opposed to having to try and alter an existing system which is
coded in the X3d brower itself.
One further advantage would be to allow connections to multiple server's at
once.
I have tried doing something simple with Blaxxun Connunity server, simply
trying to change the LOD distance used to SharedObjects has proven
impossible because the code to write the objects is part VRML and part OCX
plugin.
Should we stipulate/provide a way of allowing X3d scenes to intercept
network communications, rather than having to try to change things later on.
By this I basically mean that multi-user addon system should add items to
scenes via a node rather than directly which creates problems with
syncronzation of data between what is in the scene and what is in Script
nodes.
--- Miriam English <miriam@werple.net.au> wrote:
> Hi Tony,
>
> I'm having a bit of difficulty in expressing this clearly, so please
> bear with me.
>
> First let me say I'm not aiming this at X3D or the consortium or
> anybody as a criticism. I was honestly hoping that some such
> functionality might have been added. And I blame myself as much as
> anyone for it not being. If I'd been able understand the problem
> properly I might have been able to suggest something. Well, I guess
> that's what I'm doing now.
>
> There are a some networking nodes and javascript and java calls in
> VRML, and X3D already. They have fairly specialised functions, for
> example Inline, createVrmlFromURL(), AudioClip, Background,
> ImageTexture, MovieTexture, getWorldURL(), loadURL(), ExternPROTO. It
> is good that we have these just as we have specialised geometry nodes
> like Sphere, Cylinder, and Box. But the problem is, while we can
> create a different kind of object from low-level geometry
> (IndexedFaceSet), we can't do the same for networking. I can't use a
> simple, basic node to set up a connection with a URL to send and
> receive events.
>
> I have to think more about this to be able to define the problem
> properly, let alone a good solution, but off the top of my head a
> simple way of doing it might look something like this (in VRML,
> because that is what I'm most familiar with):
>
> Net {
> url MFString
> protocol "http" #or "udp" or "rtp" or ??
> in eventType name #define data to be got from the network
> out eventType name #define data to be sent to the network
> #eventIn eventType name #receive from the scene elements to go to
> the net
> #eventOut eventType name #send to the scene elements from the net }
>
> This is probably incomplete and a bit hazy -- remember this is just
> off the top of my head. (I've probably got the in and out attributes
> wrong -- I haven't had breakfast yet and I've been up half the day
> already. :) But something like this should be so flexible that you
> could build any of the other nodes or java/javascript functions from
> it.
>
> I am far from being an expert in these matters, so I'm just throwing
> this out there.
>
> We definitely need something that does general-purpose simple comms
> from inside VRML/X3D. At the moment we have high level comms without
> low level flexibility. Anyone wanting to handle database access, or
> multiuser, or cookie-like wrl memory, or any one of a number of other
> networked uses, currently has to either hack inappropriately, or build
> upon non-spec proprietary extensions.
>
> Best wishes,
>
> - Miriam
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
-------------------------------------------------------------------------
for list subscription/unscrubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html
-------------------------------------------------------------------------
for list subscription/unscrubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html