Lux as a Python module

[dougal2]

Thanks for the info - I think you are safe to carry on in the direction you wish, I can easily wait a bit.

As for landmark moments, today I compiled lux against boost 1.42 and python 3.1

Code: Select all

doug@l64dev:~/dev/lux/build$ python3
Python 3.1.1+ (r311:74480, Nov  2 2009, 17:04:50)
[GCC 4.4.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylux
>>> dir(pylux)
['RenderingServerInfo', 'RenderingThreadInfo', 'ThreadSignals', '__doc__', '__file__', '__name__', '__package__', 'accelerator', 'addServer', 'addThread', 'areaLightSource', 'attributeBegin', 'attributeEnd', 'camera', 'cleanup', 'concatTransform', 'coordSysTransform', 'coordinateSystem', 'disableRandomMode', 'enableDebugMode', 'errorHandler', 'exit', 'exterior', 'film', 'framebuffer', 'getDefaultParameterValue', 'getDefaultStringParameterValue', 'getHistogramImage', 'getNetworkServerUpdateInterval', 'getParameterValue', 'getRenderingServersStatus', 'getServerCount', 'getStringParameterValue', 'greet', 'identity', 'init', 'interior', 'lightSource', 'loadFLM', 'lookAt', 'luxComponent', 'luxComponentParameters', 'makeNamedMaterial', 'material', 'motionInstance', 'namedMaterial', 'objectBegin', 'objectEnd', 'objectInstance', 'overrideResumeFLM', 'pause', 'pixelFilter', 'portalShape', 'removeServer', 'removeThread', 'renderingThreadsStatus', 'reverseOrientation', 'rotate', 'sampler', 'saveFLM', 'scale', 'setEpsilon', 'setHaltSamplePerPixel', 'setNetworkServerUpdateInterval', 'setParameterValue', 'setStringParameterValue', 'shape', 'start', 'statistics', 'surfaceIntegrator', 'texture', 'transform', 'transformBegin', 'transformEnd', 'translate', 'updateFilmFromNetwork', 'updateFramebuffer', 'volume', 'volumeIntegrator', 'wait', 'worldBegin', 'worldEnd']
>>>


[jromang]

As for landmark moments, today I compiled lux against boost 1.42 and python 3.1

Great news ! Blender 2.5 : we are coming

[SATtva]

Finally, pylux has been successfully compiled statically (yes, it's huge -- 11Mb!). :D

Code: Select all

readelf -d pylux.so | grep NEEDED
0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libpython2.6.so.1.0]
0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

The only major dynamic dependency it still has is for Python 2.6. What do you think about this? Should it also be linked statically (and make the module bigger by additional 1.7Mb) or it's ok to proceed like this?

[psychotron]

maybe would be useful to go for staticaly linked python, blender goes same way for new v2.5 cause many people still have issues with right version of it etc.. AFAIK
1.7mb? phew just one more floppy who cares..

[jeanphi]

Hi,

Actually it's huge because of liblux.a. I'm currently considering splitting the core lib from the modules so that applications not needing the modules (like luxcomp or luxmerge once the whole buffer stuff including flm handling is inside core/film.*) can become much smaller. Maybe we should also consider making liblux.a shared so that executables don't duplicate this whole pile of code.
And yes, I too believe that python should be statically linked considering its size.

Jeanphi

[SATtva]

Ok, then the current weeklies (as I already delayed them for two days) are being compiled with dynamic python, but for the next week I'll consider making it static. As to any efforts on making the binaries smaller, I'm openheartedly appreciate them. :)

[SATtva]

I've just tested static linking of libpython. Works nicely, although the binary is actually 2.8Mb larger (I've looked at .so instead of .a by mistake ).

[jromang]

I added a 'getOption' call for queryable parameters in the python API :

Code: Select all

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylux
>>> pylux.init()
>>> pylux.lookAt(0,0,1,0,1,0,0,0,1)
>>> pylux.worldBegin()
>>> pylux.lightSource('infinite', [])
>>> pylux.worldEnd()
[Lux 2010-Feb-09 16:24:04 DEBUG : 0] pyLux launching worldEnd thread
>>> [Lux 2010-Feb-09 16:24:04 DEBUG : 0] Compiled scene size: 0KBytes
[Lux 2010-Feb-09 16:24:04 WARNING : 0] Parameters 'xsamples' and 'ysamples' are deprecated, use 'pixelsamples' instead
[Lux 2010-Feb-09 16:24:04 DEBUG : 0] Building KDTree, primitives: 0
[Lux 2010-Feb-09 16:24:04 INFO : 0] Preprocess thread uses seed: 1804289382
[Lux 2010-Feb-09 16:24:04 INFO : 0] Thread 0 uses seed: 1804289383

>>> print pylux.getOptions()
<?xml version='1.0' encoding='utf-8'?>
<context>
  <object>
    <name>film</name>
    <attribute>
      <name>xResolution</name>
      <type>int</type>
    </attribute>
  </object>
</context>

>>> pylux.getOption("film","xResolution")
800


This should be the standard way of getting values from lux in the near future

[dougal2]

Is there any way the bindings alone can be changed such that I can create many instances of Lux within python ?
e.g. rather than all the lux API functions being at the module-level, move them into a class and have them de-coupled from other class instances.

Has it been done this way because the Lux API itself cannot be used this way ? Are we talking binding refactoring or major API re-think ?

The reason I ask is that it would probably be needed in the future if we want to create material previews at the same time as rendering...
(or in fact, generate several material previews simultaneously)

[jromang]

Hi doug : yes there is a way What you want is named a 'context' and I added this to lux a long time ago...but it was never used (maybe because it's not exposed in the C API ). Again, this is inspired by the rispec (https://renderman.pixar.com/products/ri ... pec3_2.pdf), you can read more about it p.9
I think the good way to expose this to python is to create a 'context' class : instancing a context class just creates a new object, and than you can make calls on this context :
eg :

Code: Select all

import pylux
pylux.init()
context1=pylux.getcontext()
...
context2=pylux.getcontext()
...
context1.lookAt(....)


It shouldn't be too difficult to do - If this is what you want I will start to work on it this week ; but as far as I know contexts were never used - so this is highly untested feature