|
 |
On 11/26/2013 12:16 PM, James Holsenback wrote:
> On 11/26/2013 11:32 AM, clipka wrote:
>> Am 26.11.2013 16:50, schrieb James Holsenback:
>>> On 11/26/2013 07:42 AM, clipka wrote:
>>>> Am 26.11.2013 04:33, schrieb James Holsenback:
>>>>
>>>>>> This must be something deep in the bowels of the POVMS
>>>>>> message-passing
>>>>>> code; can you try the following - in source/base/povmscpp.cpp,
>>>>>> replace
>>>>>> all
>>>>>>
>>>>>> throw POV_EXCEPTION_CODE(pov_base::kFileDataErr)
>>>>>>
>>>>>> with
>>>>>>
>>>>>> throw POV_EXCEPTION_CODE(pov_base::kFileDataErr, "FUBAR: ###")
>>>>>
>>>>> error: macro "POV_EXCEPTION_CODE" passed 2 arguments, but takes just 1
>>>>
>>>> My bad - that should have been:
>>>>
>>>> throw POV_EXCEPTION(pov_base::kFileDataErr, "FUBAR: ###")
>>>>
>>>
>>> This run got a little farther .... used +am3 aa depth +r5
>>>
>>> Rendered 553984 of 705600 pixels (78%)
>>> Belch: 1494
>>
>> Still doesn't make much sense to me. Mind e-mailing the complete scene +
>> all render settings? (See the dev newsgroup for my e-mail address).
>>
>
> a little bit too big to email ~15MB, so I put it on my wiki testbed ...
> see your email for the link
another thought ... might be worth it to have a quick look at latest
Coverity scan results. I've not looked so your mileage may vary
Post a reply to this message
|
|
|
|
Am 26.11.2013 18:31, schrieb clipka:
> Am 26.11.2013 18:16, schrieb James Holsenback:
>>>
>>> Still doesn't make much sense to me. Mind e-mailing the complete scene +
>>> all render settings? (See the dev newsgroup for my e-mail address).
>>>
>>
>> a little bit too big to email ~15MB, so I put it on my wiki testbed ...
>> see your email for the link
>
> Thanks, but I guess I've nailed down the culprit already - after
> accidently getting my Windows system into swap hell by "nothing more"
> than cranking up the AA mode 3 quality settings (something like +am3
> +ac0.999 +a0.001 +r9). The quality settings shouldn't have any effect on
> the memory consumption during AA mode 3, but obviously they do.
>
> That was the clue I needed. Turned out to be a stupid bug, actually.
BTW, the render abort you experience is probably due to an excessively
large chunk of memory being passed from one of the render threads to the
front end.
Post a reply to this message
|
|
