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