Open Standards for Real-Time 3D Communication

So great, we can control the scene and scene nodes with external scripts. Yes, since when could we not do that. The emerging environments will conserve the choice of providing this scriptable object to the user. The choice will be made either by content development tools of the host organization, ‘automatically’ at the server, possibly restricted by the client OS, further processed by the host browser, and finally, affirmatively approved by the actual user.

Essentially, the future of embed gives you the equivalent of the animated .gif option for X3D. Everything interactive you want to do in your scene has got to be in the scene already. Once its loaded, it must be treated as a complete object with no access to its internal properties. But Hey, that is OK, because the .x3d object, like the animated .gif object, can do anything it wants as long as it stays in it’s container.
As excited as I am about AjaX3D and the idea of running the scene as a child of the html/xhtml browser, I see it will require some learning/relearning to use this powerful technique. The fact that it is an ‘object’ in that browser means that by security definitions it is highly managed. For example, some servers will strip or replace html/xhtml object tags, maybe replacing them with embed, or nothing at all. Think required html image tag alt attribute along with embed and object tag html fallback.

But that is off the main topic, which is how to best use this powerful stuff to best advantage. For this I must resort to heresy and history. The most recent history I will tap is from the AjaX3D.org forums, mainly extending Tony’s example where an external dom script causes a change in the scene state. I hope I give proper requested credit to KimballSoftware here in the course of the example, as a valued contributor to AjaX3D forums. The concept is very straightforward.

This is a timed event, in that the scene update happens about every 1/2 second. It makes great advantage of a host script timer to cause the update.

dom.js
setInterval(’pingPong()’,500);

then every 500 ms pingPong sends

newTranslation=boxNode.getField(’set_translation’);

and the scene changes

.x3d

when X3D SAI boxNode translation is updated. This makes a nice little scene where the red box moves to and fro across the viewport and is a nice example of how responsive a modern HTML/XHTML DOM along with a modern X3d SAI can be. It goes a long way in showing in a simple way how powerful this really is. And, it is at least 1/3 of the AjaX3D story. The next 1/3 along this line would be use an X3D SAI timer and send events to move a DOM object around the window. Then we can do heavy Ajax for sure!

While this example takes me back to some very ‘early’ days of seeing some very amazing VRML stuff, we gotta be careful. Now for the heresy: This is the way VRML1 was first animated. Beginning in VRML97 and continuing in X3D, behaviors were added to static VRML1. One of the main reasons for this was realizing that for a basic time and event-driven system, time-based scene behaviors can be handled much more effectively from the inside, rather than the outside. This is more true now than ever before.

So let’s take that example of the SAI sending periodic events to the containing DOM, then having the DOM move some divs around the window.

As I consider how to implement this using the SAI, unlike the unassisted html DOM, I have a choice. Since the above DOM script is in ECMAscript, I could just move it into an SAI script node, and with luck, it would work when I achieve the correct SAI<=>DOM connections. Or, at least I can substitute the X3D TimeSensor for setInterval, use some utility logic elements and maybe even not need any script at all. Depending upon what is really necessary, in the general case for this type of visual, the ‘best’ way to do this in X3D is simply to enable/disable a timer/interpolater combo to get the data. The point is, that the X3D SAI offers many built-in nodes for time-based animation that do not appear in html until you add scripting and timing interfaces.

How does this apply to the beginning question of what’s the difference between html object and embed? So what if you are not given a choice of which tag to use. There are at least a couple of reasons why this would happen. The first is just that it is a text browser and all that will be presented is whatever html fallback text you provided. Another might be that the basic OS being served won’t handle it, for example mobile or very small footprint browsers. They may not have enough power for animated .gif objects, certainly not enough for real active abjects. Or maybe active objects are OK, but you just can’t script them.

What is the difference? Apparently the only practical differences between the embed and object tag is that for embed, the current registered mime player is used exclusively, and that you can’t script it from the outside.

Essentially, embed gives you the equivalent of the animated .gif option for X3D. Everything interactive you want to do in your scene has got to be in the scene already. Once its loaded, it must be treated as a complete object with no access to its internal properties. But Hey, that is OK, because the .x3d object, like the animated .gif object can do anything it wants as long as it stays in it’s container.

From the X3D scene point of view, the DOM does “External” scripting of the scene while the SAI does “Internal” scripting of the scene. We have the host “live” DOM document object connected to the embedded “live” web3D X3D browser SAI execution context object. 
We can easily pass events to produce a highly interactive result.
That is, unless the ScriptSourceAccess flag or something like it is set.

Posted by Joe D Williams on 2006-10-06 | Permalink | Comments