I would agree with this definition. I would try to clarify it a bit
more by saying "IPC" instead of "outside factors".
> (Indeed, I'll be surprised if server-driven dynamism ever goes anywhere.
> It puts the processing requirements at the wrong end, requiring the
> server to do the processing for all of its clients. That's a nasty
> bottleneck for most applications. Regardless of the exact API chosen,
> I expect most dynamic processing to happen on the client in some
> fashion, just because clients usually have far more horsepower to
> spare.)
This is partly true, and I don't think that dynamic update mechanisms
should be used to handle frame-to-frame animation. I do think there
are still uses for it, however.
> >I don't think the animation functions completely solve the dynamic
> >update problem, which is essentially a transport issue.
>
> Well, more than just that. But the point is taken.
>
> > However, I
> >disagree with your statement that the encoded-in-the-scene behaviors
> >should not be part of the spec. I think they belong in the spec even
> >more than the dynamic update features.
>
> I'd disagree with "more than", but that's because my model of the
> right way to handle dynamic features (a proper programming language, a
> la Java or the Geomview language) could subsume all of the capabilities
> of such scene-coded behaviours. But yes, it's useful to have such
> things in. When you *do* want a simple static behaviour (and they are
> often quite useful), the engine model is almost certainly an easier
> way to implement it than a full-fledged program.
Yes, and there's already a fairly straightforward path to implementation,
through the existing Inventor engine mechanisms. I think Besoft is trying
to do too much with the engines, however, by trying to use them as interfaces
to interprocess communication (someone correct me if this is wrong). There
would be similar problems if one were to try to encapsulate communication
inside a scripting language. A much simpler conceptual model would separate
the two: scripting or engines for static animation, and some other more
appropriate mechanism for dynamic updates to the scene.
> (And that _ramp
> function of yours is a very nice general-purpose mechanism. Does
> Inventor have anything similar? I don't notice anything quite like
> it in a glance at the Mentor...)
Inventor does have a SoInterpolate set of classes, but they're not general
enough to do what _ramp does in an efficient way. Right now, _ramp is
implemented with a SoCalculator, which is kind of a hack. It should be
its own custom engine, that gets paramaterized by type of input and
output. This wouldn't be too difficult, I just haven't had time to
go back and fix it.
-- Pete McCann [email protected] Department of Computer Science http://swarm.wustl.edu/~mccap/ Washington University in St. Louis