I would like to hear comments and discussion on my implementations of motion
blur and persistent objects/variables.  Please read all of the documentation
first.  Some thoughts I have are these:

=================
- Persistent Variables -
=================

I opted for the all-or-nothing approach.  Either all variables are
persistent or none are.  This was by far the easiest and cleanest way to do
this.  Does this provide enough functionality?  (Remember, you can #undef
objects if you don't want them to be persistent.)

=================
- Persisten Objects -
=================

I want a consistent way of naming objects.  I don't like using one way to
name variables and another to name scene objects.  This is the reason I came
up with the #create= way of naming scene objects.

I ran into problems with whether to allow duplicate names.  The problem is
that not allowing duplicate labels for scene objects is tough, since there
is scope involved.  For example, if you have object "abc" inside a CSG
difference, it should not conflict with another object named "abc" which is
a frame-level object.  As it turns out, trying to code this into the
existing POV parser could get very messy, which means it would take a lot of
work and could easily have many bugs.  Then, if unions get split up (which
usually happens for speed reasons), things get really crazy.

I would like it if names for variables (created using #local or #declare)
and labeles for objects (created with label or #create) could be used
interchangeably.  For example, it would be nice to use modify{} on a
#declared object or to be able to make a copy of a #created object by using
another #create.  Although these are not necessary, the would make the
language more complete.  Unfortunately, this is also quite difficult to
implement and raises a variety of scoping issues.

Because scene objects can share labels, the object modifiers between the "{"
and "}" of the modify{} 'command' get parsed many times.  This could be
quite confusing to unsuspecting users.  Should modify be changed to #modify
to signify this?  Note that the syntax would be:
#modify{
  name
  modifiers
}
and NOT
#modify
  name
  modifiers
#end
The curly braces would have to remain due to the fact that
Parse_Object_Mods() expects to see the end curly brace.  Also that using
curly braces with #default is done, so this would not be unprescedented.

It would be nice to change more about objects than just their modifiers
(like moving control points of a bezier patch or moving vertices in a mesh).
However, major decisions about implementation standards and syntax need to
be made before this can be done.

=================
- Motion Blur -
=================

Similar concern as with modify{}, since the creation of the motion blur
object causes that section of the POV file to be parsed multiple times.
Unfortunately, this time a directive (with a #) would not be good, since
this is an object type and you need to do something like:
#declare myMotionBlurObject=motion_blur{
  sphere{clock,<0,0,0>}
  translate clock*x
}

Do you think this is a major problem or would good documentation and ample
warnings ward off confusion among users.  What I am worried about is
something like this:

#declare i=0;
#while(i<10)
motion_blur{
  myObject
  translate clock*x
  #declare i=i+1;
}
#end

Note how i would get 1 added to it many times before you got out of the
motion_blur object definition.  motion_blur{} is almost like an implied
#while loop.

-Nathan

Post a reply to this message

In article <3851c981@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> =================
> - Persistent Variables -
> =================
> 
> I opted for the all-or-nothing approach.  Either all variables are
> persistent or none are.  This was by far the easiest and cleanest way to 
> do
> this.  Does this provide enough functionality?  (Remember, you can #undef
> objects if you don't want them to be persistent.)

I think this is the best way to do it. Because of the way the scene 
files are structured, variables are always initialized. You can just 
check to see if the variable already exists if you want that one to be 
persistant.


> =================
> - Persistent Objects -
> =================

I really don't have any ideas about this, I do kind of like it the way 
you did it, though.


> =================
> - Motion Blur -
> =================
>
> motion_blur{} is almost like an implied #while loop.

This should definitely be kept, and just carefully documented. It could 
be very useful to be able to control the object blur motion with 
something in addition to the clock variable, using a variable 
incremented within the blur statement as a counter.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nathan Kopp <Nat### [at] Koppcom> wrote...
> Do you think this is a major problem or would good documentation and ample
> warnings ward off confusion among users.  What I am worried about is
> something like this:
>
> #declare i=0;
> #while(i<10)
> motion_blur{
>   myObject
>   translate clock*x
>   #declare i=i+1;
> }
> #end

Of course, the person SHOULD have typed:
#declare i=0;
#while(i<10)
motion_blur{
  myObject
  translate clock*x
}
#declare i=i+1;
#end

But confusion could exist nonetheless, since if this were, say, a 'sphere'
then both would work fine.  I guess maybe there's no avoiding it.

-Nathan

Post a reply to this message