I think we are talking about similar kinds of things, at least in the general
ballpalk, anyhow.
On Apr 15, 6:04am, Don Brutzman wrote:
> Here is a possible view of behaviors. It merely extends existing
> engine examples in OpenInventor (OI) to build on a common vocabulary.
> - Engine outputs only operate on the scene graph. Thus behaviors do not
> have any explicit control over the host machine (unlike CGI scripts).
I'm sure that restricting behaviours in some way is good, but this is a little
too restrictive (?) .. what happens if, say, I want to produce a mixed text-VR
environment ?? Or connect to a mud, etc. In such cases, only one set of engine
outputs should be connected to the browser. See my earlier post and see if you
agree with any of it ..
> - A wide variety of behavior mechanisms might stimulate engine inputs.
I'm not sure that I think that the behavior mechanisms need to stimulate engine
inputs, though I do see a performance advantage. Might it not be better to start
with simple events (see below) and scale to more complex mechanisms if simple
stuff seems impractical. I also feel that this further cements VRML==Inventor.
> - Sensors & algorithmic calculator methods in OI provide numerous
> deterministic stimuli. Some or all might be practical for VRML 2.0
See above. One good avenue of discussion would be "What kind of events should
the browser support" ... though I do like the idea of programmable event
parsing on the browser side. Sort of like "Look for this sequence of things, and
when it occurs, let me know using this token". I'm just worried about
VRML=Inventor.
> - Scripted actions might be embedded in the scene graph, sent live over
> the network or read from a file/URL. Network connections might be
> MUD/MUSH/MOO, multicast channel, etc.
Yup. I think that we agree on the embedding of behavior in the scene graph.
> - Message passing can be done by local user or a software agent.
What kind of message passing are we talking about here ?? Between browser and
external application ? external applications ? Between browsers ?
> - IEEE Distributed Interactive Simulation (DIS) protocol provides a
> variety of mechanisms for entity-level (application layer) interactions.
> Most likely an 'extended subset' approach to DIS is most practical.
> DIS Entity State PDUs are the primary way that physically-based entities
> communicate position/posture, dead reckon, and deal with latency simply.
> There is no need to start from scratch on network-based entity physics.
I think it would behoove us all to read up massivly on DIS. A repost of the URLs
might be in order.
> - Any network connections that are unicast (point-to-point) instead of
> multicast (several-to-many) will not scale up.
This is definitly true. PARC have shown that it is hard to run a textual mud
server with 200 users w/o lag using a conventional client-server approach. Even
with a 100x improvement in server capacity, this still does not look good, and
bogs down eventually.
> Thus let's continue
> Chris Hall's opening thread and keep hammering on just what 'behaviors' are.
<Hammer>
Later !
-- Mike