cbullard at hiwaay.net
Tue Apr 28 09:54:10 PDT 2009
I've missed you, M. Where ya been? Crazy musical *video* 3D guy if you
don't mind. Jing SonyVegas Contact Vivaty make that easy to do. For a
storyteller, it is an excellent way to use the libraries and then YouTube.
Happy days are here again!
Personal: I'm having a real good time putting the IrishSpace video
together. Our VRML gift to YouTube from a time not so long ago....
Correct. Interpolators are questionable. I don't think it is because they
are hard to understand. It is that they are hard to plot by dead reckoning
looking at the screen. Whatever the impact on the engine, doing fractional
changes in one's head is not a skill most people have. Even if you tell
them it is just a sample of positions along a poly line unless they really
want to do the calculations, they won't. It's tedious. Best done by
sampling, I think, and therefore how much of that is exposed in the text vs
how that is rendered are all good things to question.
OTOH, the charm of interpolators and timers is the fractional variation
possible in the local time of the objects. All objects have internal rhythm
and the interpolators are excellent for inscribing beat/pace into local
The scene graph is sound. The objects in it need refactoring to account for
authoring. Initially, Gavin Bell wanted the faster rendering of lower
level constructs. We can now afford to trade a little initialization time
for easier drag and drop objects.
Routes? I'm torn. They are appealing to the patch board guy in me. They
fix eventIn/Out type compatibility enabling author constructable
relationships. It is a creative approach given the author or system need
only know the types to hook them up. Then results are what they are but it
is one of the more fascinating aspects of the system to explore. It turns
out very many natural motions are simple logarithmic scales or amenable to
that time-based representation.
Routes? Very good for the GUI (graph editing and validation).
Is that on the wrong side of the data though? IOW, what should be in XML?
What shouldn't? How much should show up in the GUI?
Given a standard dialog editor, what X3D objects would you expect to see
represented? All of them? Some for some and not for others? IOW, I'm a
musician. I EXPECT to see the audio object properties beyond the URL. Is
VRML authors know there is a common toolkit a lot of us use. How can that
become one toolkit everyone has?
Well... if Google hosts a building space for VRMLers that works with that,
they can make that happen the same way they make the blogs happen. It
depends on what is in it for Google and only Google can answer that.
Summary: We need a cleaner framework of drag and drop composable 3D objects
on the web and a standard set of symbols for denoting those in the 2D layer.
Interesting bifurcation. Google dives toward the hardware API to enable
author world asks for more composable objects. There is baby in that
bathwater. Experimenting with a cleaner separation of where GUI behavior
and graphics engine calls to the hardware are represented in declarative and
imperative script enables more experimentation with the drag and drop
objects, the meat of composability.
Nay! Composable libraries, reusable, cheap to build but built to last by
being open IP-free technology.
Yes, the miracle of VRML is it is still standing. As I said, the only test
that matters to me.
From: miriam [mailto:miriam at werple.net.au]
Sent: Tuesday, April 28, 2009 5:29 AM
To: Len Bullard
Time for me to chime in here I guess. Long time no speak... I still lurk
I have no real opinion one way or the other about Google's offering. It
might come through... it might not. I guess we'll see. For various
historical reasons VRML/X3D had a shot at the big lights and *almost*
made it. Will it still eventually make it? Who knows?
But one thing I *must* correct is Len's statement that "Interpolators
for example, are a pretty good authoring hedge because most people get
the idea of clock ticks and points on a line."
No way! Len, I think you are the greatest, but boy, are you wrong here!
Interpolators are great for the browser programmers but they are
actually antithetical to how most people think and it takes quite a bit
of mind-stretching to get used to them. Ask someone how they want to
move something and they'll generally say something like "that direction
at that speed", whereas interpolators require start point, start time,
end point, end time, and if the movement is not constant then one or
more inbetween point and inbetween time too.
Even the simplest animation in VRML/X3D requires a timer, an
interpolator, a sensor, and a moderately involved way of connecting
If you want to do non-deterministic animation, like a lot of blocks
falling in a heap then it becomes almost impossible with interpolators.
Contrast this with scriptable objects in ActiveWorlds, which are simply
told to move when they sense something. I don't know how things work in
SecondLife, but I bet it doesn't use interpolators. Not long ago I was
fiddling with pygame and it allows non-deterministic actions. The
programming is probably as complicated and non-intuitive as VRML/X3D for
getting animations working, but it is far more flexible. Blender (my
main 3d tool now) is far more capable than either pygame or VRML/X3D and
is almost entirely point-and-click. Added to that, you can do extremely
complex scripting that I wouldn't even attempt in VRML/X3D. (Blender has
a very steep learning curve, but it is worth it.)
But in the end I have to agree with you Len, that the more toys, the
I know I seem to dump on VRML/X3D whenever I pipe up, but in truth I'll
always have a very big soft spot for it. I still tell gob-smacked little
kids that using VRML they can make a simple world in just 3 lines of
text. There is something very profound in that. Also very cool is the
learning curve of VRML/X3D: you can get started knowing very little
about it and learn as you go.
My big disappointment was always that the potential was never fully
realised. Some of that was the "fault" of VRML and the community and the
consortium; some of it was outside anybody's control (the browser wars,
the changing rules for embedding plugins, the IE security problems, SGI
incinerating their 3D arm, the Highlander tug of war between Cortona and
Contact, and so on). But whatever the reasons, VRML/X3D took a hell of a
beating over the decade or so. What is most surprising of all is that it
is still standing.
Good luck to you all (and to you especially Len, you crazy, musical, 3d
Len Bullard wrote:
> 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
> of clock ticks and points on a line. Should that be automated? Sure.
> the real-time 3D world coordinate animation model with
> 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
> 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]
> Behalf Of Lars O. Grobe
> Len Bullard schrieb:
>> Converting a Phong sphere and converting the behaviors of any real-time
>> content are not so simple.
>> 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.
> X3D-Public mailing list
> X3D-Public at web3d.org
My time wasn't completely wasted last year.
I went on a 940 million kilometer journey.
More information about the X3D-Public