Re: Blackboard

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.

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.

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

	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.



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?


Greg

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

iD8DBQA9MufE4lr1bpbcL6kRAmrBAJ4zp4Ej/gKaoranVN2EzYQiZEr61ACfZ/uU
P2qtCDE2RZ5lvxWbp7VNH+0=
=Fw0C
-----END PGP SIGNATURE-----