Re: Blackboard

Hi!

On Monday 15 July 2002 17:18, Greg Copeland wrote:
> On Sun, 2002-07-14 at 16:34, Andreas Zehender wrote:
> > I have just written down the ideas from the last discussions
> > You can see it at http://www.kpovmodeler.org/blackboard.html
>
> Additional follow up or comments on the animation/scripting items
> currently on the blackboard.  I'm not sure if these are differences in
> expectations or simply how I'm interpreting (being too literal) the
> blackboard, however, I thought I'd go ahead and toss these out there.

That is only a collection of catchwords, no real ideas.

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

Well, I didn't think about animation support yet and will not do that within 
the next weeks. My free time is limited at the moment. First priority is the 
documentation, then the plugin api and then animation with basic scripting.

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

Sure.

> 	Collision Detection (CD)
> 		When I originally mentioned this, I envisioned the simplest of CD and
> allow for complex CD via scripting.  Remember, since python is being
> used, it can pretty easily be extended via C or C++ which means even
> custom objects could be addressed via this type of CD approach.

But imagine a csg that consists of a height field, a lathe and a polynom. I 
would say a real, exact collision detection is impossible.

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

I think we should ask the user if a scene for an older povray version should 
be converted and support only one version. At least that is the easiest way.

Andreas
-- 
--------------------------------------------------
 Andreas Zehender, Dipl. Ing. (BA)
 Student, 10th semester computer science
 http://www.azweb.de
 [email protected] | [email protected]      
--------------------------------------------------


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