space_cadet wrote:
> On my last project, I experienced something similar. All of the sudden my
> renders slowed to a crawl seemingly independent of any changes I made. So I
> undid my changes that supposedly invoked the slowdown. It didnt fix it. So I
> rolled back all changes to the point of the last known successful mass
> render. It didnt fix it. I was looking at two identical files, stroke for
> stroke. One rendered fine (the previous successful launch) and the other
> one crawled, even tho they were syntactically identical, character for
> character. Finally, I constructed a new file by copying and pasting the
> code from the problem file, line for line, into a new file buffer.  That
> fixed it. Even tho absolutely NO code changes were implemented. I then
> proceeded to implement all my mods that seemed to invoke the problem in the
> first place, and there was no appearance of the problem.
> 
> I hesitate to mention that, because it makes me look like an idiot. Any
> reader is surely convinced that I missed something in the file, as I would
> be if I were reading it from another poster. But thats not the case. I dont
> even know what I COULD put in a file to slow a render by orders of magnitude
> like that, let alone something that cant even be seen in a character by
> charcter comparison between two source files.

I'd say this sounds like a memory leak.  Try this: when you get to the 
slowdown, shut down POV-Ray and then restart it.  If that doesn't fix 
your problem, shut down your computer and restart it.  See if that 
effects anything - if so, then we're dealing with some type of memory leak.

However, its difficult to know whether the leak is in POV-Ray itself or 
in the OS, although you mentioned it happened on two different 
architectures.

...Chambers

PS You mentioned you're using a large geometry file - what size & type 
of file is it, and how much RAM do you have?

Post a reply to this message

I'm juggling my time between work arounds to meet some deadlines and trying
to get to the bottom of this.  I'll have to look into it deeper as time
permits, so I havent been able to explore all the helpful suggestions here
yet.

But one thing I'm seeing today is curious. I isolated one very small piece
of geomtery. Rendered it in native scaling, and it rendered in one second.
I scaled it by the .0000254 and it took 10 seconds to render (and I did
adjust the camera position so that the geometry covered the exact same
image portion.) I then scaled it to .254 and it rendered in 3 seconds.  The
slow down is porportional to the degree of scale, not just the scale itself.
Does that make ANY sense at all?

On a similar note, a light source I have was positioned at <-9500, 0, -9500>
and rendered fine.  But when moved to <-95000, 0 , -95000> * 3600, the
render hung, and I had to kill it.  Again, slowdown proportional to the
precision/magnitude of the values involved in the computation.

All this has been done on 32 bit architectures so far (linux and windows).
As of yesterday, I did a custom build on a 64-bit mega cluster. I've only
rendered my 'workarounds' on there so I havent learned anything yet, but
will shortly be playing with these issues in 64 bits to see if that sheds
any light.

I've just never seen this sort of thing before.

Post a reply to this message

space_cadet wrote:
> All this has been done on 32 bit architectures so far (linux and windows).
> As of yesterday, I did a custom build on a 64-bit mega cluster. I've only
> rendered my 'workarounds' on there so I havent learned anything yet, but
> will shortly be playing with these issues in 64 bits to see if that sheds
> any light.

The "64-bit" refer to the integer size, and have absolutely nothing to do
with the floating-point range. Your numbers are simply out of range to
generate meaningful results. Please read the FAQ:
<http://tag.povray.org/povQandT/misconceptions.html#simulatingsun>

	Thorsten

Post a reply to this message

