Maybe I'm missing something, but I feel POVRay would strongly need some

kind of "render" statement. Let me explain: with version 3.1, POV has

achieved the status of a nearly complete programming language. It has

its own cyles, conditional tests, macros etc. BUT we still have to make

animations by the quite primitive mathod of calling the program

repeatedly with different arguments: this means re-parsing every time

and no chance of doing a complex animation. I know, now POV can read and

write files, but using them to store temporary variable values seems to

me a bit dumb. What we really need is a siple "render" statement. e.g





#declare a_cross = union {

			cylinder { <-1.5,0,0>, <1.5,0,0>, 0.3}

			cylinder { <0,1.5,0>, <0,-1.5,0>, 0.3}

		   }	





#macro DrawCross (rot,trans, colr)

	object {a_cross

		texture {pigment {color rgb colr}}

		rotate rot translate trans 

	}

#end







#declare cycles=0;


#while (cycles<36)

	DrawCross(<0,cycles*10,0>,<0,0,0>,<0,.8,.2>)

	#declare cycles=cycles+1;



	render <sort of a numbered-filename>//<- THIS IS THE NEW DIRECTIVE!


#end







The above code would render to a different file every time it comes upon

the "render" directive (36 times) from WITHIN the cycle, rather than at

the end of the complete parsing, thus outputting an animation. This way,
we could avoid working outside the POV program with limited .INI files
to achieve any kind of animation, at any level of complexity: particle
systems, mesh distortion/morphing ecc.

POV would become the most flexible 3D system in the world.



Am I wrong?



Could this be implemented via a patch (I don't think I have the skill to

do that)?



Please tell me your opinion!



Luca Rivelli <luk### [at] usanet>

Post a reply to this message

Hi all,

    I agree with this wholeheartedly and I'm implementing it (and more) as
you read. What I'm doing, though, won't be as seamless as many of you might
like. What I'm working on is a Perl module for POVRay. It is still in the
very early stages but I think it should work quite well. The reason I
started doing this is because I wanted to do some pretty complex animation
stuff (like object collisions, etc) and was finding the POV language
limiting. Perl is quite robust and fast and can probably handle many things
better than POV.
    There are a number of features this could be added once the base stuff
is in place. Stuff like easy object collision routines, physics stuff
(gravity, friction, etc), and just about anything you could think of. For
now I'm sticking with the basics but we'll see how it goes.
    I really think that POV is being limited by its need to be mostly
backwards compatible in the language. Also the fact that people good at
programming a ray-tracer may not be that good at writing a good language.
I'm not saying that I'm good at it either but I'm hopeing to build something
useful. Probably better than the way I'm doing it would be to change POV so
that it accepts a well-defined binary scene file and people could build any
type of preparser they like.
    Please don't think any of this is criticism to the POV team.
    Below is a small example. The syntax is mostly there but some things
will likely change as things advance more. I'll post here when things are to
the testing point. If you are interested in helping on this project please
contact me. Knowledge of Perl (and POV of course) are needed.


# beginning of perl script
use POV;

my $test = Scene->new;

my $tempPoint = Point->new( 1, 1, 1 );
my $thing1 = Sphere->new( $origin, 0.5 );

my $myTexture = Texture->new;
$myTexture->{pigment}->{color}->set( 1, 0, 1);
$thing1->{texture} = $myTexture;

$test->{camera}->{location}->set( 1, 1, -10 );
$test->{camera}->{look_at}->set( 1, 1, 1 );

my $count = 0;
while( $count < 10 ) {
    $thing1->{location}->{y}++;
    $test->render( "test", 640, 480 );
    $count++;
}

print "done\n";
# end example script


--Rainer


Lukee wrote in message <3654A5E9.90504827@altavista.net>...
>Maybe I'm missing something, but I feel POVRay would strongly need some
>kind of "render" statement
[snip]
>Luca Rivelli <luk### [at] usanet>

Post a reply to this message

This same question was posted in c.g.r.r and I really don't understand
where's the problem.
  You DON'T have to call povray for each frame. You can make an animation
by calling povray just ONCE. Where is the problem?

