Re: Blackboard

On Mon, 2002-07-15 at 15:25, Andreas Zehender wrote:
> Hi!
> 
> On Monday 15 July 2002 18:55, CARVALHO Luis Passos wrote:
> > > -----Original Message-----
> > > From: Greg Copeland [mailto:[email protected]]
> > > full control
> > > over pathing as well
> >
> > I'm not sure how Andreas sees this, but i see them as special
> > translate/rotate and scale objects, which contain specialized objects.
> >
> > For instance:
> >
> >    camera
> > 	movie translate
> > 		1  - 10s - spline
> > 		10 - 11s - line
> 
> Or create a spline as path and translate and rotate an object with
> translate somePath.pos( s ) where s is in [0 1]
> lookTo somePath.direction( s )

Since your already starting to get into expressions, perhaps the more
complex work should be left to the scripts and only very basic path
primitives be natively supported.  After all, I doubt it would take too
long to build a script repository for many more complex sequences.

Things like a basic spline, cos, sin, and vectors would seemingly
address basic animation needs.  For the rest, use scripts.

Same thing for accelerations.  Something like a couple of log (i.e.
natural and base 10) functions along with things like sin and cos should
do wonders..again, for basic animation.  Again, for the rest (more
complex needs), use scripts.

> 
> > We need to filter which objects are available for that povray version,
> > inside the objects what parameters are accepted, what validations are
> > valid, as they change from time to time, etc. Although pushing for the most
> > recent version might not be a problem as povray is free, supporting
> > different versions of official povray is just part of the problem. What
> > about megapov and other unofficial patches?
> 
> Don't you think that's too much overhead?
> Then we have to move almost everything from the dialog views to some 
> description file and create, display and validate the edit widgets 
> dynamically.
> 

Well, I'm very glad this was brought up because I forgot to address this
in my original topical post.  We really should allow for the name of the
povray executable to be given.  Likewise, there should be an option to
spawn a render manager as there are already some pre-existing render
managers which understand some of the other povray derivatives.

IMO, this would not only make it more flexible but more general purpose
too.


> > Now consider this:
> > 	PMPrototypeManager will implement a set of rules for canInsert. This
> > set of rules is softcoded on a file. That means we can easily provide
> > several different rule sets, one for each version/application.
> > 	PMIOManager manages import/export plugins for whatever format you
> > choose.
> >
> > The only problem that is left is the validation code for each object. One
> > solution is to only validate according to the most recent version. The
> > export plugin could then notify the user of wrong constructs when it does
> > the export.
> > This has the downside of deferring validation to the export of the scene,
> > which might be too late.
> 

We also need a plugin validator, if you will.  That is, if something
adds a new object type, it's not really going to do any good unless it
can read and (at a minumum) write it's data.  I imagine the more complex
the plugins there are, the more complex some of these rules will be.  Of
course, different categories of plugins will probably have different
sets of rules. 

Also, would be nice if plugins could someone express a dependency if
needed.  That is, let's say I have plugin a which creates a new type of
object.  Then, someone comes along and things they can leverage the work
of that plugin.  So, it requires plugin a as it further extends it.

Greg

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA9MzZr4lr1bpbcL6kRAjvAAJ43RAgtnkAmTQ73rnqOAObhcLIs+ACdH2xJ
S25HGMkB3Dom+sRNv8Ok9Tw=
=PK+X
-----END PGP SIGNATURE-----