space_cadet wrote:
> Ben Chambers <ben### [at] pacificwebguycom> wrote:
>> Are you *really* sure what the source of the slowdown is?  Have you
>> tried putting the model in the current scene, with its native scaling?
>> Or did you just render the model at its native scaling in another scene?
>>
> 
> No, I'm not *really* sure of the source of the slowdown.  However, when I
> render the scene with native scaling (simply comment out the "scale
> ...0000254") it renders, when I comment it back in, it crawls.

If your objects are way too big or small, they won't be included in the
bounding volumes. Hence, POV-ray has to to a lot more work *trying* to give
you want you want, even though the numbers you are using are out of any sane
range. You have to use sane numbers in your scene, there is no other "solution".

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> space_cadet wrote:
> > Ben Chambers <ben### [at] pacificwebguycom> wrote:
> >> Are you *really* sure what the source of the slowdown is?  Have you
> >> tried putting the model in the current scene, with its native scaling?
> >> Or did you just render the model at its native scaling in another scene?
> >>
> >
> > No, I'm not *really* sure of the source of the slowdown.  However, when I
> > render the scene with native scaling (simply comment out the "scale
> > ...0000254") it renders, when I comment it back in, it crawls.
>
> If your objects are way too big or small, they won't be included in the
> bounding volumes. Hence, POV-ray has to to a lot more work *trying* to give
> you want you want, even though the numbers you are using are out of any sane
> range. You have to use sane numbers in your scene, there is no other "solution".
>
>  Thorsten


What seems odd about your remarks here is that it suggests that the problem
is either present or not. Its either within bounding volumes and usable, or
out of bounding volumes and causes the problem, according to you. Whereas my
slow down is continous, proportional to magnitude, not 'in or out' as your
remarks would suggest.

I've seen the situation where I'm using numbers too big or too small. All
that happens is that I lose polygons, or they render in a bizarre way, not
some mysterious slowdown.

And again, I used this same scale, generating the same size numbers
previously without this problem. Thats what makes this so baffling and
suggests its not the numbers themselves.

As for 'sane' numbers, I'm using real world numbers to model real world
values, with these exact numbers and scales performing just fine in the
past, so I dont see how that is called a breech of sanity by any
perspective. I do, of course, appreciate the flattering remark, however.

Post a reply to this message

"space_cadet" <poc### [at] grcnasagov> wrote:
> What seems odd about your remarks here is that it suggests that the problem
> is either present or not. Its either within bounding volumes and usable, or
> out of bounding volumes and causes the problem, according to you. Whereas my
> slow down is continous, proportional to magnitude, not 'in or out' as your
> remarks would suggest.

Just wondering if you see this behaviour with antialiasing turned off?

Tom

Post a reply to this message

space_cadet wrote:
  > As for 'sane' numbers, I'm using real world numbers to model real world
> values...
Those would go from astronomicals to subatomics...


-- 
 From a certain point onward there is no longer any turning back.
That is the point that must be reached.
Franz Kafka

Post a reply to this message

space_cadet wrote:
> I'm juggling my time between work arounds to meet some deadlines and trying
> to get to the bottom of this.  I'll have to look into it deeper as time
> permits, so I havent been able to explore all the helpful suggestions here
> yet.
> 
> But one thing I'm seeing today is curious. I isolated one very small piece
> of geomtery. Rendered it in native scaling, and it rendered in one second.
> I scaled it by the .0000254 and it took 10 seconds to render (and I did
> adjust the camera position so that the geometry covered the exact same
> image portion.) I then scaled it to .254 and it rendered in 3 seconds.  The
> slow down is porportional to the degree of scale, not just the scale itself.
> Does that make ANY sense at all?
> 
> On a similar note, a light source I have was positioned at <-9500, 0, -9500>
> and rendered fine.  But when moved to <-95000, 0 , -95000> * 3600, the
> render hung, and I had to kill it.  Again, slowdown proportional to the
> precision/magnitude of the values involved in the computation.
> 
> All this has been done on 32 bit architectures so far (linux and windows).
> As of yesterday, I did a custom build on a 64-bit mega cluster. I've only
> rendered my 'workarounds' on there so I havent learned anything yet, but
> will shortly be playing with these issues in 64 bits to see if that sheds
> any light.
> 
> I've just never seen this sort of thing before.

Does the same problem occur with the 3.7 beta?

If so please post a small sample that demonstrates the problem and I will
investigate.

-- Chris

Post a reply to this message

Hugo <hug### [at] yahoocombr> wrote:
> space_cadet wrote:
>   > As for 'sane' numbers, I'm using real world numbers to model real world
> > values...
> Those would go from astronomicals to subatomics...

LOL, yes indeed.  However, my numbers werent that extreme.  I knew they were
aggressive, so I tried them with my fingers crossed, and they worked fine.
(until this problem surfaced much much later).

Actually, on first attempt, I scaled the spacecraft into kilometers (from
native milimeters) and positioned it at orbit altitude (in km).  Here is
where I saw many polygons disappearing from the spacecraft geometery,
although render speed was fine. So I reconfigured my scene such that the
craft stayed at the origin, and translated the earth away to the
appropriate distance, keeping all scales.  All was right with the world
from then on. (...until now)

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> >
> Does the same problem occur with the 3.7 beta?
>
> If so please post a small sample that demonstrates the problem and I will
> investigate.
>
> -- Chris

Ah, I wont have time to explore a whole new code base for some time yet. I'm
really very pressed with deadlines at the moment (I'm making do with usable
workarounds).  As time permits me to investigate more exhaustively, I'll
put this on the list and let you know.

Thanks for the suggestion.

Post a reply to this message