Now with basic support for motion blur.

Source & Windows binary packages are available at:

https://github.com/UberPOV/UberPOV/releases/tag/v1.37.0.0-beta.2

Post a reply to this message

El 22/11/13 15:30, clipka escribió:
> Now with basic support for motion blur.

    I just started to try to apply reflection blur to my christmas
baubles... but found a problem even before starting:

    As a first test, I just changed the version directive and rendered it
with UberPOV, and the garland was missing. Checking my ugly code, I
found that trace() seems to not be working at all. The attached simple
scene shows the problem: on 3.7 you get some scattered spheres, as the
trace() call finds an intersection point with the plane, but on UberPOV
all the spheres get placed at <0,0,0>, as the intersection test seems to
fail (normal is also 0).

--
Jaime

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Am 24.11.2013 13:05, schrieb Jaime Vives Piqueres:
> El 22/11/13 15:30, clipka escribió:
>> Now with basic support for motion blur.
>
>     I just started to try to apply reflection blur to my christmas
> baubles... but found a problem even before starting:
>
>     As a first test, I just changed the version directive and rendered it
> with UberPOV, and the garland was missing. Checking my ugly code, I
> found that trace() seems to not be working at all. The attached simple
> scene shows the problem: on 3.7 you get some scattered spheres, as the
> trace() call finds an intersection point with the plane, but on UberPOV
> all the spheres get placed at <0,0,0>, as the intersection test seems to
> fail (normal is also 0).

I've already stumbled across - and fixed - this very bug myself 
yesterday :-)

In case you are using Linux, or have access to Visual Studio 2010, you 
may want to get the latest code from the "master" branch at 
https://github.com/UberPOV/UberPOV.

I would have rushed out a new beta already, but haven't found the time 
yet; it'll probably happen no sooner than tomorrow. Windows users might 
want to use the older beta.2 until then.

There is another bug in beta.2 that breaks SSLT; again, both beta.2 and 
the current master branch are fine.

Post a reply to this message

On 11/24/2013 08:02 AM, clipka wrote:
> There is another bug in beta.2 that breaks SSLT; again, both beta.2 and
> the current master branch are fine.

Hmmm ... just pulled and I'm getting:

In file included from /usr/include/boost/thread.hpp:24:0,
                  from ./backend/povray.h:53,
                  from ./backend/control/renderbackend.h:40,
                  from ./backend/control/messagefactory.h:39,
                  from backend/frame.h:65,
                  from lightgrp.cpp:35:
/usr/include/boost/thread/future.hpp:286:12: error: stray ‘\267’ in program
/usr/include/boost/thread/future.hpp:286:12: error: stray ‘\23’ in program
/usr/include/boost/thread/future.hpp: In static member function ‘static 
void 
boost::detail::future_traits<void>::cleanup(boost::detail::future_traits<void>::storage_type&)’:
/usr/include/boost/thread/future.hpp:286:19: error: ‘orage’ was not 
declared in this scope

I last built yesterday (23rd) early in the morning ... was fine then. I 
was not getting the results I was expecting from +am3, so after seeing 
Jamies post I decided to re-build.

Jim

Post a reply to this message

El 24/11/13 14:02, clipka escribió:
> I've already stumbled across - and fixed - this very bug myself
> yesterday :-)

   Surely, just moments after I downloaded it... :) ...will try again 
with the latest code, thanks.


--
Jaime

Post a reply to this message

Am 24.11.2013 15:36, schrieb James Holsenback:
> On 11/24/2013 08:02 AM, clipka wrote:
>> There is another bug in beta.2 that breaks SSLT; again, both beta.2 and
>> the current master branch are fine.
>
> Hmmm ... just pulled and I'm getting:
>
> In file included from /usr/include/boost/thread.hpp:24:0,
>                   from ./backend/povray.h:53,
>                   from ./backend/control/renderbackend.h:40,
>                   from ./backend/control/messagefactory.h:39,
>                   from backend/frame.h:65,
>                   from lightgrp.cpp:35:
> /usr/include/boost/thread/future.hpp:286:12: error: stray ‘\267’ in program
> /usr/include/boost/thread/future.hpp:286:12: error: stray ‘\23’ in program
> /usr/include/boost/thread/future.hpp: In static member function ‘static
> void
>
boost::detail::future_traits<void>::cleanup(boost::detail::future_traits<void>::storage_type&)’:
>
> /usr/include/boost/thread/future.hpp:286:19: error: ‘orage’ was not
> declared in this scope

