I'm working on a project where I have a spacecraft modeled in inches, and
I'm putting it in a world scene (earth, sun, moon) that I have modeled in
kilometers.

So I scale my craft into kilometers with "scale .0000254".  Yikes, yes,
thats awful small. And many of the vertices have coordinates that small to
begin with. (So I do end up with a lot of degenerate triangles).

The problem is, when I scale that small, my renders go so slow they're
unusable.  When rendered in its native units (inches), a typical image
renders in about 40 minutes. Whereas when I scale it into kilometers, that
same image...well...it rendered for 17 hours until I killed it because it
wasnt even halfway done.

Whats the issue here?  What is MOST confusing, is on the last project, with
a very similar model file that was modeled in milimeters, I did a similar
scaling only MORE extreme (scale .000001), and that rendered fine!!  All on
the same machines with the same architecture (develop on Windows, render
animation frames on linux cluster, and yes the problem occurs on both
archs).

So, why does such a scale drop rendering to a crawl, and why did it NOT do
that when I was scaling with .000001 on the other project?

Yes, I can look into 64-bit archs, look into work arounds, find a happy
medium unit to work in, etc.  But I want to understand more clearly how
performance is being affected by this.

Any input?  Thanks in advance.

Post a reply to this message

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?

Try using another model in its place.  Try using other geometry (a 
simple sphere, for intstance).  Try turning off its texture.  See if 
anything else has an effect on the speed.

Try creating a cloned copy of the model, but with the scaling 
pre-applied, and using that model (so there would be no scaling in 
POV-Ray) and see if that changes things.

Other than that, I have no idea what to say :o

...Chambers

Post a reply to this message

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. I reduced the
scene to just one piece of the offensive geometry (which does not have
textures), and one light. It should have rendered in 5 minutes based on
previous performance, but still hung forever when scaled. Highly
suggestive, but not conclusive.

However, I launched a major render for over the holiday weekend on Friday,
with the native scaling presuming it was ok, but the performance I saw
before leaving suggested maybe the problem wasnt eliminated. I'll see
tuesday morning when I arrive at work.

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 initially thought my current problem was the same situation, until I honed
in on the scale issue. So these situations may or may not be related.

I was hoping and praying this would sound familiar to someone. I still never
figured out what the issue was on the last project, that alone still gnaws
at me. If this current situation doesnt get resolved, I got some real
trouble.

Of course, I've looked at all command line options as well, and the problem
happens on two different architectures. Someone suggested perhaps one of my
files didnt have an 'end of line' character at the end and maybe thats
causing some problems. I investigated that, to no avail, however thats the
sort of thing that I'm hoping to hear, since its separate from the graphics
issues that I've explored to death.

On the first project, it actually looked like something was getting trapped
in recursion. As if something was calling itself, and it kept recursing
until some maximum recursion depth was hit.(but i had no macros or user
defined functions. and my file includes checked out ok) Thats the only sort
of thing
that could explain what I was seeing, because the code itself just didnt.

Other ideas is that maybe something is causing memory to flood and thrash,
and maybe very little cpu time is going to the actual raytracing.

Sure wish I could post the whole thing on here to prove I'm not insane or
stupid (at least not on these counts), but the geometry and texture files
are too large to distribute.

Sorry for the long windedness. This is really baffling.

Post a reply to this message

Well,

what you say sounds really strange. But it seems that you check your files
and setting many times.

So, for me, the cause for your problem cannot be related directly to Povray
rendering. Did you check your PC configuration, the processes running,
memory consumption, even priority setting?

Poor help, but I think that you should look in a new direction.

Pascal.

Post a reply to this message

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