Rainer Mager <rvm### [at] cyberadjp> wrote:
: my $count = 0;
: while( $count < 10 ) {
:     $thing1->{location}->{y}++;
:     $test->render( "test", 640, 480 );
:     $count++;
: }

  I don't see the problem. That's very easy to do in povray:

object { thing1 translate y*clock*10 }

  And then calling povray with the parameters +kff10 +kc
(and yes, it will calculate all 10 frames without you needing to start
the program but just once).

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

But the entire scene has to be parsed again for every frame.

Margus

Nieminen Mika wrote:
> 
>   This same question was posted in c.g.r.r and I really don't understand
> where's the problem.
>   You DON'T have to call povray for each frame. You can make an animation
> by calling povray just ONCE. Where is the problem?

Post a reply to this message

Margus Ramst wrote:

> But the entire scene has to be parsed again for every frame.
>
> Margus

Which makes a lot of sense memory wise. If you have a 200
frame animation and parsed once you would have to store in
memory every iteration of the changes in the reflected rays in
the scene. I would think you would also increase the initial
parsing time to an uncomfortable level to do the calculations
for each iteration.. Maybe for one object against a black
background this penalty wouldn't be too high but what if you
had several objects moving down a mirrored hallway with 12
colored lights bouncing off of the objects and the walls of the
hall ? I shudder to think of the wait.
Just my thoughts on the subject.

Ken Tyler

Post a reply to this message

On Fri, 20 Nov 1998 00:12:41 +0100, Lukee <luk### [at] altavistanet> wrote:
>#declare a_cross = union {
>			cylinder { <-1.5,0,0>, <1.5,0,0>, 0.3}
>			cylinder { <0,1.5,0>, <0,-1.5,0>, 0.3}
>		   }	
>
>#macro DrawCross (rot,trans, colr)
>	object {a_cross
>		texture {pigment {color rgb colr}}
>		rotate rot translate trans 
>	}
>#end
>
>#declare cycles=0;
>
>
>#while (cycles<36)
>	DrawCross(<0,cycles*10,0>,<0,0,0>,<0,.8,.2>)
>	#declare cycles=cycles+1;
>	render <sort of a numbered-filename>//<- THIS IS THE NEW DIRECTIVE!
>#end

Please explain how POV knows to get rid of the old 'cross' object while 
keeping the objects that were created outside the loop, such as the 
camera.  That is, let's assume that you've made this new directive so 
it renders the frame as it exists at the time you told it to render.
The first call will then render the cross in the initial position. The
second call will render TWO crosses, one in the initial position and 
one in the second position. By the 36th call, you'll have 36 crosses
(though it'll look like 9).

I do think it'd be nice if you could dump the entire contents of the 
symbol table (essentially, the 'state' of the script, but not including 
the frame) to a file for later resurrection, though.  Then you could 
do this:

----------------------------------------
#fopen File "filename" read
#ifdef (File)
  #readstate File
  #fclose File
#end

#ifndef (SavedStep)
   /* Initialize all variables to their start values */ 
   #declare MySphere=sphere{0,1 pigment {color red 1}}
   #declare SavedStep=1;
#else
   /* Adjust all variables as necessary */
   #declare MySphere=object{MySphere translate clock_delta*x}
   #declare SavedStep=SavedStep+1;
#end

#fopen File "filename" write
#ifdef (File)
  #writestate File
  #fclose File
#end

camera {location -4*z look_at 0}
light_source { <-4,4,-4> rgb 1 }
object {MySphere}
----------------------------------------

I am of course opposed to the idea of persistent variables on principle, 
due to the way they muck up scalability, but if you're gonna use them, 
it would be nice to have an easy way to just make all variables - 
including the entire state of objects and textures - be persistent.

Post a reply to this message

On the other hand, if your scene script contais some kind of iterative process
or - worse yet - some kind of a physics model (for ex. balls bouncing around),
it is a real pain to have the entire scene processed for every frame. The
calculations would have to go from the beginnig to current state every frame and
the parse time would increase each time.
This can often be handled with I/O functions, of course; but POV's I/O functions
are (with all due respect) a bit cumbersome (for example having to #read all the
identifiers in a file when you only need the last one for a particular frame or
having to manually comma-delimit the list).

Margus

Ken wrote:
> 
> Which makes a lot of sense memory wise. If you have a 200
> frame animation and parsed once you would have to store in
> memory every iteration of the changes in the reflected rays in
> the scene. I would think you would also increase the initial
> parsing time to an uncomfortable level to do the calculations
> for each iteration.. Maybe for one object against a black
> background this penalty wouldn't be too high but what if you
> had several objects moving down a mirrored hallway with 12
> colored lights bouncing off of the objects and the walls of the
> hall ? I shudder to think of the wait.
> Just my thoughts on the subject.
> 
> Ken Tyler

Post a reply to this message

Lukee wrote:
> 
> Please tell me your opinion!
> 
> Luca Rivelli <luk### [at] usanet>

You can effect something similar through the use of arrays, file io and
includes. And using a pre animation ini/pov script to pre-compute your
frames (with display/output turned off):

	display=0
	Output_to_File=0

It of course would be nice to be able to save state of all objects with
one command, but with a little work you can create a newtonian based
physics script complete with collision, etc detection. I had did
something primative along those lines for a space battle with klingon
warships. 

Personally I think a render statement would make frame-based rendering a
little too complex. At least for animations involving many objects.

-- 
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usitnet (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.intrafoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html

You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)

"The comedy is over" -i pagliacci

Post a reply to this message

Rainer Mager wrote:
> 
> Hi all,
> 
>     There are a number of features this could be added once the base stuff
> is in place. Stuff like easy object collision routines, physics stuff
> (gravity, friction, etc), and just about anything you could think of. For
> now I'm sticking with the basics but we'll see how it goes.

Well... I will agree that pov needs at least three things: 

1) ability to determine the bounds of any complex object (esp. text
objects) which would be useful for collision detection.