According to the message, the file "future.hpp" - part of the boost 
library's dev package that apparently comes with your Linux distro - 
contains two non-ASCII characters among the program code. \267 (aka 
0xB7, or decimal 183) and \23 (aka 0x13, or decimal 19), are a centered 
dot ("MIDDLE DOT") and a non-printable character ("DEVICE CONTROL THREE" 
aka DC3), respectively.

The code you just pulled probably doesn't have anything to do with it; 
something must have garbled your libboost-dev package.

Post a reply to this message

On 11/24/2013 04:32 PM, clipka wrote:
> Am 24.11.2013 15:36, schrieb James Holsenback:
>> On 11/24/2013 08:02 AM, clipka wrote:
>>> There is another bug in beta.2 that breaks SSLT; again, both beta.2 and
>>> the current master branch are fine.
>>
>> Hmmm ... just pulled and I'm getting:
>>
>> In file included from /usr/include/boost/thread.hpp:24:0,
>>                   from ./backend/povray.h:53,
>>                   from ./backend/control/renderbackend.h:40,
>>                   from ./backend/control/messagefactory.h:39,
>>                   from backend/frame.h:65,
>>                   from lightgrp.cpp:35:
>> /usr/include/boost/thread/future.hpp:286:12: error: stray ‘\267’ in
>> program
>> /usr/include/boost/thread/future.hpp:286:12: error: stray ‘\23’ in
>> program
>> /usr/include/boost/thread/future.hpp: In static member function ‘static
>> void
>>
boost::detail::future_traits<void>::cleanup(boost::detail::future_traits<void>::storage_type&)’:
>>
>>
>> /usr/include/boost/thread/future.hpp:286:19: error: ‘orage’ was not
>> declared in this scope
>
> According to the message, the file "future.hpp" - part of the boost
> library's dev package that apparently comes with your Linux distro -
> contains two non-ASCII characters among the program code. \267 (aka
> 0xB7, or decimal 183) and \23 (aka 0x13, or decimal 19), are a centered
> dot ("MIDDLE DOT") and a non-printable character ("DEVICE CONTROL THREE"
> aka DC3), respectively.
>
> The code you just pulled probably doesn't have anything to do with it;
> something must have garbled your libboost-dev package.
>

Since I hadn't touched my end I didn't think it was the problem, but I 
refreshed my boost package and that was indeed the problem ... however a 
render I left running while at work (yesterday build) had an error when 
I got home to check:

Rendered 379904 of 705600 pixels (53%)
Cannot access data in file.
Rendered 380928 of 705600 pixels (53%)
Fatal error in renderer: Frontend halted render.

Dunno if it was related to the above problem ... just thought I'd 
mention it anyways

Post a reply to this message

On 11/24/2013 11:11 PM, James Holsenback wrote:
> Dunno if it was related to the above problem ... just thought I'd
> mention it anyways

sheesh ... should have realized my pull script was snagging the master 
/not/ beta branch ... that will teach me to try to throw something 
together quickly before i've checked things a bit more

Post a reply to this message

On 11/24/2013 11:11 PM, James Holsenback wrote:
> Rendered 379904 of 705600 pixels (53%)
> Cannot access data in file.
> Rendered 380928 of 705600 pixels (53%)
> Fatal error in renderer: Frontend halted render.
>
> Dunno if it was related to the above problem ... just thought I'd
> mention it anyways

decreased +am3 aa depth from +r6 to +r4 and abort went away ...

Post a reply to this message

Am 25.11.2013 21:14, schrieb James Holsenback:
> On 11/24/2013 11:11 PM, James Holsenback wrote:
>> Rendered 379904 of 705600 pixels (53%)
>> Cannot access data in file.
>> Rendered 380928 of 705600 pixels (53%)
>> Fatal error in renderer: Frontend halted render.
>>
>> Dunno if it was related to the above problem ... just thought I'd
>> mention it anyways
>
> decreased +am3 aa depth from +r6 to +r4 and abort went away ...

