## LuxCore: the new LuxRender C++ and Python API

Discussion related to the implementation of new features & algorithms to the Core Engine.

Moderators: Dade, jromang, tomb, zcott, coordinators

### Re: LuxCore: the new LuxRender C++ and Python API

hedphelym wrote:I appreciate that, I can test what ever solution comes up, I just want to get this to work for LuxMax

I pushed a tentative fix for this problem: you have to compile all LuxCore sources with CPP_API_EXPORTS symbol defined. Then you can use the library headers in your sources (without having CPP_API_EXPORTS defined). It should work, it is a copy of how old LuxRender C++ API was working.

Posts: 8393
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: LuxCore: the new LuxRender C++ and Python API

Hi

I tested the new macro succesfully.

Code: Select all
diff -r 00dead756b21 src/luxcore/CMakeLists.txt--- a/src/luxcore/CMakeLists.txt   Tue Dec 10 18:18:05 2013 +0100+++ b/src/luxcore/CMakeLists.txt   Tue Dec 10 21:15:33 2013 +0100@@ -123,6 +123,7 @@ )  add_library(luxcore STATIC ${LUXCORE_LIB_SRCS}${LUX_PARSER_SRC})+SET_TARGET_PROPERTIES(luxcore PROPERTIES DEFINE_SYMBOL CPP_API_EXPORTS) # for controlling visibility  link_directories (${SLG_LIB_DIR}${LuxRays_LIB_DIR})

If you now compile with -fvisibility=hidden -fvisibility-inlines-hidden ( OSX, Linux ), it links fine again and only wanted symbols are public.
In windows this is default afaik anyway.

Jens

jensverwiebe

Posts: 3420
Joined: Wed Apr 02, 2008 4:34 pm

### Re: LuxCore: the new LuxRender C++ and Python API

Just wanted to add something to the switch from GPL3 to Apache. Is this a wise move? You can't reuse 1.x code, and you can't copy/take/borrow code from other (L)GPL projects, but they can take whatever they want from you and re-license it under GPL, and you can't use their modifications. And I guess several commercial "forks" will suddenly appear. Only "nice" companies/developers will give code back, since they now don't have too.

If the only goal is to link against commercial software, then LGPL2(libs)+GPL2(apps) or a wrapper is good enough.

I'm not a big fan of GPL, I mostly use BSD/MIT myself, but in this case (L)GPL would be better (?) I'm sorry if this has been discusses earlier, didn't find any thread related.
olear

Posts: 24
Joined: Thu Dec 12, 2013 6:52 am
Location: Norway

### Re: LuxCore: the new LuxRender C++ and Python API

Hello everyone ! thanks for the hard job ! we love you so

I already use SLGPATHOCL to create complete scenes ! and I'want to use luxrender 2.0 in the future !
But how many time do you think it will make before lux 2.0 become more user friendly (proper integration inside blender "luxblend") to work with ?
i7 6700k + 32 Gb DDR4 + 2X R9 390 sapphir nitro.

sharlybg

Posts: 730
Joined: Tue Nov 02, 2010 10:22 am
Location: Ivory coast

### Re: LuxCore: the new LuxRender C++ and Python API

olear wrote:Just wanted to add something to the switch from GPL3 to Apache. Is this a wise move? You can't reuse 1.x code, and you can't copy/take/borrow code from other (L)GPL projects, but they can take whatever they want from you and re-license it under GPL, and you can't use their modifications. And I guess several commercial "forks" will suddenly appear. Only "nice" companies/developers will give code back, since they now don't have too.

If the only goal is to link against commercial software, then LGPL2(libs)+GPL2(apps) or a wrapper is good enough.

I'm not a big fan of GPL, I mostly use BSD/MIT myself, but in this case (L)GPL would be better (?) I'm sorry if this has been discusses earlier, didn't find any thread related.

This has indeed been discussed at various times both internally and in various threads on the forum over the years. Exact license choice aside, the core issue - from my personal point of view - is that a net-based wrapper (for example telnet or via some socked based rpc) or going purely via file-export->import is not a very convenient way of working for third party exporters/programs. Being unable to integrate lux into the ordinary workflow in these systems makes us a fairly unattractive target for exporter development (at least in some cases).

I think most people are fairly well aware of the pros/cons of going with a license like GPL3; i.e mandatory code-sharing etc. The code that the active developers have written themselves can be re-licensed without issue for use in LuxCore, the other parts written by inactive contributors or integrated from other non-public domain sources will of course have to be reimplemented (i.e. not copied). As I understand it, going with the LGPL* we would have faced the same issue of re-licensing as with APL (you cannot go from GPL->LGPL without consent from every single contributor), and still would have risked running into legal complications using the API externally (note: IMO - perhaps I'm FUD-ing here). FWIW, APL2 is less permissive than BSD/MIT (which is basically do-what-you-please). Over the years, as far as I know, we've not really used code directly from other projects (and I am not aware of the other way around either, except for Luxblend which was reused by Mitsuba as well). Except from the PBRT-basis of course. So I feel that even though this is a valid issue/concern in principle, it is mostly "theoretical" in practice.

So TL;DR - my Personal Opinion (tm), fwiw and all that, is that it's worth it in the long run, and I for one am not that worried about other people "stealing" anything or using the code in inappropriate ways. Perhaps I am being naive Your and others' milage may, of course, vary

tomb

Posts: 2677
Joined: Thu Oct 11, 2007 4:23 pm
Location: Oslo, Norway

### Re: LuxCore: the new LuxRender C++ and Python API

Apache is good for me, just wanted to know if the pros/cons has been talked about
olear

Posts: 24
Joined: Thu Dec 12, 2013 6:52 am
Location: Norway

### Re: LuxCore: the new LuxRender C++ and Python API

Dade wrote:I pushed a tentative fix for this problem: you have to compile all LuxCore sources with CPP_API_EXPORTS symbol defined. Then you can use the library headers in your sources (without having CPP_API_EXPORTS defined). It should work, it is a copy of how old LuxRender C++ API was working.

Thanks, I'll get to test it the next days, I appreciate the help on the issue from both of you.

hedphelym

Posts: 1408
Joined: Mon Aug 18, 2008 7:37 am
Location: Kristiansand Norway

### Re: LuxCore: the new LuxRender C++ and Python API

hi everyone

any news
i7 6700k + 32 Gb DDR4 + 2X R9 390 sapphir nitro.

sharlybg

Posts: 730
Joined: Tue Nov 02, 2010 10:22 am
Location: Ivory coast

### Re: LuxCore: the new LuxRender C++ and Python API

Hello!

It has been a while since this thread is updated. Is the forum down for maintenance most of the times?
Any idea when the 2.0 APL version of LuxRender will be finally released?
anoop.thomas

Posts: 1
Joined: Mon Feb 17, 2014 3:04 am
Location: India

### Re: LuxCore: the new LuxRender C++ and Python API

The work is ongoing. Subscribe to our G+ community and you will get weekly summaries of what's going on.

tomb

Posts: 2677
Joined: Thu Oct 11, 2007 4:23 pm
Location: Oslo, Norway

PreviousNext