[x3d-public] ] V4.0 Opendiscussion/workshopon X3DHTMLintegration

[Philipp Slusallek]

[Resent, as the original email was apparently not relayed through the list]

Hi Joe, all,

Thanks for looking into this. I am not sure I understand all aspects of
your post.

Again, the goal of this example was not to provide a nicely editable
format (Hanim would much be better for that!) but to have a direct
mapping from the data of the game to a nicely animatable asset to be
used in XML3D (without knowing the internals of the implementation).
This is a very important goal, I believe.

Layering a WebComponent on top of our core engine, which reformats the
input data (e.g. Hanim) is the main topic of the paper I sent and should
not be too difficult once this is all working nicely (still work in
progress right now). We hope to show a nice prototype at Web3D if things
work out well.

Eventually this would allow you or anyone else to simply create their
own high-level elements in a modular way using WebComponents and publish
that for others to use. I am sure large parts of X3D should fit this
model quite nicely.

It would be great if others want to join and help with this.


Best,

	Philipp



Am 15.06.2016 um 09:57 schrieb Joe D Williams:
>> here in string format. If you look into it
> you find all the index buffers for the different parts of the body,
> positions, normals, texcoords, the bone indices and weights (which bones
> influence each vertex and with what weight), bone parents (describe the
> bone hierarchy used for flattening), and bindTranslation and
> bindRotation (which define the bind pose). After that you find the
> different animations again specified as separate translation and
> rotation applied to the bones (defined above). The latter are arrays of
> arrays indexed by the "key" value, which is the time index for the
> respective animation keyframe. We could have several of those animation
> elements here for many different animation to select from.
> 
> That is all first rate I am sure (not sure I care about flattening) and
> the data categories look like what I have seen and can expect to need. I
> know I need arrays of arrays, always.
> 
> X3D HAnim builds the human skeleton hierarchy using Joints and Segments
> and end-effectors. The names may be different but it looks like there is
> equivalent functionality to do my example (hanim level 2, LOA3 humanoid
> skeleton with segment geometry and/or deformable skin bound to Joint(s)).
> 
> HAnim Segment geometry along with child joints and segments are animated
> direcly as a parent Joint is rotated. Skin geometry is bound to Joint(s)
> and animated by weighted Joint(s) rotation. Maybe due to skeleton
> hierarchy, hanim don't typically set independent joint translation or
> segment orientation for usual animations. Usually the only Joint that
> gets translation is the root.
> 
> So, maybe I can look into this some more.
> 
> https://github.com/xml3d/xml3d-examples/blob/master/examples/xflowSkin/asset/heavy.xml
> 
> 
> shaders,
> master mesh base,
> meshes used here,
> animations.
> 
> https://raw.githubusercontent.com/xml3d/xml3d-examples/master/examples/xflowSkin/asset/heavy.json
> 
> 
> meshes used here
> animation keyframes used here
> 
> index_hvyweapon_red
>  int index of mesh
> index_eyeball_r
>  int index of mesh
> index_eyeball_l
>  int index of mesh
> position
>  float3 location of point
> normal
> float3 of mesh
> texcoord
> float2 of texture
> boneIdx
>  ? int4 ( )
> boneWeight
>  ? float4  (rotation of joint)
> boneParent
>   int  (parent joint of segment)  116
> bindTranslation
>  float3 ( )
> bindRotation
>   float4 116 quat (parent joint of segment)
> taunt05h_translation
>   float3 116 (location of root joint?)
> value and key 128 keys 0-5.29167 x  0.0416667
> taunt05h_rotation
>   float4 quat (of target joint?)
> value and key 128 keys 0- 5.29167  x 0.0416667
> 
> Animation
> animations used here
> data id="anim_taunt05h" src="heavy.json"
> not found here
> 
> OK, Thank You All. Now I think I know 116 is an important number in this
> and am ready to look at the anim_taunt05h animation things that make the
> heavy.json data produce stuff that is live and operating. Yes, I might
> have heard from this list that json for scripts is under development, so
> I'm really not to surprized to find it in missing in this heavy.json
> file. Can you please send me a link to some readable?
> 
> So, I think my x3d example basically probably contains the same sorts of
> data required or can be derived, for instance axis-angle instead of
> quaternions (0 0 1 0 = 0 0 0 1) and other that I don't quite get yet,
> like why 2 interpolator value-key sets and 116 bindRotation values?
> 
> If you have in idea for an automated way for me to load my x3d hanim
> example data into this style of coding, please tell me. I'm not worried
> that there is no mention of 'joint' in any of the above data names. It
> took change for many toolmakers to expose the concept of a joint as the
> basic hierarchal object structure and exposed joints as actuators of the
> skeleton. .
> 
> Thanks Again,
> All Best,
> Joe
> 
> 
> 
> 
> ----- Original Message ----- From: "Philipp Slusallek"
> <philipp.slusallek at dfki.de>
> To: "Joe D Williams" <joedwil at earthlink.net>; "'X3D Graphics public
> mailing list'" <x3d-public at web3d.org>
> Sent: Monday, June 13, 2016 10:26 PM
> Subject: Re: [x3d-public] ] V4.0 Opendiscussion/workshopon
> X3DHTMLintegration
> 
> 
>> Hi Joe,
>>
>> I would appreciate if you would not assume the worst from others. No, we
>> are NOT cheating and all the data is actually there right in front of
>> you for you to see and check, even without my help. The paper (which I
>> did link multiple times in my emails) would have told you how to
>> interpret the data, which is all in the main HTML5/XML3D web page or
>> files that are linked from it. Just follow the URLs. It just looks a bit
>> different than you are used to.
>>
>> So, for your convenience here are all the bits and pieces:
>>
>> -- The data is actually exported in json format from the game. XML3D can
>> directly import JSON and make this data available as generic <data>
>> elements for Xflow. BTW, we also have format handlers for a number of
>> other geometry formats that you can directly refer to simply with a URL.
>> The result is not a mesh but simply a <data> element.
>>
>> You see this json import at the very end of the XML3D file for the heavy
>> character
>> (https://github.com/xml3d/xml3d-examples/blob/master/examples/xflowSkin/asset/heavy.xml).
>>
>>
>> -- If you look at the json file (large,
>> https://github.com/xml3d/xml3d-examples/blob/master/examples/xflowSkin/asset/heavy.json)
>>
>> you see all the raw data , here in string format. If you look into it
>> you find all the index buffers for the different parts of the body,
>> positions, normals, texcoords, the bone indices and weights (which bones
>> influence each vertex and with what weight), bone parents (describe the
>> bone hierarchy used for flattening), and bindTranslation and
>> bindRotation (which define the bind pose). After that you find the
>> different animations again specified as separate translation and
>> rotation applied to the bones (defined above). The latter are arrays of
>> arrays indexed by the "key" value, which is the time index for the
>> respective animation keyframe. We could have several of those animation
>> elements here for many different animation to select from.
>>
>> -- Back in the heavy.xml file we do a few tricks to better handle the
>> data: You see the 'filter="keep({translation: XX_translation, ...}"'
>> part. This simply creates a new data element with selected and renamed
>> entries. No data duplication is happening here, its just references and
>> so very efficient. We do this so that the generic Xflow scripts are
>> referencing the right data (by name). The same for the index elements
>> and the main data element for the character ("meshbase"). We also define
>> the materials here. All the data exists exactly once.
>>
>> -- In the main html file
>> (https://github.com/xml3d/xml3d-examples/blob/master/examples/xflowSkin/xflow-skin.html/)
>>
>> we then simply import the data while applying the skinning operator
>> (discussed in a previous email) and then instantiate the different body
>> parts with their materials. Again, we could further put this into an
>> XML3D Asset (see spec I referenced in an earlier email), if you want to
>> use the characters in an even simpler way as an entire asset with a
>> single line. Note, that even in this case you still have full control
>> over the animation and other aspects of the character within an asset.
>>
>> So you see: No tricks here, all good skeletal animation with skinning as
>> exported directly from the game character. Or "Level1" as you call it.
>>
>> And yes all of this is directly animatable from standard HTML5 (JS
>> scripts, events, CSS attributes, even from well-known CSS transitions,
>> etc.). It just all works as an extension to HTML5. Just a bit
>> differently organized as "required" by Hanim. But we can use it just the
>> same way.
>>
>> -- The whole animation is controlled by setting the "key" value in the
>> character in the main file ("heavySkinned"). Again I explained in my
>> previous email.
>>
>> -- And again, this might not be the alternative to the Hanim format, and
>> it does not try to be. Its just the way skeletal animation is specified
>> in the game the character comes from. The point is we can simply use the
>> data "as is" without having to convert it to some "standard" format.
>>
>> -- But in just the same way we can create a Xflow graph that uses the
>> data from an Hanim character spec. This what I call "generic data
>> handling and processing". Again, most of the processing can be mapped to
>> the GPU without anyone having to write any specific code for skinning or
>> so. All without any "native" code to write. Its handled in Xflow where
>> possible and needed. We are further improving the automatic GPU mapping
>> to be even more flexible, as we speak.
>>
>> -- BTW, Besides the string format (in the json file), we also offer the
>> BLAST format for very efficient binary data streaming. It is essentially
>> a json header with intelligently arranged binary blobs, organized for
>> streaming. You find the paper here:
>> https://graphics.cg.uni-saarland.de/2014/blast-a-binary-large-structured-transmission-format-for-the-web/
>>
>>
>>
>> Best,
>>
>> Philipp
>>
>> Am 14.06.2016 um 04:03 schrieb Joe D Williams:
>>>
>>>
>>>> Hi Joe,
>>>>
>>>> I thought we could have meaningful discussion about the different
>>>> approaches, which could help all of us to come up with a better
>>>> understanding and finally a better architecture.
>>>
>>> Great, the architecture I am interested in the the architecture of the
>>> Humanoid. It consist of various types of data. If we are talking about
>>> the same thing, that is skeletal animation using segment geometry and
>>> skin, then we should be able to talk about user code for skeletons and
>>> skin and animations.
>>>
>>> When we use skeletal animation to animate skin, then we assume the
>>> author wants to document the mesh to actuator bindings. If you don't
>>> need this data for a style of animation you are using then that is fine
>>> and please tell me how you are doing it. If you do support this style of
>>> joint-driven animation then where does the author put that mesh binding
>>> information.
>>>
>>> Maybe I am being difficult, but from what you have shown me i said
>>> before and you did not refute, I still am guessing that you may be
>>> animating what I call a Level 2 export from some authoring tool. Level 2
>>> is when the data for the skeleton and animation system is not there and
>>> the export is just flattest possible geometries for each frame. Then you
>>> just cycle through the geometry frames like it was really animated. If
>>> that is true, then x3d deals with that just fine in a very systematic
>>> way of just swapping all geometry each frame. But that is not the topic
>>> of hanim because h-anim deals primarily with skeletal animation
>>> progressing frame to frame. What I call Level 1 export gives you all
>>> geometry, data, and event system needed to create the animated scene.
>>> Level 3 export is a video where all scenegraph information is lost.
>>>
>>> Well, as I am asking, where is the skeleton and where is the mesh and
>>> the bindings.
>>> How can I take conrol of the animations?
>>>
>>>> But it seems you do not really care what others have to say.
>>>
>>> Maybe I have ignored something you have written. All fine stuffs but the
>>> topic I want to chase is what are your recommended style of user code
>>> for the process of skeletal animations. If you do enough of it and want
>>> to reuse some of it I'm sure you will have some preferences for names
>>> and structures for getting data into the user code. Admittedly X3D HAnim
>>> has a very narrow scope in this area but the elements in that scope are
>>> essential for basic operation of the humanoid.
>>>
>>> Of course this basic humanoid could be composed and operated without
>>> giving special names to parts of it and there may be other ways of
>>> moving skin around, maybe even without a skeleton - that's the way they
>>> used to do it. But just please tell me how I use your tool to get basic
>>> results.
>>>
>>>> Most of your questions would
>>>> already be answered by a simple look into our papers.
>>>
>>> I guess you have no questions or comments about the 'standard' hanim
>>> character I sent.
>>> The main reason you might read it is just to see how hanim documents the
>>> structures and parameters.
>>>
>>> I did actually look and read the example you referenced. Sorry that all
>>> I am asking is not answered on that one page of user code. I am sure
>>> there are pages of code behind that page but I could not find working
>>> links. How about just these questions below? I am just asking for some
>>> simple guidance. The page you showed did not contain these details, at
>>> least in a form that I could recognize and understand.
>>>
>>>>>
>>>>> skeleton hierarchy
>>>
>>> can you please show me the parts that define the parent-child
>>> relationships of the various parts of the skeleton. Since I want to deal
>>> with aspects of skeletal animation then I want to know how to target
>>> specific joints or whatever is used in your system to connect with other
>>> structures. If your process uses a skeleton hierarchy (some don't) then
>>> I should be able define my skeleton in the style of your user code.
>>>
>>>>> joint center locations
>>>
>>> these are important parameters of the model. Again, I think I need to
>>> position the joints in 3D space in order to drive the segment or skin
>>> geometry.
>>>
>>>>> before animation pose
>>>
>>> what is the default skeleton pose prior to animation.
>>> My existing animations may depend upon a certain starting pose
>>>
>>>>> before animation joint rotations
>>>
>>> another important parameter for sharing skeletons and animations
>>>
>>>>> segment geometries
>>>>> skin geometry
>>>
>>> Where is the mesh defined in the user code? Not on that page you
>>> showed me,
>>>
>>>>> skin vertex to joint bindings
>>>
>>> I think this is a vital block of data. I must know which joints affect
>>> which points of the skin.
>>> Show me the mesh and binding to animated elements. I am not interested
>>> really in the techniques of the runtime, just how the humanoid skeleton
>>> and skin is documented.
>>>
>>> The purpose of X3D is not the style of runtime since many styles are
>>> possible,
>>> The purpose of X3D is reliable documentation for transport.
>>>
>>>>
>>>> I am more than happy to answer meaningful questions but why should I
>>>> repeat the paper's content here just because you do not care to read
>>>> it?
>>>
>>> How about because you a polite guy with a mission and want to help even
>>> though I am having problems?
>>> Did you send me a link for the paper?
>>> "Cam you Please show me the mesh?" is not a meaningless question? It may
>>> be lazy for me not looking harder but the question is not meaningless.
>>>
>>> Why should I have to read the paper (which I probably have seen at some
>>> point but don't recall coverage of hanim specifically mentioned) for you
>>> to tell me where in the user code for your hanim example do you stash
>>> skeleton joint hierachy and the skin bindings?
>>>
>>> I shoudn't talk like this but this is like the old days when character
>>> rigging and all the various tricks were used to hide and obscure code
>>> because no one wanted to give away their rigging and skinning secrets.
>>> Maybe that is what is happening here where this basic stuff is really
>>> not for the eyes of a casual reader that might stand at least some
>>> chamce of understanding the thing.
>>>
>>> The hanim character I showed is nothing so great, all hand-done with a
>>> text editor but it works by the spec, the skeleton is orderly, the mesh
>>> is obvious, and the animation is straightforward. It should not be too
>>> difficult to make it work in your system. But I gotta know where the
>>> data goes before I try it. So please guide me through the places where
>>> the data that is needed would be placed.
>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>> Philipp
>>>
>>> Thanks Philipp. I am somewhat limited in what I can do but if you have
>>> anything, even a rough template style for skeletal animation projects, I
>>> would like to try it.
>>>
>>> All Best,
>>> Joe
>>>
>>>
>>>>
>>>> Am 13.06.2016 um 18:10 schrieb Joe D Williams:
>>>>>>> ... this generic data design also allows  ... the specialized
>>>>>>> approach that X3D is based on
>>>>>
>>>>> That is what I hope to hear anyway. X3D does use a generically
>>>>> specialized approach because it is aimed at a specific application. So
>>>>> here are some categories of data required to create the humanoid and
>>>>> animations.
>>>>>
>>>>> skeleton hierarchy
>>>>> joint center locations
>>>>> segment lengths
>>>>> before animation pose
>>>>> before animation joint rotations
>>>>> segment geometries
>>>>> skin geometry
>>>>> skin vertex to joint bindings
>>>>>
>>>>> So, the x3d hanim data design is pure 3D database. Easy to build from
>>>>> a spreadsheet. For the skeleton, there is a base joint, then segments
>>>>> connect to other joints in a system of parent-child so the thing moves
>>>>> as expected by rotations applied to joints. The only reason I can
>>>>> think of why they called the bones segments instead of bones is
>>>>> because this type of chained animations using
>>>>> anchorjoint-segment-joint-segment-(etc.)-endeffector structures is
>>>>> very common over many fields as well as humanoid simulation. Also this
>>>>> 3D structure gives some handles to attach physics elements.
>>>>>
>>>>> In x3d, the segment geometries are children of the segment so when the
>>>>> segment moves because the joint is rotated, then the geometry moves.
>>>>> So, in the x3d data model the animated geometry is defined in the
>>>>> children user code of the segment it represents, This should be fairly
>>>>> standard way of including geometry for the character.
>>>>>
>>>>> In x3d the segment lengths are not given directly, instead it is a
>>>>> computed distance between parent and child joints (or parent joint and
>>>>> end effector).
>>>>>
>>>>> In x3d the before animation skeleton pose is sort of a relaxed
>>>>> attention pose, with all joints at the default rotation, facing +z,
>>>>> with +y up, with 0 0 0 at the standing surface between the feet. This
>>>>> is the animation binding pose which may be different than the skin
>>>>> binding pose.
>>>>>
>>>>> The base joint for the skeleton is about crotch level, maybe center of
>>>>> gravity standing, Then the x y z of joint centers are also set
>>>>> relative to 0 0 0. The hanim example typical skeleton dimensions are
>>>>> from a large sample and include a collection of surface features, such
>>>>> as an xyz location for the top of the head. So the complete important
>>>>> dimensions of the skeleton are stored as an attribute of each Joint
>>>>> node. There may be other ways to do this but this seems convenient and
>>>>> is basically what all authoring tools do.
>>>>>
>>>>> If the animation includes a deformable mesh, then each vertex of the
>>>>> skin geometry needs to be hooked up with one or more joint nodes that
>>>>> are responsible for controlling displacment of each skin vertex as the
>>>>> skeleton joints are rotated. The skin geometry is defined as a child
>>>>> of the humanoid so all moves when the base joint moves and each
>>>>> individual vertex of the skin moves according to rotation of
>>>>> associated joint(s). So the skin is defined as a single mesh that may
>>>>> be composed from individual geometries.
>>>>>
>>>>> The binding of each vertex to one or more joints is given in each
>>>>> Joint node by listing the number of the vertex in its order of
>>>>> appearance in the skin geomery definition, along with a weight that
>>>>> allows computation of the radial displacement to move the vertex as
>>>>> the associated joint(s)are rotated. So, the individual joint nodes
>>>>> hold skin binding and weight data, I guess there could be other ways
>>>>> of cooding this, like frestanding list of each vertex and its
>>>>> controlling joints but that path was not chosen.
>>>>>
>>>>> Seem complex? Well how else can it be done? You must know complete
>>>>> details about the skeleton and skin or else, no luck or turn it over
>>>>> to a black box. If you use this sort of technology, then this is what
>>>>> it takes to document the techniques.
>>>>>
>>>>> In x3d standard, the animation is given by listing the controls, such
>>>>> as touch and time sensors. For each joint to be animated an
>>>>> orientation interpolator or script along with a list of routes that
>>>>> describe the flow of time to each interpolator and the result from
>>>>> each interpolator to the Joint it controls.  completes the animation
>>>>> event system,
>>>>>
>>>>> So that is my version of how the hanim character 'rigging; and
>>>>> animation data is presented as user code. Especially in hanim there
>>>>> really aren't many abstractions. It is very concrete because the model
>>>>> wants to be as complete and realistic as possible.
>>>>>
>>>>> again > Hanim has
>>>>>> selected one specific way of describing and handling animation and
>>>>>> skinning, which requires a node-specific implementation.
>>>>>
>>>>> No, you just have to recognize the node and know what to do with the
>>>>> data.
>>>>> Animation is usually keyframe interpolation, meaning a set of data
>>>>> that includes a list of times and a list of what the data should be at
>>>>> that time. The idea is that if you need to create the scene at some
>>>>> point between the keytimes, then linear interpolation berween adjacent
>>>>> key data can be computed. This is the way all does realtime. There can
>>>>> be some differences that simpify if you just wanna make a video. But
>>>>> again, if you need interplators, there are not many easier or more
>>>>> straightforward deflcative way to define user code for a keyframe
>>>>> interpolator.
>>>>>
>>>>> As for skinning, maybe you would rather have a separate container that
>>>>> just lists each vertex and and the elements that control it. What is a
>>>>> better way to document this connection than the way it is done in x3d
>>>>> hanim?
>>>>>
>>>>> And yes, skeleton has at its core a node specific implementation that
>>>>> contains the hierarchy of joints. It is important to define the
>>>>> hieratchy in the user code so it can be verified against a 'standard'
>>>>> hierarchy which is part of figuring out whether the character can do
>>>>> 'standard' animations, for example.
>>>>>
>>>>> So it is just a matter of names of functionality and the data for that
>>>>> functionality. And the not small matter of putting that functionality
>>>>> in a structure and syntax so that the data can be easily read,
>>>>> analyzed, and maybe extracted in a 'standard' form and used according
>>>>> to processing styles of the supporting 3D application. HAnim made a
>>>>> giant step forward when back in the day they decided to put the
>>>>> complete skeleton model and all the data to run the thing directly and
>>>>> unambigiously in the user code. This made the model concrete and
>>>>> verifiable as well as personal. Before that all they could do was
>>>>> submit lists of elements and data to the big hanim simulator in the
>>>>> sky and it would would send back results.
>>>>>
>>>>> Some built-in convenience nodes are certainly needed at some point. Is
>>>>> here a simple way to define keyframe interpolation or do I start with
>>>>> a script template that depends upon dom events?
>>>>>
>>>>> Thanks and Best,
>>>>> Joe
>>>>>
>>>>>
>>>>> ----- Original Message ----- From: "Joe D Williams"
>>>>> <joedwil at earthlink.net>
>>>>> To: "doug sanden" <highaspirations at hotmail.com>; "'X3D Graphics public
>>>>> mailing list'" <x3d-public at web3d.org>; "Philipp Slusallek"
>>>>> <philipp.slusallek at dfki.de>
>>>>> Sent: Sunday, June 12, 2016 3:59 PM
>>>>> Subject: Re: [x3d-public] ] V4.0 Opendiscussion/workshopon
>>>>> X3DHTMLintegration
>>>>>
>>>>>
>>>>> Hi, Philipp,
>>>>>
>>>>>> https://xml3d.github.io/xml3d-examples/examples/xflowSkin/xflow-skin.html
>>>>>>
>>>>>>
>>>>>> for
>>>>>> simple skinned and animated characters
>>>>>
>>>>> I don't see it. There are things jumping around, but from code think
>>>>> not skeletons with skin but just geometries dragged from frame to
>>>>> frame. Maybe the code is in the protos? Looks like it could be
>>>>> generated by something that used skeletal animation but just exported
>>>>> geometry for some keyframes. Anyway, I can't find the desired
>>>>> interfaces, like how is the skeleton composed, how is the skin bound,
>>>>> how do I control the animations, do my personal animations stand a
>>>>> chance of working in those rigs? All the questions I consider basic
>>>>> are not there or very far down in the reading. So show me the code for
>>>>> a skeleton, please,
>>>>>
>>>>> From the spec, It is important that the skeleton be well defined in
>>>>> terms of names, locations, and interfaces. To me, the great thing
>>>>> about the x3d representation is clarity about the naming and location
>>>>> of features, and even an initial pose so that animations can be easily
>>>>> transported between characters.
>>>>>
>>>>>> Hanim has
>>>>>> selected one specific way of describing and handling animation and
>>>>>> skinning, which requires a node-specific implementation.
>>>>>
>>>>> Right, hanim documented the best practices for handling skeleton, and
>>>>> animation, and skinning, I mean for years x3d does it the same way
>>>>> because these are the parameters for the way that everybody does it.
>>>>>
>>>>> So, it started long ago with the idea that researchers needed a
>>>>> standardized skeleton that would serve for producing a computable
>>>>> replacement for a mechanical armature in humanoid simulations. With
>>>>> medical and robotic folks also involved, they decided to pick a
>>>>> realistic representation that was widely accepted. The hanim and X3D
>>>>> standards use as the example a 'standard' humanoid with 'typical'
>>>>> dimensions in a realistic humanoid hierarchy, This was easy for VRML
>>>>> and X3D with a Humanoid container holding skeleton and skin and some
>>>>> other stuffs.
>>>>>
>>>>> Skeleton is realistic hierarchy of Joints, Segments, and Sites.
>>>>> Defining the default initial pose was not easy but finally, the choice
>>>>> was probably an artifact of the method used to obtain the greatast
>>>>> share of samples to define typical joint and surface feature
>>>>> locations. Anyway, some of the names have changed (segment instead of
>>>>> bone) and some under the covers stuffs exposed, but basically x3d
>>>>> hanim is indusry-standard best practices for complete documentation of
>>>>> a realtime animated character.
>>>>>
>>>>> Later this has evolved for skeleton structures to serve as the basic
>>>>> model for motion capture data and as the corresponding structure for
>>>>> the mocap playback model.
>>>>>
>>>>> I mean, this hanim has been the world standard for transportablity of
>>>>> basic structures and basic functionality. Wouldn't you expect to get
>>>>> something that represents the core factors for what most all realtime
>>>>> character animation tools would give you when you start with any
>>>>> default (fantasitc that there are now so many) humanoid or biped or
>>>>> something of that category? Of course, and that is true. See X3D HAnim
>>>>> LOA2. Some names are changed, but that is the generic skeleton.
>>>>>
>>>>> The names may be changed or some hidden interfaces exposed, but if you
>>>>> look close you will see that x3d hanim does indeed represent complete
>>>>> documentation required to build and animate the character. That can be
>>>>> important when you wish to carry your work from one commercial or open
>>>>> product to another. I mean you used to have to beg for binding and
>>>>> animation curves. At some authoring levels sometimes you can't even
>>>>> see that stuff.
>>>>>
>>>>> Whatever the authoring system internal data forms, if they rig skin,
>>>>> then there may or may not be a human readable and kestroke editable
>>>>> listing of the skin vertex bindings and weights. X3D just says that
>>>>> this very basic stuff has to be in the flie in a logical place and
>>>>> reasonable form. Any authoring system worthy of your trust should be
>>>>> able to give you that list just in case you wanted to work with
>>>>> another tool and use your old rigging. Why is it so carefully defined
>>>>> in x3d hanim? Because that is the best way to preserve that type of
>>>>> data since basically, everybody has to do it that way down at the
>>>>> metal, to move the points ro positions that depend upon what time
>>>>> appears in the next frame.
>>>>>
>>>>> That's just way it is. The basic data in close to executable form
>>>>> readable and editable is what x3d hanim requires. Since it is so
>>>>> basic, data should be able to be exchanged between most any set of
>>>>> authoring tools and it is. Of course there might be some new
>>>>> technique(s) because the things advance, but those techniques either
>>>>> remain proprietary of have not yet made it into the public open source
>>>>> community so would ot appear in X3D.
>>>>>
>>>>> No outright challenge here but look at what you get when you start
>>>>> with the default humanoid in any authoring system. Some might hook up
>>>>> the joints slightly differently with other names or use some other
>>>>> space than 'standard' hanim humanoid space but the basic goal is
>>>>> realism, Hey, I think best results when everything is drawn in
>>>>> 'standard' human space, dimensioned for your preferences. Like the
>>>>> hanim end-effector surface features are there because experimeters
>>>>> wanted to be able to define an actual location in human space relative
>>>>> to the skeleton. That was where the virtual doctor could touch the
>>>>> virtual surgical tool. Anyway, by the time the standard was set, it
>>>>> was pretty much decided that real machines would use quats to anmate
>>>>> but X3D stayed with axis-angle as the minimum requirement for
>>>>> transporting realtime animations (realtime always needs interpolators
>>>>> and all inbetweens, so sorry euler angles).
>>>>>
>>>>> A Transform extended to a Joint adds some technical features and the
>>>>> hierarchal structure of Joint, connecting Segment, and Site(s) for
>>>>> surface and internal features are all standard vrml/x3d. Using the
>>>>> names Humanoid. Joint, Segment, and Site as names for the major
>>>>> functionalities of the basic humanoid with geometries bound to
>>>>> segments is accomplished by extending Transform using simple
>>>>> prototypes. To do the skin needs some pretty standard gem script to
>>>>> move the skin points as the skeleton is animated .
>>>>>
>>>>> I mean that all the information about mesh and binding and what is
>>>>> supposed to happen when it is supposed to happen is very nicely
>>>>> composed. Of course x3d hanim is always interested in new names and
>>>>> locations and styles or techniques that are missing from anywhere in
>>>>> x3d, but basically it is all there. This reflects the data that is
>>>>> actually used to create the character and realtime animations in
>>>>> human-readable form. And it matches up with detailed vizualization
>>>>> technolofies like medical and cad and physics and is completely
>>>>> collada friendly.
>>>>>
>>>>> As I said, the example I am interested in exploring is relatively
>>>>> simple and from what I have seen (with conversion from axis-angle to
>>>>> unitquats) can probably be represented lossless in glTF.
>>>>>
>>>>>> But this generic data design also allows for creating these
>>>>>> abstractions that would be much harder (if not impossible) to do
>>>>>> with
>>>>>> the specialized approach that X3D is based on.
>>>>>
>>>>> X3D is a generic data design because it defines generic forms of data
>>>>> needed to make and animate a common character. The data is indeed
>>>>> generic and no character animation that can produce animated
>>>>> characters is missing any of this data. Absent proprietary technology
>>>>> they all use a skeleton and they all have geometry bound to connecting
>>>>> things, and they all use the same skin bindings.
>>>>>
>>>>> What is specialized? The names and hierarchy? Well the names are
>>>>> probably specialized but the hierarchy and bindings are not. If i read
>>>>> the above right, then _if_ the generic data design has hard times with
>>>>> the x3d approach of containing the data then the generic data design
>>>>> has big problems. I don't think that is what you said, but what part
>>>>> of the x3d data design is harder? Overall, the hanim is a very generic
>>>>> data design using very generic 3D hierarchies. Hanim is not at all an
>>>>> unusual or non-generic scenegraph structure or data structure so I
>>>>> don't understand the problem.
>>>>>
>>>>> Besides, please look at some browsers that do a great job with x3d
>>>>> hanim. There were several more before they went missing.
>>>>>
>>>>> http://www.hypermultimedia.com/x3d/hanim/JoeH-AnimKick1a.txt
>>>>>
>>>>> is the text version of the example I am most interested in, in classic
>>>>> encoding because I thinki is easier to read. Don't use word wrap.
>>>>>
>>>>> In reality, I don't care how the data is stored for runtime execution,
>>>>> I care about the readability of the documentation created at
>>>>> authortime. Sure, X3D HAnim may take a while to learn to read because
>>>>> the structure is complicated, but all time is not wasted because these
>>>>> are types of data common to most all efforts of humanoid animation.
>>>>>
>>>>> One piece of automation also used in character animation is precise,
>>>>> time-driven animation of parts of a geometry, like when a piece of
>>>>> skin to move independently of any joint rotations, In HAnim this is
>>>>> done by Displacer, You tell it which points to move and how much to
>>>>> move them then send it a weight, This is an important little tool.
>>>>> Again, the data and technique just represents a common way to do it.
>>>>> How would your project define such as operation?
>>>>>
>>>>> Thanks and Best,
>>>>> Joe
>>>>>
>>>>>
>>>>> ----- Original Message ----- From: "Philipp Slusallek"
>>>>> <philipp.slusallek at dfki.de>
>>>>> To: "Joe D Williams" <joedwil at earthlink.net>; "doug sanden"
>>>>> <highaspirations at hotmail.com>; "'X3D Graphics public mailing list'"
>>>>> <x3d-public at web3d.org>
>>>>> Sent: Sunday, June 12, 2016 12:21 AM
>>>>> Subject: Re: [x3d-public]] V4.0 Opendiscussion/workshopon X3DHTML
>>>>> integration
>>>>>
>>>>>
>>>>>> Hi Joe,
>>>>>>
>>>>>> I believe it may even be illuminating to just read a paper to
>>>>>> understand
>>>>>> the principles of other technologies and consider them for your own
>>>>>> design. Also, some more openness to other available technology
>>>>>> besides
>>>>>> X3D would actually help the discussion here.
>>>>>>
>>>>>> But we actually do have an implementation as well, which is used in
>>>>>> many
>>>>>> of our projects: See for example
>>>>>> https://xml3d.github.io/xml3d-examples/examples/xflowSkin/xflow-skin.html
>>>>>>
>>>>>>
>>>>>> for
>>>>>> simple skinned and animated characters that are handled using Xflow
>>>>>> to
>>>>>> describe the required processing on the triangle meshes. These are
>>>>>> animated characters exported to XML3D/Xflow directly from a
>>>>>> well-known game.
>>>>>>
>>>>>> This is just one of many ways of how Xflow can be used. Really, the
>>>>>> main
>>>>>> point of Xflow is the ability to describe very different processing
>>>>>> operations on various data sets in a scene in a declarative way.
>>>>>> There
>>>>>> are also examples for image processing (e.g.
>>>>>> https://xml3d.github.io/xml3d-examples/examples/xflowIP/histogramm.html),
>>>>>>
>>>>>>
>>>>>> simple
>>>>>> Augmented Reality
>>>>>> (https://xml3d.github.io/xml3d-examples/examples/xflowAR/ar_flying_teapot.html),
>>>>>>
>>>>>>
>>>>>>
>>>>>> and others using the exact same basic technique. Our ongoing work
>>>>>> will
>>>>>> make this even simpler and support different HW mappings better.
>>>>>>
>>>>>> This is made possible by the generic data model in XML3D that I have
>>>>>> alluded to several times in my email. It is already useful as nice
>>>>>> abstraction of GPU buffers but also allows for supporting
>>>>>> programmable
>>>>>> shading. But this generic data design also allows for creating these
>>>>>> abstractions that would be much harder (if not impossible) to do
>>>>>> with
>>>>>> the specialized approach that X3D is based on. However, it does work
>>>>>> the
>>>>>> other way round: You can map the specialized nodes of X3D to the
>>>>>> more
>>>>>> general and generic functionality of XML3D/Xflow.
>>>>>>
>>>>>> I think this highlights the difference between our approaches: Hanim
>>>>>> has
>>>>>> selected one specific way of describing and handling animation and
>>>>>> skinning, which requires a node-specific implementation. On the
>>>>>> other
>>>>>> hand, we provide a small core engine for any such processing and
>>>>>> expose
>>>>>> it in a compact and declarative way. The engine can then analyze and
>>>>>> optimize the resulting flow-graph, optimize it, and map it to the
>>>>>> available HW independent of what the specific computation and up
>>>>>> representing. On top of this, one can then use WebComponents to map
>>>>>> any
>>>>>> specific representation (such as Hanim) to this generic
>>>>>> representation.
>>>>>>
>>>>>> We also did a careful analysis and comparison to X3D/Hanim in our
>>>>>> papers
>>>>>> (see below for the links). There are several issues that we
>>>>>> identify:
>>>>>> Need to duplicate the geometry to apply different animations to the
>>>>>> same
>>>>>> model, or the fact that Hanim cannot handle tangent vectors as part
>>>>>> of
>>>>>> the model, which may be required if a model has anisotropic
>>>>>> materials
>>>>>> that need the transformed tangent vectors as vertex attributes for
>>>>>> the
>>>>>> shader. It is very straight forward to add such processing to an
>>>>>> Xflow
>>>>>> graph. There are more arguments in the paper.
>>>>>>
>>>>>> We also argue in the paper that Xflow is expressive enough to handle
>>>>>> Hanim. Doing a full WebComponent implementation for Hanim is left as
>>>>>> an
>>>>>> exercise for the reader :-). While certainly useful, we do not see
>>>>>> this
>>>>>> as the main target of our research work, sorry. But it should not be
>>>>>> a
>>>>>> difficult exercise.
>>>>>>
>>>>>> BTW, the relevant papers are here:
>>>>>> -- 
>>>>>> https://graphics.cg.uni-saarland.de/fileadmin/cguds/papers/2012/klein_web3d2012/xflow.pdf
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> https://graphics.cg.uni-saarland.de/fileadmin/cguds/papers/2013/klein_web3d2013/xflow-ar.pdf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> There is also a IEEE CG&A extended version of the first paper here:
>>>>>> --  https://www.computer.org/csdl/mags/cg/2013/05/mcg2013050038.pdf
>>>>>>
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Philipp
>>>>>>
>>>>>> Am 12.06.2016 um 05:52 schrieb Joe D Williams:
>>>>>>> Hi Philipp,
>>>>>>>
>>>>>>> I would study some of your work, but please help me esablish this
>>>>>>> confidence by showing me what you can do with some relatively
>>>>>>> complex
>>>>>>> X3D. This is skeleton animation of joints and segments as used
>>>>>>> everywhere (no matter which interfaces are actually exposed by the
>>>>>>> authoring system) and a deformable mesh skin bound to the skeleton
>>>>>>> and
>>>>>>> each skin vertex bound to one or more joint(s) nodes.
>>>>>>>
>>>>>>> http://www.web3d.org/documents/specifications/19774/V1.0/HAnim/ObjectInterfaces.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Skin animation is achieved by animating the joints in the
>>>>>>> skeleton's
>>>>>>> joint hierarachy then weighting each skin vertex displacement
>>>>>>> according
>>>>>>> to the bound joint(s) rotation (as used everywhere no matter which
>>>>>>> interfaces are actually exposed by the authoring system).
>>>>>>>
>>>>>>> some basics are here:
>>>>>>>
>>>>>>> https://en.wikipedia.org/wiki/Skeletal_animation
>>>>>>>
>>>>>>> is pretty much what X3D does either/both segment geometry (none on
>>>>>>> this
>>>>>>> model) or skin, like this one, and represents complete
>>>>>>> documentation of
>>>>>>> the model rigging and animations. Relative to the rest of the world
>>>>>>> of
>>>>>>> character authoring and animation X3D covers a lot of ground. The
>>>>>>> only
>>>>>>> 'probem' I know X3D has is that we do not use quaterions for joint
>>>>>>> animation, which is now more or less industry glTF standard instead
>>>>>>> of
>>>>>>> axis-angle used here. Well, also see that while the interpolators
>>>>>>> are
>>>>>>> linear, the keytimes may not always be constant intervals.
>>>>>>>
>>>>>>> A couple of X3D browsers will do this fine and BSContact free is my
>>>>>>> reference.
>>>>>>>
>>>>>>> This is a 'standard' LOA3 skeleton with skin vertices mostly taken
>>>>>>> from
>>>>>>> 'standard' surface feature points. Both skeleton and skin are drawn
>>>>>>> in
>>>>>>> approximately human scale, using the spec example dimensions as a
>>>>>>> basis.
>>>>>>> I use an IndexedFaceSet for the skin mesh and depend upon the
>>>>>>> 'standard'
>>>>>>> X3D browser feature of IFS to generate a default texure map so the
>>>>>>> texture stays bound to the skin as it moves.
>>>>>>>
>>>>>>> Anyway, I hope you can take a look at this because implementation
>>>>>>> of
>>>>>>> this basic character animation stuff is really not that easy and in
>>>>>>> the
>>>>>>> past we have seen X3D browser development stall at implementation
>>>>>>> of
>>>>>>> skeleton based skin animation. Note the hanim displacer node also
>>>>>>> does
>>>>>>> mesh deformation.
>>>>>>>
>>>>>>> Example is here:
>>>>>>>
>>>>>>> http://www.hypermultimedia.com/x3d/hanim/JoeH-AnimKick1a.x3dv
>>>>>>>
>>>>>>> and attached.
>>>>>>>
>>>>>>> I can get it in .x3d but this version has better documentation of
>>>>>>> the
>>>>>>> skin-joint bindings.
>>>>>>>
>>>>>>> Thanks and Best,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Philipp Slusallek"
>>>>>>> <philipp.slusallek at dfki.de>
>>>>>>> To: "Joe D Williams" <joedwil at earthlink.net>; "doug sanden"
>>>>>>> <highaspirations at hotmail.com>; "'X3D Graphics public mailing list'"
>>>>>>> <x3d-public at web3d.org>
>>>>>>> Sent: Saturday, June 11, 2016 3:17 AM
>>>>>>> Subject: Re: [x3d-public] [x3d] V4.0 Opendiscussion/workshopon
>>>>>>> X3DHTML
>>>>>>> integration
>>>>>>>
>>>>>>>
>>>>>>>> Hi Joe,
>>>>>>>>
>>>>>>>> Thanks for the good discussion.
>>>>>>>>
>>>>>>>> But may I humbly suggest that you read our Xflow papers. We have
>>>>>>>> looked
>>>>>>>> at this problem very carefully and tried different options with
>>>>>>>> Xflow as
>>>>>>>> the result of this. Xflow describes a generic data modeling and
>>>>>>>> processing framework as a direct extension to HTML. It is even
>>>>>>>> independent of XML3D conceptually. I would even call it the most
>>>>>>>> important parts of our system.
>>>>>>>>
>>>>>>>> Its data representation is very close to GPU buffers (by design)
>>>>>>>> and we
>>>>>>>> have shown that it can be mapped efficiently to very different
>>>>>>>> acceleration API (including plain JS, asm.js, ParallelJS, vertex
>>>>>>>> shaders, and others).The reason is that it is a pure functional
>>>>>>>> design
>>>>>>>> that is hard to do with X3D Routes for various reasons (discussed
>>>>>>>> in the
>>>>>>>> papers).
>>>>>>>>
>>>>>>>> Morphing, skinning, and image processing were actually the first
>>>>>>>> examples that we showed how to do with the system. Hanim can be
>>>>>>>> easily
>>>>>>>> mapped to Xflow (e.g. by a WebComponent), from where it can take
>>>>>>>> advantage of the generic HW acceleration without any further
>>>>>>>> coding. All
>>>>>>>> that is left on the JS side is a bit of bookkeeping, attribute
>>>>>>>> updates,
>>>>>>>> and the WebGL calls.
>>>>>>>>
>>>>>>>>
>>>>>>>> And with regard to the need of native implementations as raised by
>>>>>>>> you
>>>>>>>> earlier: On a plain PC we could do something like 40-50 (would
>>>>>>>> have to
>>>>>>>> check the exact number) fairly detailed animated characters, each
>>>>>>>> with
>>>>>>>> their own morphing and skinning in a single scene in pure JS, even
>>>>>>>> WITHOUT ANY ACCELERATION AT ALL, including rendering and all other
>>>>>>>> stuff. Yes, faster and more efficient is always better, but (i) we
>>>>>>>> should not do any premature optimizations unless we can show that
>>>>>>>> it
>>>>>>>> would actually make a big difference and (ii) this will not be
>>>>>>>> easy as
>>>>>>>> you should not underestimate the performance of JS with really
>>>>>>>> good JIT
>>>>>>>> compiler and well-formed code.
>>>>>>>>
>>>>>>>> Unless we have SHOWN that there is a real problem, that JS CANNOT
>>>>>>>> be
>>>>>>>> pushed further AND there is sufficient significant interest by a
>>>>>>>> large
>>>>>>>> user base, the browser vendors will not even talk to us about a
>>>>>>>> native
>>>>>>>> implementation. And maintaining a fork is really, really hard --
>>>>>>>> trust
>>>>>>>> me that is where we started :-(.
>>>>>>>>
>>>>>>>> And even more importantly, when we should ever get there we should
>>>>>>>> better have an implementation core that is as small as possible.
>>>>>>>> Many
>>>>>>>> node types each with its own implementation is not the right
>>>>>>>> design for
>>>>>>>> that (IMHO). Something like Xflow that many nodes and routes could
>>>>>>>> be
>>>>>>>> mapped to seems, a much more useful and maintainable option.
>>>>>>>>
>>>>>>>>
>>>>>>>> Right now we are extending shade.js in a project with Intel to
>>>>>>>> also
>>>>>>>> handle the Xflow processing algorithms to be more general, which
>>>>>>>> should
>>>>>>>> allow us to have a single code that targets all possible
>>>>>>>> acceleration
>>>>>>>> targets. Right now you still need separate implementations for
>>>>>>>> each
>>>>>>>> target.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Philipp
>>>>>>>>
>>>>>>>> Am 10.06.2016 um 19:26 schrieb Joe D Williams:
>>>>>>>>>> e6 html integration > route/event/timer
>>>>>>>>>
>>>>>>>>> These are details solved declaratively using .x3d using the
>>>>>>>>> abstractions
>>>>>>>>> of node event in and outs, timesensors, routes, interpolators,
>>>>>>>>> shaders,
>>>>>>>>> and Script directOuts...
>>>>>>>>>
>>>>>>>>> in the <x3d> ... </x3d> environment, everything hat is not
>>>>>>>>> 'built-in' is
>>>>>>>>> created programatically using 'built-in' event emitters, event
>>>>>>>>> listeners, event processors, time devices, scripts, etc.
>>>>>>>>>
>>>>>>>>> So the big difference in event systems might be that in .html the
>>>>>>>>> time
>>>>>>>>> answers what time was it in the world when you last checked the
>>>>>>>>> time,
>>>>>>>>> while in ,x3d it is the time to use in creation of the next
>>>>>>>>> frame. So
>>>>>>>>> this declarative vs programatic just sets a low limit on how much
>>>>>>>>> animation automation ought to be included. Both .x3d and <x3d>
>>>>>>>>> ,,,
>>>>>>>>> </x3d> should preserve the basic event graph declarations.
>>>>>>>>>
>>>>>>>>> This brings up where to stash these organizable lists of routes
>>>>>>>>> and
>>>>>>>>> interpolators.
>>>>>>>>> The user code of .html is not really designed for these detailed
>>>>>>>>> constructions and its basic premise is that the document should
>>>>>>>>> contain
>>>>>>>>> content, not massses of markup. So, are timers and interpolators
>>>>>>>>> and
>>>>>>>>> routes as used in .x3d content or markup? If they are markup,
>>>>>>>>> then it is
>>>>>>>>> clear they should be in style. Besides, in my trusty text editor
>>>>>>>>> this
>>>>>>>>> gives me a easily read independent event graph to play with.
>>>>>>>>>
>>>>>>>>> Next, if I need to step outside the 'built-in' convenience
>>>>>>>>> abstractions,
>>>>>>>>> or simply to communicate with other players in the DOM which
>>>>>>>>> happens to
>>>>>>>>> be the current embeddiment of my <x3d> ,,, </x3d> then I need DOM
>>>>>>>>> event
>>>>>>>>> stuffs and probably a DOM script to deal with DOM events set on
>>>>>>>>> x3d
>>>>>>>>> syntax.
>>>>>>>>>
>>>>>>>>> So, to me this is the first step: Decide how much of the
>>>>>>>>> automation is
>>>>>>>>> actually included within <x3d> ... </x3d>?
>>>>>>>>>
>>>>>>>>> Maybe one example is x3d hanim where we define real skin vertices
>>>>>>>>> bound
>>>>>>>>> to real joints to achieve realistic deformable skin. In HAnim the
>>>>>>>>> first
>>>>>>>>> level of animation complexity is a realistic skeleton of joints
>>>>>>>>> with
>>>>>>>>> simple binding of shapes to segments in a heirarchy where joint
>>>>>>>>> center
>>>>>>>>> rotations can produce realitic movements of the skeleton. As a
>>>>>>>>> joint
>>>>>>>>> center rotates then its children segments and joints move as
>>>>>>>>> expected
>>>>>>>>> for the skeleton dynamics. For seamless animations across segment
>>>>>>>>> shapes, then the technique is to bind each skin vertex to one or
>>>>>>>>> more
>>>>>>>>> joint objects, then move the skin some weighted displacement as
>>>>>>>>> the
>>>>>>>>> joint(s) center(s) rotates.
>>>>>>>>>
>>>>>>>>> To document this completely in human-readable and editable form,
>>>>>>>>> as is
>>>>>>>>> the goal of .x3d HAnim, is very tedious, but that is exactly how
>>>>>>>>> it is
>>>>>>>>> actually finally computed in the wide world of rigging and in
>>>>>>>>> computationally intensive. Thus, it makes sense for <x3d> ...
>>>>>>>>> </x3d> to
>>>>>>>>> support shapes bound to segments that are children of joints but
>>>>>>>>> not
>>>>>>>>> demand full support for deformable skin. Hopefully the javascript
>>>>>>>>> programmers that are now building the basic foundations to
>>>>>>>>> support x3d
>>>>>>>>> using webgl features will prove me wrong, but without very high
>>>>>>>>> performance support for reasonable density deformable skin, this
>>>>>>>>> does
>>>>>>>>> not need to be supported in the (2.) html environment. Of course
>>>>>>>>> standalone and embeddable players can do this because they will
>>>>>>>>> have
>>>>>>>>> access to the high performance code and acceleration that may not
>>>>>>>>> be
>>>>>>>>> available in .html with webgl.
>>>>>>>>>
>>>>>>>>> Thanks for thinking about this stuff.
>>>>>>>>>
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>> http://www.hypermultimedia.com/x3d/hanim/hanimLOA3A8320130611Allanimtests.x3dv
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.hypermultimedia.com/x3d/hanim/hanimLOA3A8320130611Allanimtests.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.hypermultimedia.com/x3d/hanim/JoeH-AnimKick1a.x3dv
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message ----- From: "doug sanden"
>>>>>>>>> <highaspirations at hotmail.com>
>>>>>>>>> To: "'X3D Graphics public mailing list'" <x3d-public at web3d.org>
>>>>>>>>> Sent: Friday, June 10, 2016 7:03 AM
>>>>>>>>> Subject: Re: [x3d-public] [x3d] V4.0 Opendiscussion/workshopon
>>>>>>>>> X3DHTML
>>>>>>>>> integration
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 3-step 'Creative Strategy'
>>>>>>>>> http://cup.columbia.edu/book/creative-strategy/9780231160520
>>>>>>>>> https://sites.google.com/site/airdrieinnovationinstitute/creative-strategy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. break it down (into problem elements)
>>>>>>>>> 2. search (other domains for element solutions)
>>>>>>>>> 3. recombine (element solutions into total solution)
>>>>>>>>>
>>>>>>>>> e - problem element
>>>>>>>>> d - domain offering solution(s) to problem elements
>>>>>>>>> e-d matrix
>>>>>>>>> ______d1________d2______d3__________d4
>>>>>>>>> e1
>>>>>>>>> e2
>>>>>>>>> e3
>>>>>>>>> e4
>>>>>>>>>
>>>>>>>>> Applied to what I think is the overall problem: 'which v4
>>>>>>>>> technologies/specifications' or 'gaining consensus on v4 before
>>>>>>>>> siggraph'.
>>>>>>>>> I don't know if that's the only problem or _the_ problem, so this
>>>>>>>>> will
>>>>>>>>> be more of an exercise to see if Creative Strategy works in the
>>>>>>>>> real
>>>>>>>>> world, by using what I can piece together from what your're
>>>>>>>>> saying as an
>>>>>>>>> example.
>>>>>>>>> Then I'll leave it to you guys to go through the 3 steps for
>>>>>>>>> whatever
>>>>>>>>> the true problems are.
>>>>>>>>> Problem: v4 specification finalization
>>>>>>>>> Step1 break it down:
>>>>>>>>> e1 continuity/stability in changing/shifting and multiplying
>>>>>>>>> target
>>>>>>>>> technologies
>>>>>>>>> e2 html integration > protos
>>>>>>>>> e3 html integration > proto scripts
>>>>>>>>> e4 html integration > inline vs Dom
>>>>>>>>> e5 html integration > node/component simplification
>>>>>>>>> e6 html integration > route/event/timer
>>>>>>>>> e7 html integration > feature simplification ie SAI
>>>>>>>>> e8 siggraph promotion opportunity, among/against competing 3D
>>>>>>>>> formats /
>>>>>>>>> tools
>>>>>>>>>
>>>>>>>>> Step 2 search other domains
>>>>>>>>> d1 compiler domain > take a high-level cross platform language
>>>>>>>>> and
>>>>>>>>> compile it for target CPU ARM, x86, x64
>>>>>>>>> d2 wrangling: opengl extension wrangler domain > add extensions
>>>>>>>>> to 15
>>>>>>>>> year old opengl32.dll to make it modern opengl
>>>>>>>>> d3 polyfill: web browser technologies > polyfill - program
>>>>>>>>> against an
>>>>>>>>> assumed modern browser, and use polyfill.js to discover current
>>>>>>>>> browser
>>>>>>>>> capaiblities and fill in any gaps by emulating
>>>>>>>>> d4 unrolling: mangled-name copies pasted into same scope - don't
>>>>>>>>> know
>>>>>>>>> what domain its from, but what John is doing when
>>>>>>>>> proto-expanding, its
>>>>>>>>> like what freewrl did for 10 years for protos
>>>>>>>>> d5 adware / iframe / webcomponents > separate scopes
>>>>>>>>> -
>>>>>>>>> https://blogs.windows.com/msedgedev/2015/07/14/bringing-componentization-to-the-web-an-overview-of-web-components/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> http://www.benfarrell.com/2015/10/26/es6-web-components-part-1-a-man-without-a-framework/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - React, dojo, polymer, angular, es6, webcomponents.js polyfill,
>>>>>>>>> shadoow
>>>>>>>>> dom,import, same-origin iframe
>>>>>>>>>
>>>>>>>>> d6 server > when a client wants something, and says what its
>>>>>>>>> capabilities are, then serve them what they are capable of
>>>>>>>>> displaying
>>>>>>>>> d7 viral videos
>>>>>>>>>
>>>>>>>>> (its hard to do a table in turtle graphics, so I'll do e/d lists)
>>>>>>>>> e1 / d1 compiler: have one high level format which is technology
>>>>>>>>> agnostic, with LTS long term stablility, and compile/translate to
>>>>>>>>> all
>>>>>>>>> other formats which are more technology dependent. Need to
>>>>>>>>> show/prove
>>>>>>>>> the high level can be transformed/ is transformable to all
>>>>>>>>> desired
>>>>>>>>> targets like html Dom variants, html Inline variants, and desktop
>>>>>>>>> variants
>>>>>>>>> e4 / d1 including compiling to inline or dom variants
>>>>>>>>> e1 / d6 server-time transformation or selection: gets client
>>>>>>>>> capabilities in request, and either
>>>>>>>>> - a) transforms a generic format to target capabilities variant
>>>>>>>>> or
>>>>>>>>> - b) selects from among prepared variants to match target
>>>>>>>>> capaibilties,
>>>>>>>>> e5 / d1 compiler: can compile static geometry from high level
>>>>>>>>> nurbs/extrusions to indexedfaceset depending on target
>>>>>>>>> capabilities,
>>>>>>>>> need to have a STATIC keyword in case extrusion is animated?
>>>>>>>>> e6 / d1 compiler transforms routes, timers, events to target
>>>>>>>>> platform
>>>>>>>>> equivalents
>>>>>>>>>
>>>>>>>>> e5 / d2 extension wrangling > depending on capaiblities of
>>>>>>>>> target,
>>>>>>>>> during transform stage, substitute Protos for high level nodes,
>>>>>>>>> when
>>>>>>>>> target browser can't support the component/level directly
>>>>>>>>> e5 / d3 polyfill > when a target doesn't support some feature,
>>>>>>>>> polyfill
>>>>>>>>> so it runs enough to support a stable format
>>>>>>>>>
>>>>>>>>> e8 / d7 create viral video of web3d consortium
>>>>>>>>> deciding/trying-to-decide
>>>>>>>>> something. Maybe creative strategy step 3: decide among matrix
>>>>>>>>> elements
>>>>>>>>> at a session at siggraph with audience watching or participating
>>>>>>>>> in
>>>>>>>>> special "help us decide" siggraph session.
>>>>>>>>>
>>>>>>>>> e2 / d5 webcomponents and proto scripts: create scripts with/in
>>>>>>>>> different webcomponent scope;
>>>>>>>>> e3 / d5 webcomponents make Scene and ProtoInstance both in a
>>>>>>>>> webcomponent, with hierarchy of webcomponents for nested
>>>>>>>>> protoInstances.
>>>>>>>>> e2+e3 / d4 unrolling + protos > unroll protos and scripts a)
>>>>>>>>> upstream/on
>>>>>>>>> server or transformer b) in client on demand
>>>>>>>>>
>>>>>>>>> e7 / d6 server simplifies featuers ie SAI or not based on client
>>>>>>>>> capabilities
>>>>>>>>> e7 / d1 compiler compiles out features not supported by target
>>>>>>>>> client
>>>>>>>>>
>>>>>>>>> ____d1___d2___d3___d4___d5___d6___d7
>>>>>>>>> e1 __ * _______________________ *
>>>>>>>>> e2 _________________ *___*
>>>>>>>>> e3 _________________ *___*
>>>>>>>>> e4 _*
>>>>>>>>> e5 _*_____*____*
>>>>>>>>> e6 _*
>>>>>>>>> e7 _*_________________________*
>>>>>>>>> e8 ________________________________*
>>>>>>>>>
>>>>>>>>> Or something like that,
>>>>>>>>> But would Step 3 creatively recombine element solutions into
>>>>>>>>> total
>>>>>>>>> solution still result in deadlock? Or can that deadlock be one of
>>>>>>>>> the
>>>>>>>>> problem elements, and domain solutions applied? For example does
>>>>>>>>> the
>>>>>>>>> compiler/transformer workflow idea automatically solve current
>>>>>>>>> deadlock,
>>>>>>>>> or does deadlock need more specific attention ie breakdown into
>>>>>>>>> elements
>>>>>>>>> of deadlock, searching domains for solutions to deadlock elements
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> HTH
>>>>>>>>> -Doug
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> x3d-public mailing list
>>>>>>>>> x3d-public at web3d.org
>>>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> x3d-public mailing list
>>>>>>>>> x3d-public at web3d.org
>>>>>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>>>>
>>>>>>>> -- 
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
>>>>>>>> Trippstadter Strasse 122, D-67663 Kaiserslautern
>>>>>>>>
>>>>>>>> Geschäftsführung:
>>>>>>>>  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>>>>>>>>  Dr. Walter Olthoff
>>>>>>>> Vorsitzender des Aufsichtsrats:
>>>>>>>>  Prof. Dr. h.c. Hans A. Aukes
>>>>>>>>
>>>>>>>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>>>>>>>> VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
>>>>>>>> ---------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
>>>>>> Trippstadter Strasse 122, D-67663 Kaiserslautern
>>>>>>
>>>>>> Geschäftsführung:
>>>>>>  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>>>>>>  Dr. Walter Olthoff
>>>>>> Vorsitzender des Aufsichtsrats:
>>>>>>  Prof. Dr. h.c. Hans A. Aukes
>>>>>>
>>>>>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>>>>>> VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
>>>>>> ---------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> x3d-public mailing list
>>>>> x3d-public at web3d.org
>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>>
>>>>
>>>> -- 
>>>>
>>>> -------------------------------------------------------------------------
>>>>
>>>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
>>>> Trippstadter Strasse 122, D-67663 Kaiserslautern
>>>>
>>>> Geschäftsführung:
>>>>  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>>>>  Dr. Walter Olthoff
>>>> Vorsitzender des Aufsichtsrats:
>>>>  Prof. Dr. h.c. Hans A. Aukes
>>>>
>>>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>>>> VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
>>>> ---------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>
>>
>> -- 
>>
>> -------------------------------------------------------------------------
>> Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
>> Trippstadter Strasse 122, D-67663 Kaiserslautern
>>
>> Geschäftsführung:
>>  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
>>  Dr. Walter Olthoff
>> Vorsitzender des Aufsichtsrats:
>>  Prof. Dr. h.c. Hans A. Aukes
>>
>> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>> VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
>> ---------------------------------------------------------------------------
>>
>>
> 

-- 

-------------------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern

Geschäftsführung:
  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
  Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
  Prof. Dr. h.c. Hans A. Aukes

Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
---------------------------------------------------------------------------


-- 

-------------------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern

Geschäftsführung:
  Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
  Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
  Prof. Dr. h.c. Hans A. Aukes

Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
VAT/USt-Id.Nr.: DE 148 646 973, Steuernummer:  19/673/0060/3
---------------------------------------------------------------------------