2)ability to read heightfields data like a 2d array (so random tree and
rock objects, for example, sit ON the ground and not 10 ft under. :)

3)and the addition of translate_path, rotate_path and scale_path, which
are curve-based animation functions (operating similiar to say
color_map) using the 0 to 1 of the clock variable. Operating on all
objects including camera.

But otherwise, I'm more or less happy. Except for the speed of course.
:)

-- 
Lewis A. Sellers: writer and contract Multimedia Website Developer
mailto:lse### [at] usitnet (The Fourth Millennium Foundation)
http://www.public.usit.net/lsellers/ & http://www.intrafoundation.com
http://brain-of-pooh.tech-soft.com/users/critters/bios/sellers_lewis.html

You can bug the living bejesus out of me live on ICQ @ 491461
(If I don't get back to you within a month, I'm out of prozac in some
dark corner somewhere screaming things quite unintelligable but -- most
curiously -- thick with a sumerian accent.)

"The comedy is over" -i pagliacci

Post a reply to this message

On Fri, 20 Nov 1998 13:09:34 -0500, Lewis Sellers <lse### [at] usitnet> wrote:
>1) ability to determine the bounds of any complex object (esp. text
>objects) which would be useful for collision detection.

What do you mean by bounds?  Do you want to find the surface of the object,
or the bounding box?  My contributions to the superpatch allow you to 
trace arbitrary rays (thus allowing you to at least sample the surface of
the object) and to compute the bounding box.

>2)ability to read heightfields data like a 2d array (so random tree and
>rock objects, for example, sit ON the ground and not 10 ft under. :)

Since you can sample the surface of an object, you can easily determine
the elevation of a heightfield at any given point, as well as the slope.

>3)and the addition of translate_path, rotate_path and scale_path, which
>are curve-based animation functions (operating similiar to say
>color_map) using the 0 to 1 of the clock variable. Operating on all
>objects including camera.

Please explain this in more detail.  Specifically, what syntax should this
have?  Also, I'm having trouble determining how scale can be correlated 
with a path.  If all you're looking for is a convenient way to generate a 
spline through a series of points or scalar values, this too is in the 
superpatch (though I didn't write that patch) or available as an include
file from Chris Colefax's page.

Granted, none of these things are yet in the official version (well, the
include file is) but anything could happen.  The superpatch is at 
http://twysted.net/patchstation and I hope to have a new version with 
the new 3.1 windows editor, as well as a Linux and maybe a DOS port, 
online very soon.
s

Post a reply to this message