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

Postby Dade » Tue Dec 10, 2013 10:24 am

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.
User avatar
Dade
Developer
 
Posts: 8318
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

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

Postby jensverwiebe » Tue Dec 10, 2013 3:22 pm

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
User avatar
jensverwiebe
Developer
 
Posts: 3402
Joined: Wed Apr 02, 2008 4:34 pm

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

Postby olear » Mon Dec 16, 2013 3:46 am

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

Postby sharlybg » Mon Dec 16, 2013 4:19 am

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

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.
User avatar
sharlybg
 
Posts: 687
Joined: Tue Nov 02, 2010 10:22 am
Location: Ivory coast

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

Postby tomb » Mon Dec 16, 2013 4:27 am

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 :)
User avatar
tomb
Developer
 
Posts: 2677
Joined: Thu Oct 11, 2007 4:23 pm
Location: Oslo, Norway

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

Postby olear » Mon Dec 16, 2013 4:33 am

Ok, thanks for you reply.

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

Postby hedphelym » Mon Dec 16, 2013 5:15 am

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.


Dade, jensverwiebe

Thanks, I'll get to test it the next days, I appreciate the help on the issue from both of you.
User avatar
hedphelym
Developer
 
Posts: 1407
Joined: Mon Aug 18, 2008 7:37 am
Location: Kristiansand Norway

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

Postby sharlybg » Fri Jan 10, 2014 12:53 pm

hi everyone ;)

any news
i7 6700k + 32 Gb DDR4 + 2X R9 390 sapphir nitro.
User avatar
sharlybg
 
Posts: 687
Joined: Tue Nov 02, 2010 10:22 am
Location: Ivory coast

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

Postby anoop.thomas » Mon Feb 17, 2014 3:15 am

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

Postby tomb » Mon Feb 17, 2014 3:40 am

The work is ongoing. Subscribe to our G+ community and you will get weekly summaries of what's going on.
User avatar
tomb
Developer
 
Posts: 2677
Joined: Thu Oct 11, 2007 4:23 pm
Location: Oslo, Norway

PreviousNext

Return to Architecture & Design

Who is online

Users browsing this forum: No registered users and 1 guest