[X3D-Public] my musings on O3D and JavaScript on the web

Len Bullard cbullard at hiwaay.net
Sat Apr 25 00:34:42 PDT 2009

Yes, if the sensors scare them, maybe they don't understand the model.
VRML97 and by lineage, X3D, do have a lot of features.  Interpolators for
example, are a pretty good authoring hedge because most people get the idea
of clock ticks and points on a line.  Should that be automated?  Sure.

It may be this is also coming down to the HTML/Javascript page model versus
the real-time 3D world coordinate animation model with
Javascript/EcmaScript.  The discontent here is most likely over the SAI.

As to mass market, the mass market is adopting Vivaty at a good clip and
getting their feet wet that way.  The mass market doesn't code.  It drags,
drops and goes.  The high end simulation market where the code crosses grow
wild is adopting Bit Management, Octaga, and Cortona.  The game market for
ubiquity is adopting Flash.  Gamers are adopting frameworks like Unity3D.

What am I missing here?

I think mass adoption to some means mass adoption by programmers and those
who need to write specialty engines can certainly use O3D to do it, and
import quite a bit of X3D.  All?  Who knows but that is irrelevant as long
as the engines we do write for survive.

In the long run, that is the test.

That said, bring it on.  More toys is more toys and a 3D scripted HTML
wedgie is likely to be useful.


From: x3d-public-bounces at web3d.org [mailto:x3d-public-bounces at web3d.org] On
Behalf Of Lars O. Grobe

Len Bullard schrieb:
> Converting a Phong sphere and converting the behaviors of any real-time 3D
> content are not so simple.
> What does an O3D converter do with the internal Javascripts,
> sensors, and so on?

I think this is part of the alternative that this new engine offers.

A) Convert the 3d-part into low-level code that will work in any web
browser, make it simple and have this work with all kind of

B) Have a scripting interface, that again works fine in any web browser,
to implement the logic.

x3d tries to solve both at once. This may be a nice idea, but in many
cases fails. Most work-flows produce geometry from tools that do not
know anything about behaviour - so there is no need to stuff all of it
into one format. And dividing logic and geometry not only matches the
tools better in many cases - it avoids a lot of errors.

So if anyone wants to compare the sphere with some logic in x3d and o3d
- look only at the logic part, as the geometry can be imported and will
not by created by typing in a text editor in most cases.

Do not misunderstand me, I still think that x3d is a great tool. But for
a mass market adoption, the support by web browsers is missing. And the
developers of these browsers obviously fear integrating the whole system
of geometry, sensors, scripts that comes with x3d, as they can have the
same result with adding some 3d geometry features to existing
programming apis. Can we blame them?

CU Lars.

More information about the X3D-Public mailing list