 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Copied the meshcam scene files into an alternate location and started
going through the baking demo ....
There were some warnings associated with not setting assumed_gamma
before calling/using rgb vectors, and warnings in light_source
definitions ... suspicious value after rgb. I fixed all those, and
submitted changes to revision control, but that didn't address the
unexpected results I'm seeing!!!
Has anyone else worked through the demo?
Post a reply to this message
Attachments:
Download 'baking_demo.png' (516 KB)
Preview of image 'baking_demo.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
James Holsenback <nom### [at] none com> wrote:
> Copied the meshcam scene files into an alternate location and started
> going through the baking demo ....
>
> There were some warnings associated with not setting assumed_gamma
> before calling/using rgb vectors, and warnings in light_source
> definitions ... suspicious value after rgb. I fixed all those, and
> submitted changes to revision control, but that didn't address the
> unexpected results I'm seeing!!!
>
> Has anyone else worked through the demo?
Just tried it on Windows version. It works fine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Copied the meshcam scene files into an alternate location and started
> going through the baking demo ....
>
> There were some warnings associated with not setting assumed_gamma
> before calling/using rgb vectors, and warnings in light_source
> definitions ... suspicious value after rgb. I fixed all those, and
> submitted changes to revision control, but that didn't address the
> unexpected results I'm seeing!!!
>
> Has anyone else worked through the demo?
Hmmm... everything seems to work fine here, both the bakind and the
rendering steps (using final 3.7 compiled from sources a few months
ago). BTW, it renders fine with Uberpov too...
--
jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/13/2014 03:08 PM, Jaime Vives Piqueres wrote:
>> Copied the meshcam scene files into an alternate location and started
>> going through the baking demo ....
>>
>> There were some warnings associated with not setting assumed_gamma
>> before calling/using rgb vectors, and warnings in light_source
>> definitions ... suspicious value after rgb. I fixed all those, and
>> submitted changes to revision control, but that didn't address the
>> unexpected results I'm seeing!!!
>>
>> Has anyone else worked through the demo?
>
> Hmmm... everything seems to work fine here, both the bakind and the
> rendering steps (using final 3.7 compiled from sources a few months
> ago). BTW, it renders fine with Uberpov too...
>
> --
> jaime
Thanks for the nudge ... I've been using uberpov-dev for a bit and that
works fine. Since povray is obviously busted on my system, I did a fresh
build from the perforce repository and that appears to be broken. Can
anyone with perforce access confirm? I did a fresh pull/build from the
povray github and that works fine. The plot thickens!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/02/2014 23:43, James Holsenback nous fit lire :
> Since povray is obviously busted on my system, I did a fresh build from
> the perforce repository and that appears to be broken. Can anyone with
> perforce access confirm?
Rebuilding (after getting latest revision of smp at 6194) (only make
clean, ./configure & make, not running prebuild.sh ) : compile & link
fine with:
./configure COMPILED_BY="Jérôme Grimbert <jgr### [at] freefr>"
--disable-io-restrictions LIBS="-lboost_system -lboost_thread"
BUT
./configure COMPILED_BY="Jérôme Grimbert <jgr### [at] freefr>"
--disable-io-restrictions LIBS="-lboost_system"
succeeds with configure, yet the final link fails.
> g++ -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3
-ffast-math -march=native -pthread -L/usr/lib -L/usr/lib -o povray disp_sdl.o
disp_text.o ../vfe/libvfe.a ../source/libpovray.a -lSDL -L/usr/lib/x86_64-linux-gnu
-lSDL -lSM -lICE -lX11 -lIlmImf -pthread -lIlmImf -lz -lImath -lHalf -lIex
-lIlmThread -lIlmThread -ltiff -ljpeg -lpng -lz -lrt -lm -lboost_system -pthread
> ../vfe/libvfe.a(vfesession.o): dans la fonction « vfe::vfeSession::Shutdown(bool)
»:
> vfesession.cpp:(.text+0xcd2): référence indéfinie vers «
boost::thread::native_handle() »
> vfesession.cpp:(.text+0xce7): référence indéfinie vers «
boost::thread::join_noexcept() »
> vfesession.cpp:(.text+0xcfb): référence indéfinie vers « boost::thread::detach()
»
> ../vfe/libvfe.a(vfesession.o): dans la fonction «
vfe::vfeSession::Initialize(vfe::vfeDestInfo*, vfe::vfeAuthInfo*) »:
> vfesession.cpp:(.text+0x314b): référence indéfinie vers « vtable for
boost::detail::thread_data_base »
> vfesession.cpp:(.text+0x3304): référence indéfinie vers «
boost::thread::start_thread_noexcept() »
> vfesession.cpp:(.text+0x3339): référence indéfinie vers «
boost::thread::native_handle() »
> vfesession.cpp:(.text+0x3352): référence indéfinie vers «
boost::thread::join_noexcept() »
> ../vfe/libvfe.a(vfesession.o): dans la fonction « vfe::vfeSession::Resume() »:
>
and so on (many pages). (sorry, compiler message is in French)
Test done on Ubuntu 13.10, 64 bits (x86_64)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/14/2014 12:18 PM, Le_Forgeron wrote:
> Le 13/02/2014 23:43, James Holsenback nous fit lire :
>> Since povray is obviously busted on my system, I did a fresh build from
>> the perforce repository and that appears to be broken. Can anyone with
>> perforce access confirm?
>
> Rebuilding (after getting latest revision of smp at 6194) (only make
> clean, ./configure & make, not running prebuild.sh ) : compile & link
> fine with:
>
> ./configure COMPILED_BY="Jérôme Grimbert <jgr### [at] freefr>"
> --disable-io-restrictions LIBS="-lboost_system -lboost_thread"
>
> BUT
> ./configure COMPILED_BY="Jérôme Grimbert <jgr### [at] freefr>"
> --disable-io-restrictions LIBS="-lboost_system"
>
> succeeds with configure, yet the final link fails.
>
>> g++ -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3
-ffast-math -march=native -pthread -L/usr/lib -L/usr/lib -o povray disp_sdl.o
disp_text.o ../vfe/libvfe.a ../source/libpovray.a -lSDL -L/usr/lib/x86_64-linux-gnu
-lSDL -lSM -lICE -lX11 -lIlmImf -pthread -lIlmImf -lz -lImath -lHalf -lIex
-lIlmThread -lIlmThread -ltiff -ljpeg -lpng -lz -lrt -lm -lboost_system -pthread
>> ../vfe/libvfe.a(vfesession.o): dans la fonction « vfe::vfeSession::Shutdown(bool)
»:
>> vfesession.cpp:(.text+0xcd2): référence indéfinie vers «
boost::thread::native_handle() »
>> vfesession.cpp:(.text+0xce7): référence indéfinie vers «
boost::thread::join_noexcept() »
>> vfesession.cpp:(.text+0xcfb): référence indéfinie vers «
boost::thread::detach() »
>> ../vfe/libvfe.a(vfesession.o): dans la fonction «
vfe::vfeSession::Initialize(vfe::vfeDestInfo*, vfe::vfeAuthInfo*) »:
>> vfesession.cpp:(.text+0x314b): référence indéfinie vers « vtable for
boost::detail::thread_data_base »
>> vfesession.cpp:(.text+0x3304): référence indéfinie vers «
boost::thread::start_thread_noexcept() »
>> vfesession.cpp:(.text+0x3339): référence indéfinie vers «
boost::thread::native_handle() »
>> vfesession.cpp:(.text+0x3352): référence indéfinie vers «
boost::thread::join_noexcept() »
>> ../vfe/libvfe.a(vfesession.o): dans la fonction « vfe::vfeSession::Resume() »:
>>
> and so on (many pages). (sorry, compiler message is in French)
>
> Test done on Ubuntu 13.10, 64 bits (x86_64)
>
it's compiles and links just fine on older 32bit system ... I /just/
pass the COMPILED_BY string, but it produces the odd image posted
earlier. I haven't tried running some of my old scenes just to see. I
got rid of the perforce version in favor of github. I'm wondering if it
has anything to do with /all/ the re-factoring work that's been done.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Copied the meshcam scene files into an alternate location and started
> going through the baking demo ....
>
> There were some warnings associated with not setting assumed_gamma
> before calling/using rgb vectors, and warnings in light_source
> definitions ... suspicious value after rgb. I fixed all those, and
> submitted changes to revision control, but that didn't address the
> unexpected results I'm seeing!!!
>
> Has anyone else worked through the demo?
Hmmm... this exact problem seems to be happening on the latest master
branch from github (works fine on the stable branch). Seems like
something went wrong with the mesh camera...
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.08.2014 11:19, schrieb Jaime Vives Piqueres:
>> Copied the meshcam scene files into an alternate location and started
>> going through the baking demo ....
>>
>> There were some warnings associated with not setting assumed_gamma
>> before calling/using rgb vectors, and warnings in light_source
>> definitions ... suspicious value after rgb. I fixed all those, and
>> submitted changes to revision control, but that didn't address the
>> unexpected results I'm seeing!!!
>>
>> Has anyone else worked through the demo?
>
> Hmmm... this exact problem seems to be happening on the latest master
> branch from github (works fine on the stable branch). Seems like
> something went wrong with the mesh camera...
As it turns out, James was onto something back then already: The POV-Ray
master branch was still ok then, but he must have built from the
refactor branch, where the bug had been introduced on 2013-12-16 with
commit 5cee76e.
That branch was merged into the POV-Ray master branch on 2014-06-13
(which happens to have been a Friday, yes) with commit 2c4e9f2.
Quite a silly bug actually, and a one-liner to fix.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> As it turns out, James was onto something back then already: The POV-Ray
> master branch was still ok then, but he must have built from the
> refactor branch, where the bug had been introduced on 2013-12-16 with
> commit 5cee76e.
>
> That branch was merged into the POV-Ray master branch on 2014-06-13
> (which happens to have been a Friday, yes) with commit 2c4e9f2.
>
> Quite a silly bug actually, and a one-liner to fix.
>
I didn't use the mesh cam for a while, but some weeks ago someone was
toying with my lightmapping demo, and got very strange results. I tried
it myself, and the result looked familiar... thanks for the fix!
--
jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
