|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/14/2015 2:56 AM, scott wrote:
> On 13/08/2015 18:39, Mike Horvath wrote:
>> On 8/13/2015 10:21 AM, scott wrote:
>>>> The Lego town I am working on takes a lot of RAM when you turn the
>>>> little top studs on.
>>>
>>> How many top studs do you have in total? You might be able to get away
>>> with only turning them on for the visible ones in the foreground. Once
>>> the studs get to be less than a couple of pixels big you probably won't
>>> notice that they're gone (especially with a little bit of focal blur).
>>>
>>
>> It's an orthographic render, so all studs are the same size everywhere.
>
> How many in total?
>
Over two million.
I forgot to add the important fact that the studs are not the only
things being turned on/off. In fact, most of the internals of each part
such as the inner cavity and tubes are also being enabled/disabled.
So there's more going on than just the little studs.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.08.2015 um 06:38 schrieb Mike Horvath:
> On 8/14/2015 11:44 PM, clipka wrote:
>> What would you want with such a log on disk? All it'll tell you is that
>> the system went bonkers at X bytes of memory usage - but I don't need a
>> log to tell you that X = your physical memory size.
>>
>
> Oh, I thought POV-Ray uses virtual memory when physical memory runs out.
> Never mind then.
Well, /unfortunately/ it does.
POV-Ray is a rather special beast with regards to system performance
requirements. In contrast to most applications it really needs to access
much of its data pretty frequently, and its render tasks don't do any
file i/o at all, so it keeps the operating system busy juggling virtual
memory back and forth.
With that in mind, I wonder whether /reducing/ the number of render
threads might help keep the system somewhat stable in such a situation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/15/2015 1:00 AM, clipka wrote:
> Well, /unfortunately/ it does.
>
> POV-Ray is a rather special beast with regards to system performance
> requirements. In contrast to most applications it really needs to access
> much of its data pretty frequently, and its render tasks don't do any
> file i/o at all, so it keeps the operating system busy juggling virtual
> memory back and forth.
>
>
> With that in mind, I wonder whether /reducing/ the number of render
> threads might help keep the system somewhat stable in such a situation.
>
I would be willing to sacrifice render speed for stability. In my case
the parsing is what uses all the resources, and rendering only takes a
few minutes even at 8192x8192px. As an option of course.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.08.2015 um 19:54 schrieb Mike Horvath:
> On 8/15/2015 1:00 AM, clipka wrote:
>> Well, /unfortunately/ it does.
>>
>> POV-Ray is a rather special beast with regards to system performance
>> requirements. In contrast to most applications it really needs to access
>> much of its data pretty frequently, and its render tasks don't do any
>> file i/o at all, so it keeps the operating system busy juggling virtual
>> memory back and forth.
>>
>>
>> With that in mind, I wonder whether /reducing/ the number of render
>> threads might help keep the system somewhat stable in such a situation.
>>
>
> I would be willing to sacrifice render speed for stability. In my case
> the parsing is what uses all the resources, and rendering only takes a
> few minutes even at 8192x8192px. As an option of course.
In that case use only one single render thread ("+wt1").
Also, if you're using radiosity, that is also something that eats up
memory that you might get away without, if you use UberPOV and its
"no_cache" radiosity option; if you use this, UberPOV will not store
/any/ radiosity-related data, which obviously increases render time but
saves a lot of memory (plus it also trades various types of artifacts
for random noise, wich can be reduced easily by simply throwing more
render time at it in "+am3" mode).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/16/2015 3:47 AM, clipka wrote:
> Am 15.08.2015 um 19:54 schrieb Mike Horvath:
>> I would be willing to sacrifice render speed for stability. In my case
>> the parsing is what uses all the resources, and rendering only takes a
>> few minutes even at 8192x8192px. As an option of course.
>
> In that case use only one single render thread ("+wt1").
>
I turned on the +wt1 switch and the render crashed outright. I uploaded
the dump to wherever they get sent to.
>
> Also, if you're using radiosity, that is also something that eats up
> memory that you might get away without, if you use UberPOV and its
> "no_cache" radiosity option; if you use this, UberPOV will not store
> /any/ radiosity-related data, which obviously increases render time but
> saves a lot of memory (plus it also trades various types of artifacts
> for random noise, wich can be reduced easily by simply throwing more
> render time at it in "+am3" mode).
>
Radiosity is turned off.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|