OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [huml] X3D Spec Stuff

Title: X3D Spec Stuff
Hi Folks,

I told Rob at last night's meeting that I would send him some references about a few factoids I passed along in connection with the work I am doing that uses the latest X3D Specification. It occurred to me that I have not sent out the word that this revision of the core and extended XML Specs for the next version of the ISO 3D standard to replace VRML97 is pretty much it after a year since the last major technical review.

So here it is:

Architecture and API:

XML Encodings:

The particular issue I described is the Distributed Interactive Simulation (DIS) components:

What I was specifically talking about was a small but significant change that deals with routing events into and out of objects and subobjects within objects in the scenegraph (world) that pertains to Humanoid Animations even though the example given in the spec is not.

What it means is that you move the internal  parts (in Avatars, that is the invisible inner skeleton structure such as what I show in my facial animation on my website) in relation to the whole object, not the skin that covers the collection of geometrical constructs, and those movements (interpolations) are referenced in relation to the object's own coordinates not the world coordinates.

Espdu stands for Entity State Protocol Data Unit

> Specification:  ISO/IEC FCD 19775-1--X3D--Part 1: Architecture
> Clause:      28.3.1 EspduTransform
> Comment:
> http://www.web3d.org/technicalinfo/specifications/ISO_IEC_19775/Part01/components/dis.html#EspduTransform
> Insert the following as new fourth paragraph (preceding
> paragraph beginning with \"The EntityStatePDU provides
> notification of ...\")
> Articulation parameter inputOnly events (beginning with \"set_\"
> prefix) and outputOnly events (ending with \"_changed\" suffix)
> are provided for the articulationParameters array in order to
> enable simple routing of primary events of interest into (and
> out of) the array.  As an example, if 8 articulation parameters
> were needed for an EspduTransform controlling the movable parts
> of a race-car model, each of these articulation parameters might
> be individually routed as necessary.  Events into (and out of)
> articulationParameter subscripts [8] through [78] must be
> accomplished either by a separate Script node mechanism, or else
> by complete routing/replacement using an MFFloat event.

Yeah, I know, but you don't necessarily need to read code to understand the principles.


Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC