![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
You might notice that renders (and parses) tend to be quicker when run
the second time. This of course might be OS platform dependant and
such, don't know. Possibly it's only because of memory use
effieciency of the OS and nothing to do with POV-Ray itself.
Bob
Sander <san### [at] the-inter net> wrote in message
news:37e1573d@news.povray.org...
> But what when you render exactly the same scene at a different
resolution?
> Then it seems a pity that you have to render again.....
>
> Sander
>
> Bob Hughes <inv### [at] aol com> schreef in berichtnieuws
> 37e143e8@news.povray.org...
> > I'm not totally inner workings savy, but yes, from what I
understand
> > the visible scene is calculated so the other stuff can be dropped
out.
> > That makes for a change in parse I believe even when just
viewpoint
> > changes.
> >
> > Bob
> >
>
>
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
But skipping the parsing step would also remove the need for all of this
memory shuffling. Once you've got a scene parsed and allocated in memory,
it would be nice to render scenes of an animation by simply changing what's
already in memory instead of destroying it all and rebuilding it for each
frame.
And, while it wouldn't make much difference for scenes with lots of glass or
media, it could be a noticable speed improvement for other scenes, such as
ones with lots of triangles or ones built using extreme recursion (which POV
is slow at parsing).
And, granted, all those light buffers, vista buffers, and the like would
have to be re-computed each time, but I still think it is something that
would benefit POV.
-Nathan
Ron Parker <par### [at] fwi com> wrote
> The reason that was given the last time this came up was that profiling
> shows that most of the time parsing is actually spent allocating and
> shuffling memory around. Of course this isn't true for all scenes, but
> that's what "they" said.
>
> Now that I have access to a copy of vTune for Windows, maybe I'll find
> a big scene to parse and see for myself.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Thu, 16 Sep 1999 23:27:41 -0400, "Nathan Kopp" <Nat### [at] Kopp com>
wrote:
>But skipping the parsing step would also remove the need for all of this
>memory shuffling. Once you've got a scene parsed and allocated in memory,
>it would be nice to render scenes of an animation by simply changing what's
>already in memory instead of destroying it all and rebuilding it for each
>frame.
I agree, in the animation case. I've long thought about how to modify
POV so it only parses the static parts of a scene once. It would
definitely be nice if you could somehow say "The whole scene is
static, so only reparse the camera definition for each frame."
Of course, even that would be difficult to achieve if you're using any
kind of complex camera motion, such as Colefax's splines.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Nieminen Juha
Subject: Re: Any way to avoid repeated parsing?
Date: 17 Sep 1999 03:13:21
Message: <37e1ea11@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bob Hughes <inv### [at] aol com> wrote:
: I'm not totally inner workings savy, but yes, from what I understand
: the visible scene is calculated so the other stuff can be dropped out.
You can't do that. You have no way to know if an object will be visible
through reflection/refraction (other than actually raytracing the scene).
If an object was not hit by any ray in the previous frame, you have no way
to know if it will be hit or not in the current frame.
Automatically declaring objects as "static" depending on whether the clock
value affects them or not is a mathematically impossible problem (AFAIK).
You can always write a program which is not analytically solvable.
Numerical solving would be at least as slow as the actual parsing of the
scene, so no benefits would be achieved.
You can only be sure that an object is not affected by the clock value
when it doesn't use any identifier which has been "touched" by 'clock'
(or other identifiers which have been "touched", etc). The same thing for
'clock_delta'.
This is not enought, though. An object may depend on the clock value even
if it doesn't use any identifier. For example:
#if(clock<.5) sphere { 0,1 pigment { rgb 1 } } #end
But even this is not enough. The object may depend on the contents of an
external file (which is #read during parsing and which may change from
frame to frame).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> I agree, in the animation case. I've long thought about how to modify
> POV so it only parses the static parts of a scene once. It would
> definitely be nice if you could somehow say "The whole scene is
> static, so only reparse the camera definition for each frame."
>
> Of course, even that would be difficult to achieve if you're using any
> kind of complex camera motion, such as Colefax's splines.
That sounds feasable to me, provided that special case is made. You know how
POV-Ray allows one atmospheric media? Maybe you could allow one static {}
block...
I guess the problem is when does POV release the stuff that is in
memory...unless you went so far as to add a keyword to tell it to do so. Like
#if (clock = 100) clear_memory
Seems to me that things could get messy though. Until recently there were all
those global variables that weren't getting cleared (I wouldn't doubt there are
still some). Now that I think about, that kinda' shows how it could be done -
since POV in the windows version is running from the time you start it, then if
the parsed scene wasn't freed it would be used the next time you
render...assuming you didn't try writing stuff to the same areas in memory.
I really don't know enough about how it manages memory or parses or...just about
everything, so I guess I'm not one to talk.
-Mike
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
John VanZwieten wrote:
>
> Is it necessary for POV-Ray to parse a file separately for each view of the
> same scene? Is there any way to "save" the result of the parsing to use in
> repeated raytracings from different views?
>
> Thanks in advance for any help with this.
>
> -John VanZwieten
Hi there,
my default insertion here, like some folks always say 'visit my links
page' I use to say the following:
I object to the statement that POV-Ray is slow in parsing. All that POV
is doing, is saying that it parsed some 1.5h, but most of the time it
did run your code.
It just doesn't tell you
'your $%*&ing codes runtime: 1.49Hrs
parsing time: 60 sec'
What do we have? By the grace of the POV-Ray Team we have one and only
one interface to the rendering engine, and thats the Scene Description
Language.
Like that name says, it's a language defined to describe a scene. It's
not designed to do heavy numerics or business-transactions.
Throughout it's history (which I experienced not so much of) it has been
extended by more and more programming constructs, giving the users more
and more possibilities. Thanx, guys.
But that stuff doesn't only have to be coded, but it has to be paid for.
And that's simply speed.
Short: the parser is fine, the interpreter is slow. That's fine, I do
prefer a good renderer to yet another interpreter.
Could someone speed it up? No, because there are way too many backdoors,
like pre- and postframe shellouts and #read, so one rarely knows, what
content changed at what time.
So, if you want to stick to portable and simple coding for the users,
you stick to the speed.
More speed would require a serious breaking of compatibility, and in my
opinion, another interface to the engine. POVLegal won't like it, and
most probably the POV-Ray Team won't code it.
(I think of something like a DOM-based CORBA interface)
A short remark on the binary format. It was implemented, but provided
the heterogeneous tree structure of the scene in memory, you have a lot
of work putting all those pointers back into place, and most objects
will be created one by one, so not that much of speedup to expect.
Axel
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 17 Sep 1999 03:13:21 -0400, Nieminen Juha wrote:
> You can only be sure that an object is not affected by the clock value
>when it doesn't use any identifier which has been "touched" by 'clock'
>(or other identifiers which have been "touched", etc). The same thing for
>'clock_delta'.
clock_delta is a constant for a given animation sequence, isn't it?
> This is not enought, though. An object may depend on the clock value even
>if it doesn't use any identifier. For example:
> #if(clock<.5) sphere { 0,1 pigment { rgb 1 } } #end
This can still be detected, of course. Anything that's inside an #if
block or a #while block that is dependent on clock is automatically
dependent on clock.
> But even this is not enough. The object may depend on the contents of an
>external file (which is #read during parsing and which may change from
>frame to frame).
e.g. by using a preframe shellout, or by writing it during the parse of the
current frame. And let's not forget #include files that are generated
automatically by either of those methods.
Obviously such scenes couldn't be rendered with "smart reparsing." It would
have to be an option, and probably not a default option. Alternatively, you
could have a way to explicitly mark objects as being fixed from frame to frame,
and anything that isn't so marked is automatically reparsed. This wouldn't
even take too much change to the parser.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ron Parker wrote:
>
> On Thu, 16 Sep 1999 23:27:41 -0400, "Nathan Kopp" <Nat### [at] Kopp com>
> wrote:
>
> >But skipping the parsing step would also remove the need for all of this
> >memory shuffling. Once you've got a scene parsed and allocated in memory,
> >it would be nice to render scenes of an animation by simply changing what's
> >already in memory instead of destroying it all and rebuilding it for each
> >frame.
>
> I agree, in the animation case. I've long thought about how to modify
> POV so it only parses the static parts of a scene once. It would
> definitely be nice if you could somehow say "The whole scene is
> static, so only reparse the camera definition for each frame."
I know about at least one such implementation (my own).
During a research project I implemented a parallel version
of POV-Ray (I call it POV||Ray) which used an incremental
parsing concept (see my note Xref: news.povray.org
povray.general:14892). My version went never public as the
implementation was somewhat experimental, based on some not
well supported components, some of the original POV-Ray
functionality would not be preserved, etc. (For instance,
animations based on a #clock variable would not work at all.)
Parsing was a tricky part of the implementation and I spent
some time on it. For a camera animation, the parsing times
dropped from 15 minutes to cca 3 seconds or less.
POV-Ray is not dependent on a particular interactive modeler,
therefore there is the pre- and post- processing overhead
that can be avoided if a raytracer is used within an
integrated environment. The right way lies perhaps in between
these two extremes.
My idea was/is making POV-Ray *persistent*. ;-)
I mean a termination upon request only. There could be an
interface which allows changing the scene which persists,
incremental adding of new objects, etc. The interface
could even be the same as up to now - an (incremental)
.pov file.
> Of course, even that would be difficult to achieve if you're using any
> kind of complex camera motion, such as Colefax's splines.
Not necessarily. However, I am afraid that some of the
backward compatibility would have to be given up (so if
you mean this, you are right). Many already existing tools
would thus become outdated (those which have something to
do with animations). But maybe even not.
A #clock variable would not be used by a preprocessor
anymore, at least not the way it is used now. However,
it could be used for generating an incremental .pov file
(or a script file or whatever the interface looks like).
Unless... unless there is a true 4D extension made to
POV-Ray. (Some extensions, like adding IDs to
objects/textures will be needed anyway.)
Mike wrote:
> That sounds feasable to me, provided that special case is made. You know how
> POV-Ray allows one atmospheric media? Maybe you could allow one static {}
> block...
I do not know how POV-Ray allows one atmospheric media,
but I think I know what you mean. It's probably the same
as in the case of camera, right?
> I guess the problem is when does POV release the stuff that is in
> memory...unless you went so far as to add a keyword to tell it to do so. Like
> #if (clock = 100) clear_memory
This can be done.
> Seems to me that things could get messy though. Until recently there were all
> those global variables that weren't getting cleared (I wouldn't doubt there are
> still some). Now that I think about, that kinda' shows how it could be done -
> since POV in the windows version is running from the time you start it, then if
> the parsed scene wasn't freed it would be used the next time you
> render...assuming you didn't try writing stuff to the same areas in memory.
Yes, I mean something like this. With one objection -
the solution should not be bound to windows.
> I really don't know enough about how it manages memory or parses or...just about
> everything, so I guess I'm not one to talk.
I know something about it. Feel free to ask me (a direct
msg or CC, please - I don't read news very regularly).
A final (useless) remark: If you (I guess you guys are
members of the POV-Team) decide to go the way I sketch
here, make a clear concept before making any quick
and dirty optimizations. As Mike said, things could get
messy...
Tom
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 17 Sep 1999 16:07:27 +0200, Tomas Plachetka wrote:
>A final (useless) remark: If you (I guess you guys are
>members of the POV-Team) decide to go the way I sketch
>here, make a clear concept before making any quick
>and dirty optimizations. As Mike said, things could get
>messy...
No, this thread is purely speculative and purely unofficial. Even if
some of us are members of the POV-Team, we're speaking completely
unofficially here. But I agree with your sentiment anyway; even an
unofficial patch should be well-thought-out ahead of time.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nieminen Juha wrote in message <37e1ea11@news.povray.org>...
>Bob Hughes <inv### [at] aol com> wrote:
>: I'm not totally inner workings savy, but yes, from what I understand
>: the visible scene is calculated so the other stuff can be dropped out.
>
> You can't do that. You have no way to know if an object will be visible
>through reflection/refraction (other than actually raytracing the scene).
>If an object was not hit by any ray in the previous frame, you have no way
>to know if it will be hit or not in the current frame.
> Automatically declaring objects as "static" depending on whether the
clock
>value affects them or not is a mathematically impossible problem (AFAIK).
>You can always write a program which is not analytically solvable.
>Numerical solving would be at least as slow as the actual parsing of the
>scene, so no benefits would be achieved.
> You can only be sure that an object is not affected by the clock value
>when it doesn't use any identifier which has been "touched" by 'clock'
>(or other identifiers which have been "touched", etc). The same thing for
>'clock_delta'.
> This is not enought, though. An object may depend on the clock value even
>if it doesn't use any identifier. For example:
> #if(clock<.5) sphere { 0,1 pigment { rgb 1 } } #end
>
> But even this is not enough. The object may depend on the contents of an
>external file (which is #read during parsing and which may change from
>frame to frame).
Add a 'static' object modifier to the language that can be applied to
anything, for example:
sphere{<0,0,0>, 1 pigment{ rgb 1} static}
POV-Ray will not reparse any object that contains that modifier after the
first frame of an animation. If you apply it to an object that does get
changed over the course of an animation, that's your problem, not POV's.
Mark
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |