I think what Dave is hitting on is
important here,
You don’t build logic into a data
file
What is needed by is to look at the
problem without resistance
From: owner-x3d-public@web3d.org
[mailto:owner-x3d-public@web3d.org] On Behalf
Of Dave
Sent: Tuesday, September 06, 2005
11:01 AM
To: giles@oz.net
Cc: vrmlworks@crispen.org; x3d
public mailing list
Subject: Re: [x3d-public] X3D is
too complex?
All good points, but as it relates to the original
comment (X3D is 'hard'), I forgot about Protos, which make it even harder.
Scripts are nearly impossible to convert to other
systems (anyone want to write a comprehensive Maya importer that
converts ecma to MEL?). A well-defined and
universally accepted collection of protos would definitely help, as it would
be easy to recognize, say, the
RotatationInterpolator that everyone knows and loves, and translate
accordingly.
A few of us have been kicking around the idea of
'smart objects' too. In any case, they should be well-defined and
extensively documented and easy to locate on the
web. Then guys like you and me and Aaron and Keith can put them in
our tools and all talk the same Lingo ;-)
DA
Alan Hudson wrote:
Dave wrote:
If an authoring tool is
not taking animation or interactivity into account, it's not an authoring tool
(IMHO), it's just a modeler.
The geometry, appearance, and lights are not that complex.
X3D Interactivity isn't TOO difficult, although parsing and processing ROUTES
is more complex than other simpler
event models I've seen. But X3D animation can be a write-only process. Take
simple rotation for example.
If you want something to rotate (in other packages), you'd specify axis or axes
and rotational rate(s), or total number
of degrees to rotate over so much time. Not in X3D - you set up key-frame
animation, which would take some sort
of AI to grok into knowing that it was a simple rotation. Not that it can't be
done, just that yeah, it can be hard to take
to other formats/tools.
The simple rotation you describe is one special case
of key-frame animation. I like the more general purpose answer of
providing linear interpolation values. Others have asked for higher-order
interpolators as well. If we provided an interpolator for each of the
special cases and the more general one then it bloat the spec and
implementations. You can always create a proto of the special cased animation
and use that in your content.
As for import of that data. Most authoring tools I've seen have used some
time based description of the animation. Ie likely something like the
key-frame interpolators. So I doubt its much harder to map that then the
easier description of rotations you describe. I feel like its more of a
UI issue. Ie the authoring tool might be simplier if it just offered the
simple case. But under the covers I see no reason it can't interchange
data using the key frames. With X3D metadata nodes its also possible to
give hints to authoring tools about the data. ie
RotationInterpolator {
metdata MetadataString {
name "Type"
reference "MyAuthoringTool"
value "SimpleRotationType"
}
...
}
So now when you read this in you can deduce that the interpolator actually
describes a simple special case. Likely you could determine it my mining
the actual values, but this mechanism allows you to deduce that without
spending much time reading the data.