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

Margus Ramst wrote:
> 
> 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

The easiest thing to do is to create .inc file(s) that declare all the
variables of your current frame (and init on clock = 0.0). That way you
can read in all variables, etc with a simple #include "physics.inc" etc.

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

Lukee wrote:
> 
> 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>


Since we're talking about 'cool stuff for v4' I've got another.
Auto-continuation. It'll be nice to set an .ini that's going to be
rendering a couple hundred frames over the next week or so :) to
automatically continue whenever povray is started up. (In particular, if
I've put it in the win nt tray, so that come power-outs, or BSOD's
povray will keep on going.)

Adding a render priority option to the .ini would be useful as well:

	render_priority=lower

etc...


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

Ron Parker wrote:
> 
> 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.

Big box around the object would do. :) Although for more complicated
objects (blobs etc) I assume you'd need to do some raytracing. The
superpatch is... the one at twysted.net I assume? Not tried that yet,
though I've heard of it.

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

You can? (Min scratches his head.) Oh, you mean the superpatch can?
Hmm...
 
> >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.

Well, basically it's something I mentioned a while back. Let me see if I
can remember how it went.....

ok. Assume we have an object called my1ststarship that normally faces to
position Z and is otherwise centered. Assume also we're using an .ini
that runs 60 frames from clock 0 to 1. The .pov animation code is:

object {
	my1ststarship

	translate_path {
		[0 <0,0,0>]
		[.5 <0,0,10>]
		[1 <10,10,10>]
		cubic_spline
	}

	rotate_path {
		[0 <0,0,0>]
		[.5 <0,45,45>]
		[1 <0,90,45>]
		cubic_spline
	}
}


Should be fairly obvious to you what it'll to. The ship starts at
0,0,0.  Halfway through (.5 clock) it's at 0,0,10. By 1 it's at
10,10,10. Works the same for the rotate. It would have some of the
flavouring of lathe and map objects in that the points in between would
be interpolated, etc. As you already noticed. Of course there would need
to be additional control points specified but I didn't want to muck up
the issue. :)

My math skills are not sufficent to do make the changes myself so I
never go too far in an attempt to patch my own copy of povray.

Not sure what the point of scale_path would be except that it would be
appropriate to include it for asthetic reasons. I'm sure someone would
think of a reason. :) Since it can be applied to the camera some other
attribs of the camera relating to angles, focal blur etc might also need
a _path.
 

> 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

Ah. That's what I thought you were talking about. Min moosy's on over
and order's a drink.... 

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

Hi all,

    I'd like to clarify a few things I wrote.

    First off, I think, at the stage POV's current language is in, almost
anything can be done in the POV language that could be done in any other
language. Given this, I don't think the issue is that POV can or can't do
something, I think the issue is that certain things could be done much
easier (and perhaps much faster) in other languages.
    I think the biggest example of this is that the POV language does not
allow for the creation of very robust libraries. Whether they are libraries
of objects or animation utilities or whatever. If there was a way to create
and use well-defined and well-tested libraries then I think this would
greatly aid in many people creating scenes and animations.
    What I mentioned briefly in my original post was one such library,
physics related animation things. The ability to have a function to compare
objects and check of overlap would be very useful. Although this is possible
now by keeping careful track of where an object is and what size it is and
how it is scaled and running that through a formula for that type of object
and comparing that to other objects, this is very unwieldy.
    Likewise the ability to easily apply movement to all (or a set) of
objects in a scene, for example, make every object in the scene "fall" (as
in a gravity field) for 0.2 seconds given such-and-such a gravity constant
would be very useful. Again, this is possible in the POV language but it is
not easy and it is very difficult to make a library such that arbitrary
objects can use this function.

    Second, the main purpose of my Perl module is to put a frame around the
POV language that is more robust that the current language. I think Perl can
do this. Again, I'm not claiming this is the be-all-end-all solution but I
think it can be implemented fairly quickly and in reasonable stages such
that a useable (if not complete) version is available soon.
    I'm hoping that this frame is able to allow the libraries I mentioned
above and other features that people come up with. At the same time I
realize that learning and using a new language (Perl) is difficult for many
people. I suggest that, unless you are quite adventurous, you don't use this
module until it is well tested and has some libraries available that make it
more attractive.

    Third, I also briefly mentioned in my post the desire to have POV parse
a binary language instead of the POV language. My main desire for this
feature is this. I think that this could be done much more quickly and
perhaps more memory efficiently that the current parsing method. I also this
that this would allow the POV team to concentrate more on the graphics
aspects of POV Ray and leave the language aspects to whoever wishes to
contribute to them.
    Probably the POV team should have one "official" POV compiler that takes
the current POV language and converts it to the binary language. At the same
time, if someone, such and myself, feels that they can contribute by making
a different language, a well-defined binary language would encourage this.


    Anyway, since my Perl module isn't done yet and hasn't been used to make
any real scenes yet, I can't yet say if I feel it is really an advantage
over vanilla POV. Hopefully it will be so but I don't know yet. I'll keep
you all posted.


--Rainer

Post a reply to this message

[sniiiiiip]

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

I agree with you that the .INI files is limiting the language a lot. I mainly
use POVRay for producing graphics to my other hobby - game programming - and it
seems to me to be a shame that you, for instance, can't specify the
output-filename with the language directly. You could of course use batchfiles
and that sort of things, but it would IMHO be nicer if it was possible to
directly use the extreme flexible power that the language provides.

It would be really nice if it was possible to get rid of those .INI files. :-)

Just my two ears...

PS. Yes, I know how to use the commandline!
--
- Ole Laursen - Aalborghus Gymnasium - 98z### [at] aalborghusdk -
Remember, no questions are stupid - some are just easier to answer than others
;-)

Post a reply to this message