RE: Blackboard

> -----Original Message-----
> From: Greg Copeland [mailto:[email protected]]
> Sent: segunda-feira, 15 de Julho de 2002 16:18
> To: [email protected]
> Subject: Re: Blackboard
> 
> Animation types
> 	Path translation (function, spline, ...)
> 		Does the function mean user supplied function 
> or a static list of
> internal functions.  In an ideal world, scripts would have 
> 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
		
> 
> 		Just a reminder here too, pathing includes not 
> only physical location
> but the velocity of the object as well.  That is, it's (+/-)
> acceleration and complimentary method of calculation should also be
> accessible or able to be provided via scripting.
> 

This is much easier to do via a scripting tool.

> 	Skeletal Animation
> 		Doesn't this mean that some sort of additional 
> constraint based system
> might also be required?  For more information on this, there is an old
> modeler called Sced which was completely written around the concept of
> constraint based modeling/animation.  Example, if I have two bones and
> one joint, I can independently move the two bones at it's joint,
> however, what constrains the joint's movement (e.g. I can't 
> move my arm
> 360').  Also, what if the movement of the two bones are 
> inherently tied
> together.  That is, if one moves, so must the other (think of 
> a scissor
> lift as an example) and then, only along certain axies.
> 

That's the idea as well. Constraints on each joint and maybe an optional
elasticity for the bone.
Much of this needs to be specified in order to make it simple and intuitive.
If it gets too complex it will
push users away.

> 	Attribute Modification
> 		Shouldn't scripts be able to not only modify 
> attributes but create and
> delete objects from within a scene?
> 

Yes. Editing the entire tree will be possible.

> 
> 
> POV-Ray Support
> 	What if only the current version is supported where 
> ever possible and
> the version of PoV that was used to develop a scene were 
> tracked?  That
> way, backward compatible options within povray can be enabled to
> properly render older scenes (see below).
> 
> 	I was reading through the documentation available for the latest
> version of PoV.  Seems they've done a pretty good job of of 
> allowing for
> backward compatibility as they historically have.  So, I was thinking
> that perhaps we could allow for a versioned include file which
> automatically allows for directive conversation (selecting proper
> directive options).  That is, as an example, the noise 
> function has been
> changed.  If someone is attempting to render a scene via PoV 
> 3.5 but was
> developed via the previous version, this file would be used 
> to selected
> the proper noise type generation.
> 
> 	By doing this, I was thinking that it would allow for a 
> high level of
> flexibility in backward compatibility.  Likewise, if a scene is loaded
> which was developed for an older version of PoV and object type is
> selected which has changed or is new, a warning can be issued to alert
> the user of possible backward compatibility issues.
> 
> 	The thinking here is, avoid trying to generate/support 
> code for old
> releases of PoV where ever possible.  After all, is it really a bad
> thing to require/push the latest version of PoV on the 
> kpovmodeler user
> base?

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?

And what if they change their format completely for povray 4.0?

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.

Reading your emails I see a trend towards just supporting one version. Thats
fine and dandy with me as well, but not everyone changes versions at the
same time. Some way of helping out those that stay behind would be nice, if
possible.

Regards,
Luis

List archive and information: http://mail.kde.org/mailman/listinfo/kpovmodeler-devel