[x3d-public] Fw: [x3dom-users] Modifying HTML5 and X3DOM attributes. Templating
Joe D Williams
joedwil at earthlink.net
Fri Feb 19 19:55:09 PST 2016
forwarded to x3d group
Joe
----- Original Message -----
From: "Joe D Williams" <joedwil at earthlink.net>
To: <x3dom-users at lists.sourceforge.net>; "Leonard Daly"
<web3d at realism.com>
Sent: Friday, February 19, 2016 6:21 PM
Subject: Re: [x3dom-users] Modifying HTML5 and X3DOM attributes.
Templating
>
> ----- Original Message -----
> From: "Leonard Daly" <web3d at realism.com>
> To: "Joe D Williams" <joedwil at earthlink.net>;
> <x3dom-users at lists.sourceforge.net>
> Sent: Sunday, February 07, 2016 7:44 PM
> Subject: Re: [x3dom-users] Modifying HTML5 and X3DOM attributes.
> Templating
>
>
>> Joe,
>>
>>
>>>> In my experience, all of the interesting X3D PROTOs contain a
>>>> Script
>>>> node. Without a Script node, I have not seen or been able to
>>>> construct
>>>> something that is any different than an Inline. If one exists, I
>>>> would
>>>> like to know about it.
>>> One example would be he HAnim prootypes shown in the current
>>> Humanoid
>>> Animation standard 19774:2006 Annex A.
>>
>>
>> I looked at the example. It appears to me that an H-Anim compliant
>> figure is being modeled.
>
> This is a prototype that defines some HAnim components
>
>> There is no one that I know of that does figure
>> modeling or animation this way now.
>
> Right, if the native code eists, making the proto not necessary
>
>> The figures are highly detailed, and
>> the animations are carefully refined. H-Anim (in my opinion) should
>> be
>> focused on defining standards for naming and modeling of humanoid
>> with
>> extensions for non-humanoids.
>
> It is.
>
>> It was my understanding that ISO standards
>> need to reflect established art or engineering. If H-Anim is not
>> working
>> closely with modelers and animators, then it will not be used by
>> the
>> biggest source of 3D figure creators.
>
> It is. All modelers use this structure under the covers.
>
>>
>> Modelers currently use Maya or Blender (or something similar) for
>> the
>> modeling. The model is not hand coded. Animators use the term
>> "bones" to
>> refer to joints.
>
> No actually the animators uses the term bones and the 'joints' are
> sort of hidden. It is magic that orientation of bone is also
> represented by the rotation angle of the parent joint.
>
>
>> The animation is done on the bones.
>
> Look closer to see that while the animator works with placing the
> bones, line in an old-time armature, the work is done in the joints,
> with bind the model together and allow the f/r kinematics.
>
>> The skin is
>> deformed according the display engine and the weights assigned on
>> each
>> vertex of the skin to the bones.
>
> That is exactly how X3D HAnim works. Tje names ar differnt but the
> technology and techniques ar the same.
>
>>
>> What I see in the example is a convenience mechanism to define a
>> figure
>> and not a reflection of the way things are done commercially.
>
> You are right that the typical model programs like Maya or Blender
> or Max use the same structure and interfaces as X3D HAnim but the
> names are different.
>
> For example if you select Biped in Max or similar prefab basic model
> in any other, what you get is close to LOA2 HAnim.
> Do a bit further checking and you will find that indeed, the big
> time model toolmakers turned over the whole thing to VRML. Look at
> the skeleton and how the skin deformations are weighted. Most of the
> big tools will export an X3D Humanoid.
>
> The biggest problem is that for most tools the animation is done by
> interpolating quaternions rather than axis-angle.,
>
> So, it is patently not true that X3D HAnim is different than the
> typical widely used tools. X3D HAnim directly exposes the complete
> skeleton and segment-based or deformable skin animation. Plus, we
> specify an initial pose, before animation, that makes it possible to
> transport animations between similar models.
>
> Don and I have worked on refining the 'standard' humanoid defined in
> the spec and I have some other examples. Really, it won't take much
> play with most any commercial hanim tool to see that X3D is
> completely representative and covers the art very well and gives you
> the complete user code to define the model.
>
> Speaking of defining names and locations, the current HAnim model is
> capablae of being upgraded to contain the medical stuff. As far aas
> I have looked, all is directly compatible so we should figure
> example locations for all intenal organs.
>
>
> GENERAL
>
> X3D HAnim Level 1:
> * realistic humanoid skeleton hierarchy
> - Joint, Segment, Site nodes
> * nominal humanoid dimensions
> - Joint and Site nodes
> * geometry bound to Segment and Site nodes
> * Animated by hierarchical rotation and translation
> of Joint nodes
> * Displacer for Segment geometry
> - point displacements by weighted Joint rotation
>
> X3D HAnim Level 2:
> * Level 1 plus 'single-mesh Deformable skin
> - skin points bound to one or more Joint nodes
> - skin deformation by weighted Joint rotation
> * Displacer for skin and segment geometry
> - point displacements by weighted Joint rotation
>
> It is important to recognize that the h-anim character we have is of
> World Standard Quality.
>
> First, H-Anim1 produced a realistic skeleton composed of a very
> complete and realistic 'standard' hierachy of joints and connecting
> segments. Bindings for normative 'standard' medical names of joints
> and segments, along with non-normative typical nominal locations of
> joints and lengths of segments are given. The number of Joint
> objects defines the skeleton Level of Articulation (LOA) with four
> levels, ranging from one joint to 94 joints, are defined.
>
> http://h-anim.org/Specifications/H-Anim200x/ISO_IEC_FCD_19774/concepts.html#Hierarchy
>
> Dimensions are derived From CAESAR data base using a nominal local
> coordinate system with 0,0,0 at the standing surface between the
> feet.This data structure produces a skeleton drawn in nominal
> 'human' dimensions facing +z, in a fairly realistic, what might be
> called a standing "attention" default pose, prior to animation. The
> joint locations, segment lengths, end effecters, and feature point
> locations can be adjusted for the actual dimensions of a specific
> human.
>
> This model produces humanoid motion as expected in that moving the
> humanoid root node moves the entire character, and, for instance,
> rotation of the parent shoulder joint produces expected movement of
> the child arm and hand joints and segments.
>
> Geometry and sensors can be bound to individual joints, segments, or
> defined site locations to produce a wide variety of realistic
> characters.
>
> Additionally, various external surface feature points were defined
> in this skeleton space. The standard includes non-normative but
> 'standard' medical surface feature point names, along with nominal
> 'standard' human surface locations.
>
> This model provided the means to produce animated characters with
> transportable animation routines, given that the initial pose is the
> same or well-known and that the joint hierearchy is the same or
> similar.
>
> H-Anim1 also allows the h-anim Joint node to produce seamless
> deformable skin animation. Each vertex of the skin mesh is bound to
> one, or more if appropriate, Joint(s) of the skeleton. The skin is
> animated by a weighted value depending upon rotation of the bound
> joint(s) as the joints are animated.
>
> Importantly, the Displacer node was specified in h-anim 1.1 for use
> with segment geometry or joint geometry to achieve more specific
> localized geometry vertex deformation. Displacer nodes parented by
> Joint nodes animate skin vertices associated with that Joint node.
> Displacers parented by Segment nodes animate vertices of geometry
> parented by that Sement node.
>
> In order for these deformable skin and displacer animations to be
> transportable without complex processing and some guesswork, the
> 'skin' and any Displacer actuated geometry must also be
> transportable. Transportable skin means that the same vertex, or set
> of vertices, serve the same 'standard' feature points and are bound
> to the same joint(s) in a similar location.
>
> This requirement is similar to the requirements of transporting
> skeletal animations, where the skeleton must be same or similar;
> with a predictable fail for missing hierarchy.
>
> Same or similar skeleton and skin doesn't necessarily mean the same
> 'size' in the sense that the xyz location of each joint and skin
> vertex is identical. The transportable skin does not need to be the
> same 'size' but the skin Must have the same number of points in the
> same order or else the indexing will not work as expected.
>
> So, to produce the 'standard' skins we must produce greater density
> of internal and external feature reference points. This allows
> composition of several different levels of density with bindings to
> complete an H-Anim1 character and demonstrate its operation.
> Finally, we will have an appropriate set of 'standard' skins drawn
> and bound in skeleton space.
>
> Thanks and All Best,
> Joe
>
>
>
>>
>>
>> Leonard Daly
>>
>>
>>
>>
>>> Except for the non-existant proto that would show animation of the
>>> defomable skin and Displacers, no scripts are required to produce
>>> theHuanoid, Joint, Segment, or Site nodes. A couple of browsers
>>> run
>>> HAnim without protos but I haven't fully explored how the details
>>> llike stiffness work. Of course these protos just need added
>>> definitions for how the objects can be used and what they can
>>> contain,
>>> not massaging of internal data. And, looking at details,
>>> parameters
>>> like stiffness would probably need some computation in order to be
>>> fully functional.
>>>
>>> Thanks and Best,
>>> Joe
>>>
>>>
>>> ----- Original Message -----
>>> From: "Leonard Daly" <Leonard.Daly at realism.com>
>>> To: <x3dom-users at lists.sourceforge.net>
>>> Sent: Friday, February 05, 2016 4:36 PM
>>> Subject: Re: [x3dom-users] Modifying HTML5 and X3DOM attributes.
>>> Templating
>>>
>>>
>>>> John,
>>>>
>>>>> So there’s a current going on where we are trying to modify
>>>>> HTML5
>>>>> and X3DOM attributes, either with straight JavaScript or
>>>>> Templating
>>>>> (via AngularJS). While the X3D JSON loader does not support
>>>>> modifying attributes that I know of after the fact (well, it
>>>>> *may*), it dos support specifying @class and @id attribute names
>>>>> for later modification with your favorite JavaScript framework.
>>>>> Templating is likely another issue we need to face. Who has
>>>>> used
>>>>> templating with X3DOM and what success have they had? Should
>>>>> X3DOM
>>>>> support templating as part of its core, or should it be done
>>>>> with
>>>>> web components or a framework like Meteor, Angular.js,
>>>>> handlebars,
>>>>> mustache, etc.?
>>>> I am not sure I understand exactly what you mean by templating. I
>>>> don't
>>>> want to make any assumptions and start going down a completely
>>>> wrong
>>>> path. Can you provide a foundation for the discussion?
>>>>
>>>>> We need to decide pretty quick whether Protos will be supported
>>>>> in
>>>>> X3DOM (perhaps through a prototype expander on the client and/or
>>>>> server side), otherwise, there will be a massive bifurcation of
>>>>> technology (which may be good) and struggle possibly as people
>>>>> attempt to merge various templating frameworks with X3DOM.
>>>> In my experience, all of the interesting X3D PROTOs contain a
>>>> Script
>>>> node. Without a Script node, I have not seen or been able to
>>>> construct
>>>> something that is any different than an Inline. If one exists, I
>>>> would
>>>> like to know about it.
>>>>
>>>> I do not see why there should be a Script node in an html-type
>>>> profile
>>>> for X3D. Having JavaScript (meaning code to manipulate the DOM)
>>>> and
>>>> ECMAScript (meaning code to manipulate X3D's SAI) is dangerous as
>>>> people
>>>> will quickly be confused. The SAI api cannot replace the DOM api
>>>> as
>>>> there are things that can to be done to the DOM that do not make
>>>> sense
>>>> to handle with the SAI. There are also a lot (meaning >>1,000x)
>>>> more
>>>> DOM
>>>> programmers than SAI programmers.
>>>>
>>>> So without Script node, I do not see the need for PROTO. I am
>>>> willing to
>>>> reconsider if you can provide me useful examples that are doable
>>>> in
>>>> PROTO and not Inline or some other means.
>>>>
>>>> Perhaps a better concept might be a MACRO where the contained
>>>> (declarative) code is expanded and parameter values from the
>>>> parent
>>>> are
>>>> substituted to equivalent parameters in the expanded code. That
>>>> probably
>>>> has lots of applications and would be straight-forward to code.
>>>> It
>>>> would
>>>> be sort-of like an Inline with pre-defined parameters. If that is
>>>> the
>>>> case. it would be necessary to define any name-scoping
>>>> limitations
>>>> and
>>>> parameter updates. Perhaps an extended Inline definition would be
>>>> sufficient.
>>>>
>>>>
>>>> Leonard Daly
>>>>
>>>>
>>>>> I think we need to provide an answer which *isn’t* straight
>>>>> JavaScript, and that can be declarative.
>>>>>
>>>>> John
>>>>> ------------------------------------------------------------------------------
>>>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>>>> Performance
>>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just
>>>>> $35/Month
>>>>> Monitor end-to-end web transactions and take corrective actions
>>>>> now
>>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>>> _______________________________________________
>>>>> X3dom-users mailing list
>>>>> X3dom-users at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>>>
>>>> --
>>>> *Leonard Daly*
>>>> 3D Systems & Cloud Consultant
>>>> X3D Co-Chair on Sabbatical
>>>> LA ACM SIGGRAPH Chair
>>>> President, Daly Realism - /Creating the Future/
>>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>> ------------------------------------------------------------------------------
>>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>>> Performance
>>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>>> Monitor end-to-end web transactions and take corrective actions
>>>> now
>>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>> _______________________________________________
>>>> X3dom-users mailing list
>>>> X3dom-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Site24x7 APM Insight: Get Deep Visibility into Application
>>> Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions
>>> now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>>> _______________________________________________
>>> X3dom-users mailing list
>>> X3dom-users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>
>>
>> --
>> *Leonard Daly*
>> X3D Co-Chair
>> Cloud Consultant
>> President, Daly Realism - /Creating the Future/
>>
>
More information about the x3d-public
mailing list