![](/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) |
I have found something _really_ strange with MegaPov 0.4:
I made a test scene that uses two large mesh objects (or, more
precisely: bicubic_patch objects exported from sPatch). These two
objects take long time to parse, and thus would be very effective to
#declare at the start of an animation to eliminate the need to parse the
files containing the objects at subsequent frames.
When using labels & persistent variables, MegaPov renders 11(!) times
slower - here are the render time stats when not using persistent
variables:
Time For Trace/Frame: 0 hours 0 minutes 6.5 seconds (6 seconds)
...and here the render time stats when using persistent variables:
Time For Trace/Frame: 0 hours 1 minutes 9.0 seconds (69 seconds)
I'm not kidding here - it is _that_ much slower. My only question is:
why? (Note: I'm new to MegaPov - so please forgive me if this is a well
known bug/feature)
----------------------------------------------------
Mikael Carneholm
Dep. of Computer Science and Business Administration
Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] ida utb hb se
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) |
Maybe try watching the object count in your scene frame by frame... I've
had
some slowdowns because I've mistakedly left copies of previous objects in
later frames. By the end of the animation you could have several hundred
copies of the objects on top of one another.
You can just put #if statements around it to only put the objects in the
first frame. If this is not the problem with your scene, I have no idea
what is causing the slowdown.
Andrew C
Mikael Carneholm wrote:
> I have found something _really_ strange with MegaPov 0.4:
>
> I made a test scene that uses two large mesh objects (or, more
> precisely: bicubic_patch objects exported from sPatch). These two
> objects take long time to parse, and thus would be very effective to
> #declare at the start of an animation to eliminate the need to parse th
e
> files containing the objects at subsequent frames.
>
> When using labels & persistent variables, MegaPov renders 11(!) times
> slower - here are the render time stats when not using persistent
> variables:
>
> Time For Trace/Frame: 0 hours 0 minutes 6.5 seconds (6 seconds)
>
> ...and here the render time stats when using persistent variables:
>
> Time For Trace/Frame: 0 hours 1 minutes 9.0 seconds (69 seconds)
>
> I'm not kidding here - it is _that_ much slower. My only question is:
> why? (Note: I'm new to MegaPov - so please forgive me if this is a well
> known bug/feature)
>
> ----------------------------------------------------
> Mikael Carneholm
> Dep. of Computer Science and Business Administration
>
> Personal homepage:
> http://www.studenter.hb.se/~arch
> E-mail:
> sa9### [at] ida utb hb se
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) |
It turns out I had misunderstood the documentation, mixing up persistence of
variables with persistence of scenes and ending up with having both labeled
objects AND the normal objects "pointed to" by their variable names (thus the
huge difference in rendering time).
This was the code:
#ifndef(Body)
#include "D:\Pov\Cessna\Body.inc" // #declares Body=union{bicubic_patch[1..n]
}
#end
#ifndef(Wheelcaps)
#include "D:\Pov\Cessna\Wheelcaps.inc" // #declares
Wheelcaps=union{bicubic_patch[1..n] }
#end
#if(1) // persistent variables yes/no
union{
object{Body}
object{Wheelcaps}
rotate y*clock*360
}
#else
union{
object{Body}
object{Wheelscaps}
label TestObject
}
modify{
TestObject
rotate y*clock*360
}
#end
Reading the docs again it's clear that all that's needed to make the variables
persistent is to turn Persistent_Animation on - yesterday I got the impression
that you also had to label the objects.
Sorry for that.
- Mikael.
----------------------------------------------------
Mikael Carneholm
Dep. of Computer Science and Business Administration
Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] ida utb hb se
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) |
Mikael Carneholm <sa9### [at] ida utb hb se> wrote...
> Reading the docs again it's clear that all that's needed to make the
variables
> persistent is to turn Persistent_Animation on - yesterday I got the
impression
> that you also had to label the objects.
If you label objects, they stay in the scene after the render is completed.
There has been a bit of confusion about this already, so if anyone has
anybody would like to improve the documentation to help clarify how this
works, please do so and email the changes to me.
-Nathan
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |