Difference between revisions of "X3D/HTML Integration"

From Web3D.org
Jump to: navigation, search
(Created page with "Example to investigate X3D/HTML specification issues As an illustration consider the X3DOM example "OnOutputChange" <pre> <html> <head> <meta http-equiv="X-UA-Compatible...")
 
(→‎Summary)
 
(20 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
Example to investigate X3D/HTML specification issues
 
  
−
As an illustration consider the X3DOM example "OnOutputChange"
+
== Examples ==
  
−
<pre>
+
X3DOM: [[OnOutputChange Example]]
−
<html>
+
−
<head>
+
−
    <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
+
−
    <title>X3Dom Example OnOutputChange Event</title>
+
−
    <script type='text/javascript' src='http://x3dom.org/release/x3dom.js'> </script>
+
−
    <link rel='stylesheet' type='text/css' href='http://www.x3dom.org/download/x3dom.css'/>
+
  
 +
X3DOM: [[Interactive 3D Transformations Example]]
  
−
<script>
+
== Summary ==
−
/**
+
−
* Uses the values of a PositionInterpolator to move another ball,
+
−
* but instead of just routing the values, round the y component.
+
−
* Thus the second ball moves like he is snapping to an invisible raster
+
−
*/
+
−
function snapBall(eventObject)
+
−
{
+
−
//Check if type and output of the eventObject are correct
+
−
//There may be multiple eventObjects but only one of them contains the value we need
+
−
if(eventObject.type != "outputchange" || eventObject.fieldName != "value_changed")
+
−
return;
+
−
+
−
//Get the value...
+
−
var value = eventObject.value;
+
−
//...and create a copy with the manipulated coordinates
+
−
var newPos = new x3dom.fields.SFVec3f(2, Math.round(value.y), 0);
+
−
+
−
//Set the newly created array as new position for the second ball
+
−
document.getElementById("ball2").setAttribute('translation', newPos.toString());
+
−
+
−
//Show debug information (of course the data can be used to control non x3dom-objects, too)
+
−
document.getElementById("posInterp").innerHTML = Math.round(value.y*100)/100;
+
−
document.getElementById("posSnaped").innerHTML = newPos.y;
+
−
}
+
−
</script>
+
  
−
</head>
+
So, specifying the integration of X3D into HTML requires a lot more than a simple encoding. Assuming we consider generating an ISO/IEC specification, should we be generating a 19776 series document. I believe the answer is no. We need a much more overarching document. I suggest a 19775-3 document, perhaps entitled "X3D Embedding in HTML" or "X3D Integration with HTML", or some such.
−
<body>
+
  
−
<h1>Animate Objects with X3DOM!</h1>
+
I see the following actions:
−
<p>
+
−
    Learn how to manipulate objects using values from the output of other objects.
+
−
</p>
+
  
−
<div>
+
# Review all X3DOM code, and understand the implications for specification.
−
Y-Position of output field (routed to red ball): <span id="posInterp"></span><br>
+
# Review all Cobweb code, and understand the implications for specification.
−
Calculated Y-Position (set directly to blue ball): <span id="posSnaped"></span>
+
# Review other 3D implementations, to see what lessons can be learned.
−
</div>
+
  
−
<x3d width='500px' height='400px'>
+
As these are reviewed we should start generating interface definitions. There's nothing like putting pen to paper, or pressing keys, and generating some technical details as we go. These can be short interface definitions, as above.
−
    <scene>
+
−
        <transform DEF="ball" translation='-2 0 0'>
+
−
        <shape>
+
−
            <appearance>
+
−
                <material diffuseColor='1 0 0'></material>
+
−
            </appearance>
+
−
            <sphere></sphere>
+
−
        </shape>
+
−
        </transform>
+
−
       
+
−
        <transform DEF="ball2" translation='2 0 0' id="ball2">
+
−
        <shape>
+
−
            <appearance>
+
−
                <material diffuseColor='0 0 1'></material>
+
−
            </appearance>
+
−
            <sphere></sphere>
+
−
        </shape>
+
−
        </transform>
+
  
−
        <timeSensor DEF="time" cycleInterval="4" loop="true"></timeSensor>
+
Furthermore, we are already aware of a number of general issues:
−
        <PositionInterpolator DEF="move" key="0 0.5 1" keyValue="-2 -2.5 0  -2 2.5 0  -2 -2.5 0" onoutputchange="snapBall(event)"></PositionInterpolator>
+
−
       
+
−
        <Route fromNode="time" fromField ="fraction_changed" toNode="move" toField="set_fraction"></Route>
+
−
        <Route fromNode="move" fromField ="value_changed" toNode="ball" toField="translation"></Route>
+
−
    </scene>
+
−
</x3d>
+
  
 +
# Fields - DOMStrings vs X3D types
 +
# Event models
 +
# DEF/USE vs ID/IDREF
 +
# Capitalization
 +
# Namespace
 +
# Scripts and Prototypes
 +
# (any I have missed)
 +
## DOM Extension
 +
## Other event handlers
 +
## Closing tags
 +
## X3D tag attributes
  
−
</body>
+
We should look at each, and understand the implications for both 19775-1 and the new specification.
−
</html>
+
 
−
</pre>
+
So leaping ahead, we could specify every node.
 +
 
 +
The GitHub repository for X3DOM contains small js files, in a folder structure. For downloading these seem to be combined into a single file. So if it contained all the nodes, it would be a large file. This is undesirable, particularly for mobile devices. So, can it be broken down into subunits?
 +
 
 +
XML3D are taking the approach of breaking down using a vertical stratification. This means they define a small core, which also incorporates an API, and then can define other nodes in terms of that API. So, presumably you have a relatively small core, and need additional downloads to add to it.
 +
 
 +
What about X3D? We have been talking about an HTML profile. We already have components. So our stratification is more horizontal. We could foresee a relatively small main file, for the basic HTML profile. Then an author could specify additional components, which would require a small separate download for each component. Is this a practical solution? Can subsequent js files make reference to functionality downloaded in a primary js file? The answer is believed to be yes, but confirmation is required.
 +
 
 +
Assuming the answer to the last question is yes, then we have to:
 +
 
 +
* Define an HTML profile.
 +
 
 +
What about Web components? How do they fit into the picture?
 +
 
 +
There are:
 +
* Custom Elements - Is this useful for X3D prototypes?
 +
* HTML Imports - Is this useful for X3D Inlines?
 +
* Templates - Is this useful for X3D prototypes?
 +
* Shadow DOM - This might solve the namespace problem
 +
 
 +
W3C Validator plugin would be a good idea to enable X3D validation in HTML

Latest revision as of 10:05, 15 June 2016

Examples

X3DOM: OnOutputChange Example

X3DOM: Interactive 3D Transformations Example

Summary

So, specifying the integration of X3D into HTML requires a lot more than a simple encoding. Assuming we consider generating an ISO/IEC specification, should we be generating a 19776 series document. I believe the answer is no. We need a much more overarching document. I suggest a 19775-3 document, perhaps entitled "X3D Embedding in HTML" or "X3D Integration with HTML", or some such.

I see the following actions:

  1. Review all X3DOM code, and understand the implications for specification.
  2. Review all Cobweb code, and understand the implications for specification.
  3. Review other 3D implementations, to see what lessons can be learned.

As these are reviewed we should start generating interface definitions. There's nothing like putting pen to paper, or pressing keys, and generating some technical details as we go. These can be short interface definitions, as above.

Furthermore, we are already aware of a number of general issues:

  1. Fields - DOMStrings vs X3D types
  2. Event models
  3. DEF/USE vs ID/IDREF
  4. Capitalization
  5. Namespace
  6. Scripts and Prototypes
  7. (any I have missed)
    1. DOM Extension
    2. Other event handlers
    3. Closing tags
    4. X3D tag attributes

We should look at each, and understand the implications for both 19775-1 and the new specification.

So leaping ahead, we could specify every node.

The GitHub repository for X3DOM contains small js files, in a folder structure. For downloading these seem to be combined into a single file. So if it contained all the nodes, it would be a large file. This is undesirable, particularly for mobile devices. So, can it be broken down into subunits?

XML3D are taking the approach of breaking down using a vertical stratification. This means they define a small core, which also incorporates an API, and then can define other nodes in terms of that API. So, presumably you have a relatively small core, and need additional downloads to add to it.

What about X3D? We have been talking about an HTML profile. We already have components. So our stratification is more horizontal. We could foresee a relatively small main file, for the basic HTML profile. Then an author could specify additional components, which would require a small separate download for each component. Is this a practical solution? Can subsequent js files make reference to functionality downloaded in a primary js file? The answer is believed to be yes, but confirmation is required.

Assuming the answer to the last question is yes, then we have to:

  • Define an HTML profile.

What about Web components? How do they fit into the picture?

There are:

  • Custom Elements - Is this useful for X3D prototypes?
  • HTML Imports - Is this useful for X3D Inlines?
  • Templates - Is this useful for X3D prototypes?
  • Shadow DOM - This might solve the namespace problem

W3C Validator plugin would be a good idea to enable X3D validation in HTML

Retrieved from "https://www.web3d.org/wiki/index.php?title=X3D/HTML_Integration&oldid=9427"