Strange one - can't make any sense of this yet.

Post a reply to this message

Am 25.11.2013 21:14, schrieb James Holsenback:
> On 11/24/2013 11:11 PM, James Holsenback wrote:
>> Rendered 379904 of 705600 pixels (53%)
>> Cannot access data in file.
>> Rendered 380928 of 705600 pixels (53%)
>> Fatal error in renderer: Frontend halted render.
>>
>> Dunno if it was related to the above problem ... just thought I'd
>> mention it anyways
>
> decreased +am3 aa depth from +r6 to +r4 and abort went away ...

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: ###")

where ### is different for each instance (ideally the line number), then 
compile & try again, and report which line claims the jackpot?


What are your system specs?

Post a reply to this message

On 11/25/2013 03:48 PM, clipka wrote:
> Am 25.11.2013 21:14, schrieb James Holsenback:
>> On 11/24/2013 11:11 PM, James Holsenback wrote:
>>> Rendered 379904 of 705600 pixels (53%)
>>> Cannot access data in file.
>>> Rendered 380928 of 705600 pixels (53%)
>>> Fatal error in renderer: Frontend halted render.
>>>
>>> Dunno if it was related to the above problem ... just thought I'd
>>> mention it anyways
>>
>> decreased +am3 aa depth from +r6 to +r4 and abort went away ...
>
> 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: ###")
>
> where ### is different for each instance (ideally the line number), then
> compile & try again, and report which line claims the jackpot?

I'll do that later this evening ...

>
> What are your system specs?
>

amd athlon x2 250 4gb ram

Post a reply to this message

Am 25.11.2013 22:52, schrieb James Holsenback:

>> What are your system specs?
>
> amd athlon x2 250 4gb ram

That's a 64 bit machine AFAIK; otherwise my first suspect would have 
been /some/ variable /somewhere/ with just 32 bit where 64 bit would 
have been required for whatever you're doing there.

Post a reply to this message

On 11/25/2013 03:48 PM, clipka wrote:
> Am 25.11.2013 21:14, schrieb James Holsenback:
>> On 11/24/2013 11:11 PM, James Holsenback wrote:
>>> Rendered 379904 of 705600 pixels (53%)
>>> Cannot access data in file.
>>> Rendered 380928 of 705600 pixels (53%)
>>> Fatal error in renderer: Frontend halted render.
>>>
>>> Dunno if it was related to the above problem ... just thought I'd
>>> mention it anyways
>>
>> decreased +am3 aa depth from +r6 to +r4 and abort went away ...
>
> 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

Post a reply to this message

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: ###")

Post a reply to this message

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
Rendered 555008 of 705600 pixels (78%)
Fatal error in renderer: Frontend halted render.
Render failed

btw: amd x2 250 is 32-bit dual core ... fwiw: 3.1.10-1.29-desktop kernel 
opensuse 12.1

Post a reply to this message

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
> Rendered 555008 of 705600 pixels (78%)
> Fatal error in renderer: Frontend halted render.
> Render failed
>
> btw: amd x2 250 is 32-bit dual core ... fwiw: 3.1.10-1.29-desktop kernel
> opensuse 12.1

Duh.. sure it's 32 bit? All I can find on the 'net says that it must be 
either an "AMD Athlon 64 x2", or an "AMD Athlon x2" - but the latter is 
a 64-bit thing, too. Even the notebook variant is.

Still, you're possibly running a 32-bit OS on it, so that brings integer 
size issues back on the list of suspects.

Post a reply to this message

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).

Post a reply to this message

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

Post a reply to this message

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.

Post a reply to this message

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

Am 25.11.2013 05:11, schrieb James Holsenback:

> Rendered 379904 of 705600 pixels (53%)
> Cannot access data in file.
> Rendered 380928 of 705600 pixels (53%)
> Fatal error in renderer: Frontend halted render.

You might want to try the newest version from the "master" branch; I'm 
quite sure it fixes your issue.

Post a reply to this message