latest Pixie 64bit amd deb by Cedric PAILLE
Status: Beta
Brought to you by:
render_man
Menu
▾
▴
I am using Ubuntu 9.04.
I have the repositories and the key from Cedric PAILLE source forge site.
I downloaded and ran using Gdebi.
Gdebi says that there is an unresolvable dependency libpng12.
I checked synaptic and I have these installed: libpng12-0 and libpng12-dev.
I just tried to use the dev deb and got this error message from Gdebi.
Error: Dependency is not satisfiable: libpng12
hi Cedric, same thing for me.
i have tried to compile on amd64, seems working alone , but with RIBMOSAIC exporter i am not able to render a simple scene (segfault) (due perhaps specific shader of RIBMOSAIC? sdrc compiler?)
As , i am not a programmer , i prefer to use this "certified" package
do you have a feedback on ths error ?
Checkout this post if using Pixie with CVS MOSAIC ;)
http://sourceforge.net/forum/forum.php?thread_id=3312195&forum_id=200366
About the forwarding post , i note :
- the first patch isn't included in SVN ( i have made the updating local src) OK, the second is 1208 Ok
the 3 other points aren't clear for me ... where are the changes ? any patch included or file name ?
i have rebuilt Pixie with above , same thing ...
to clarify my problem :
system Debian 5.02,
kernel2.6.29-2-amd64 (#1 SMP Sun May 17 17:15:47 UTC 2009)
gcc 4.4.1 (x86_64-linux-gnu)
configuring Pixie 2.2.6 svn 1208, gives :
@obama:~/dvp/Pixie$ csh makeunix
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
sl.y: conflits: 1 décalage/réduction
-> comment : may be a problem . ?
alaw@obama:~/dvp/Pixie$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking how to run the C++ preprocessor... g++ -E
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether make sets $(MAKE)... (cached) yes
checking for dlopen in -ldl... yes
checking for sin in -lm... yes
checking for pthread_create in -lpthread... yes
checking for acosf in -lm... yes
checking for asinf in -lm... yes
checking for atan2f in -lm... yes
checking for atanf in -lm... yes
checking for cosf in -lm... yes
checking for expf in -lm... yes
checking for fabsf in -lm... yes
checking for floorf in -lm... yes
checking for fmodf in -lm... yes
checking for hypotf in -lm... yes
checking for logf in -lm... yes
checking for powf in -lm... yes
checking for sinf in -lm... yes
checking for sqrtf in -lm... yes
checking for tanf in -lm... yes
checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for XOpenDisplay in -lX11... yes
checking for XShmAttach in -lXext... yes
checking for fltk-config... /usr/bin/fltk-config
checking for FLTK with GL support... yes
checking tiffio.h usability... yes
checking tiffio.h presence... yes
checking for tiffio.h... yes
checking for TIFFOpen in -ltiff... yes
checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
checking for png_create_write_struct in -lpng... yes
checking for OpenEXR... yes
checking for gzopen in -lz... yes
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for vprintf... yes
checking for _doprnt... no
checking for gethostname... yes
checking for gettimeofday... yes
checking for mkdir... yes
checking for rmdir... yes
checking for socket... yes
checking for strdup... yes
checking for strstr... yes
checking for strtod... yes
checking for strtol... yes
checking for random... yes
checking for flex... /usr/bin/flex
checking for bison... /usr/bin/bison
checking for Mac OS X Carbon support... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating src/common/Makefile
config.status: creating src/file/Makefile
config.status: creating src/framebuffer/Makefile
config.status: creating src/openexr/Makefile
config.status: creating src/gui/Makefile
config.status: creating src/precomp/Makefile
config.status: creating src/rgbe/Makefile
config.status: creating src/sdr/Makefile
config.status: creating src/sdrc/Makefile
config.status: creating src/ri/Makefile
config.status: creating src/rndr/Makefile
config.status: creating src/texmake/Makefile
config.status: creating src/sdrinfo/Makefile
config.status: creating src/show/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
------------------------------------------------
Installation info:
PIXIEHOME: /opt/pixie
Documentation: /opt/pixie/doc
Shaders: /opt/pixie/shaders
RIBs: /opt/pixie/ribs
Textures: /opt/pixie/textures
Displays: /opt/pixie/displays
Procedurals: /opt/pixie/procedurals
Modules: /opt/pixie/modules
------------------------------------------------
To build Pixie:
>make
>make install
Terminus Est
--> make and make install give no warning no error
Using :
-Blender 2.49a + Python 2.6.2
-Mosaic 0.43 cvs 1.56
scene is from template,+ a plane + material, + a lamp, render .... segfault
trying :
-materials setup displacement shader to NONE , segfault
- +dice binary set 1 render OK
- add materials setup displacement shader to ds_MOSAICdisplace + dice = 1 , segfault
- materials setup plastic2 + dice = DEFAULT or 1, rendering OK
- + ds_MOSAICdisplace shader , rendering OK
If i use the sample scene like sss.rib of suzanne OK
on winxp32 i haven't this problem, only a remark, i have used the 2.2.5 sdrc.exe due problem of the availability of the new download 2.2.6 win.exe .(dll problem)
it seems more a MOSAIC than Pixie, i need your expert comment ...
Sorry, I mentioned that post as it has know problems between SVN Pixie and CVS MOSAIC, I was assuming your problems may be connected. It seems however the most critical problem has been patched in Pixie's trunk so is no long necessary (http://sourceforge.net/tracker/?func=detail&aid=2722418&group_id=59462&atid=491094). The other issues are not critical so would not cause your problem.
As reference I am developing MOSAIC under a similar environment running 32bit Debian testing compiling latest SVN Pixie with the following patches:
http://sourceforge.net/tracker/?func=detail&aid=2811709&group_id=59462&atid=491094
This one allows MOSAIC's surface and displace shader to blend up to 10 textures like Blender materials.
http://sourceforge.net/tracker/?func=detail&aid=2802398&group_id=59462&atid=491094
This one fixes add substring match() which MOSAIC uses to know when to load a reflection map as texture or cube map (planar or cube mapping).
Not sure what else to say without looking at a .blend to see whats wrong, I'm currently testing MOSAIC and its shaders against 3Delight, Air, PRMan, SVN Pixie and git Aqsis under 32bit Linux and WindowsXP. To date there are a number of small bugs that need to be resolved in Pixie and Aqsis but none of them critical errors.
Eric Back (WHiTeRaBBiT)
Eric, I made the changes requested, even result. I would have wished to be able to install the software under Debian to be sure of 64bits Pixie installation, Cédric, if you can answer,(libpng) thank you in advance.
In fact I understand complexity well to test a stacking of software, api blender + mosaic + python + pixie + c++ + system…. . I suggest to test according to the following procedure:
the version 32bits of the software chain runs on winxp and Debian, i join the file test .blend and the files exported by Mosaic in order to test in 32bits.
the download link
http://www.easy-share.com/1907585040/stpixie.tar.gz
1) if nok, to compare export 32bits starting from the file blend and 64bits (joined), to search the differences.
1a) if difference => to analyze why?
1b) if no difference ==> 1a) in more complicated
2) if ok, export 64bits is running in 32bits, the problem is located more towards compilation of Pixie in versiont 64bits, obviously not implicitly a defect of Pixie, but one of chain, software or librairy that it used or compiled on my system ....
Sorry for the delay of the answer, but i am busy in this moment.
Thanks for the test case, unfortunately I can see nothing wrong with the blend setup.
I've tested both the supplied RIB and blend and have had no problems. I also tried the scenarios you mentioned above, changing the displacement shader, surface shader and trying various options (such as dice) all with no problems. This was tested in 32bit Linux and WinXP both compiled from source with mentioned patches.
At this point I can only assume its your build or your build environment :(
The only thing that comes to mind is to try different compiler options to see if anything helps. For myself I run a Intel Core2 Quad with the following GCC options -march=core2 -mfpmath=sse. I will get random segfaults without these options, but I've never compiled Pixie for 64bit so it may be very different.
Anyway I'm sure someone else here has more qualified suggestions then myself (I'm mostly into Python not C). Sorry.
Hello everyone
while trying to progress I made the following test in 64bits, to make a preview of surfaces shaders, some are not returned (obviously ss_MOSAICsurface) but also a simple surface shader like filament.sl
and gdb gives
(gdb) run
Starting program: /opt/pixie/bin/rndr ShaderPreview.rib
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff5185910 (LWP 13649)]
[New Thread 0x7ffff3a34910 (LWP 13650)]
[New Thread 0x7ffff3233910 (LWP 13651)]
[New Thread 0x7ffff2a32910 (LWP 13652)]
[New Thread 0x7ffff2231910 (LWP 13653)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff3233910 (LWP 13651)]
0x00007ffff6610e50 in strcmp () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff6610e50 in strcmp () from /lib/libc.so.6
#1 0x00007ffff7756615 in CShadingContext::execute (
this=<value optimized out>, cInstance=<value optimized out>,
locals=<value optimized out>) at scriptOpcodes.h:345
#2 0x00007ffff78329c0 in CShadingContext::shade (this=<value optimized out>,
object=<value optimized out>, uVertices=<value optimized out>,
vVertices=<value optimized out>, dim=<value optimized out>,
usedParameters=3999156339, displaceOnly=0) at shading.cpp:1079
#3 0x00007ffff7813073 in CReyes::shadeGrid (this=0x6972e0,
grid=0x7fffe40821e0, Ponly=0) at reyes.cpp:1045
#4 0x00007ffff784c2b7 in CStochastic::drawQuadGridZminUnshaded (
this=0x6972e0, grid=<value optimized out>) at stochasticQuad.h:617
#5 0x00007ffff7811adb in CReyes::render (this=0x6972e0) at reyes.cpp:373
#6 0x00007ffff78125a4 in CReyes::renderingLoop (this=0x6972e0)
at reyes.cpp:308
#7 0x00007ffff77e9998 in rendererDispatchThread (w=<value optimized out>)
at renderer.cpp:1105
#8 0x00007ffff729f73a in start_thread () from /lib/libpthread.so.0
#9 0x00007ffff666343d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
(gdb)
in fact my comment above has an error, the shader MOSAICsurface is called in the preview.
Why does the preview function for some shaders and not for others? (conditions identical of scene)
I noticed another topic with segfault:
http://sourceforge.net/forum/forum.php?thread_id=2955003&forum_id=200367
I note the line which call strcmp (I think)
scriptOpcodes.h: 352 DEFOPCODE (Sneql2, “sneql”
and in my case:
scriptOpcodes.h: 345 DEFOPCODE (Seql2, “seql”
in fact I modified the MOSAIC shader to remove part of the code not used as occlusion
that shifts the problem on breakpoints passed, in a normal case 72 in the other 92 calls
my knowledge in gdb is weak, how to trace:
Breakpoint 1, CShadingContext:: carry out (this=0x65da20, cInstance=0x697590, locals=0x7ffff380f010)
At scriptOpcodes.h: 352
352 DEFOPCODE (Sneql2, “sneql”, 3, OPERANDS3EXPR_PRE (float *, const char **, const char **), SNEQLEXPR, OPERANDS3EXPR_UPDATE (1,1,1), NULL_EXPR, 0)
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff64f7e50 in strcmp () from /lib/libc.so.
hello,
can be a bug, using valgrind :
==24128== Invalid read of size 1
==24128== At 0x4C24371: strcmp (mc_replace_strmem.c: 337)
==24128== by 0x4EB03BE: CShadingContext:: carry out (CProgrammableShaderInstance*, float **) (scriptOpcodes.h: 343) ==24128== by 0x4FE268E: CProgrammableShaderInstance:: carry out (CShadingContext*, float **) (shader.cpp: 606) ==24128== by 0x4FE9F8E: CShadingContext:: shade (CSurface*, int, int, EShadingDim, unsigned int, int) (shading.cpp: 1079) ==24128== by 0x4FBF966: CReyes:: shadeGrid (CReyes:: CRasterGrid*, int) (reyes.cpp: 1045)
==24128== by 0x50034E6: CStochastic:: drawQuadGridZminUnshaded (CReyes:: CRasterGrid*) (stochasticQuad.h: 597) ==24128== by 0x4FF6D31: CStochastic:: rasterDrawPrimitives (CReyes:: CRasterGrid*) (stochasticPrimitives.h: 31) ==24128== by 0x4FBD0CE: CReyes:: render () (reyes.cpp: 373)
==24128== by 0x4FBCE3F: CReyes:: renderingLoop () (reyes.cpp: 308)
==24128== by 0x4F97D09: rendererDispatchThread (void*) (renderer.cpp: 1105)
==24128== by 0x586B739: start_thread (in /lib/libpthread-2.10.1.so)
==24128== by 0x64FA43C: clones (in /lib/libc-2.10.1.so)
==24128== Address 0x41480000089fef38 is not stack' D, malloc' D gold (recently) free' D
thus when I compare the rendertype, I have a nophysical address of the 0x41800000…
there is a problem of assignment of string, I modified the code
according to in scripOpcodes.h: 744:
- DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (float *, const float *), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0) +DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (tank **, tank **), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0)
didn't I have a problem any more… that think about it?
comment above, a small problem of translation, sorry :
in scriptOpcodes.h: 744:
- DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (float *, const float *), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0)
+DEFOPCODE (Movess, “movess”, 2, OPERANDS2EXPR_PRE (char **, char **), SUNARYEXPR, OPERANDS2EXPR_UPDATE (1.1), NULL_EXPR, 0)