OctaneRender™ for Blender 1.20.2 - 2.3 beta Linux [OBSOLETE]

[mib2berlin]

Hi JimStar, get crash of Blender if I switch one window to LiveDB.
octane.dat
liboctane.so
in /usr/lib64

Blender and OctaneServer
in /home/user

Code: Select all

read blend: /home/pepo/3d_modelle/cycles_cornell_bench/octane_cornell_bench.blend

Program received signal SIGSEGV, Segmentation fault.
0x0000000000e07ff5 in mat_livedb_build_tree ()
(gdb) bt
#0  0x0000000000e07ff5 in mat_livedb_build_tree ()
#1  0x0000000000e06ca7 in draw_mat_livedb ()
#2  0x0000000000e04f26 in mat_livedb_main_area_draw ()
#3  0x0000000000f6fea5 in ED_region_do_draw ()
#4  0x0000000000d073f3 in wm_draw_update ()
#5  0x0000000000d04348 in WM_main ()
#6  0x0000000000cc7171 in main ()
(gdb) 

Cheers, mib.
EDIT:This crash was result of not activated OctaneRender on this system, after deactivate and reactivate all is working.
My error but should not crash.

[grimm]

Hi grimm, you could try to make a symlink libGLEW.so.1.6 to 1.9.
I have the same problem on Opensuse 12.3/64 with 1.9 but symlink work.

Cheers, mib.

Thanks mib, that worked. I was a bit leery about trying it because of the version difference. It appears to be working great! It also seems that OctaneServer is running longer before it crashes too.

The only other strangeness is with the liveDB. It works fine but I wanted to combine two of the liveDB textures, alas when you click the "Get Item" button it overwrites the existing texture. I haven't been able to find a way to include two or more liveDB textures in an object's texture. It sure would be nice to have a liveDB node in the node editor if that is possible?

A minor quibble is when you get a liveDB texture all the nodes end up on top of each other.

[JimStar]

MAybe add this to the manual. If OctaneServer fails to start because oct files are not to be found type this "sudo cp /usr/lib64/*oct* /usr/lib/" In my distro (DreamStudio) this must be done!

This is very strange! Why is it needed?
As the normal logic across the different Linux distributives is:
- if you have both /usr/lib64 and the default /usr/lib (which either contains 32-bit libraries, or symlinks to /usr/lib32) - you have 32-bit system
- if you have both /usr/lib32 and the default /usr/lib (which either contains 64-bit libraries, or symlinks to /usr/lib64) - you have 64-bit system
It is very weird, that this distro needs two copies (!, some lib-files have huge size) of library files in absolutely not-logical way: if you already have /usr/lib64 folder and you have 64-bit system, the only logical way for /usr/lib is just symlink to /usr/lib64, not to be the second copy of /usr/lib64... Otherwise - it can be normal folder and contain 64-bit libraries, but in this case it is not logical for the system to have /usr/lib64 at all - only /usr/lib32 with 32-bit set of libraries...
I just don't have this distro installed, so can't check what's going on there...

[JimStar]

It appears to be working great! It also seems that OctaneServer is running longer before it crashes too.

Can you please post here the full error message from the system after OctaneServer crashes?

[grimm]

No problem.

Code: Select all

./OctaneServer 
ERROR: Program executed illegal instruction.. terminating
Terminated

[JimStar]

Next version HERE.