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.
|