1. 10 May, 2014 7 commits
    • Artur Grunau's avatar
      Add support for automatic registration of Lua pipelines · c2348225
      Artur Grunau authored
      As there's currently only one Lua pipeline, we could so far get away
      with storing it in the `scripting` directory, giving it a generic name
      and registering it manually. However, this approach won't work anymore
      once additional Lua pipelines start to be implemented.
      To support multiple Lua pipelines, implement a registration mechanism
      for scripted pipelines based on PipelineFactory and similar to
      PipelineRegistrar. It scans each active module's `pipelines` directory
      for Lua pipelines, parses them and generates a registration header that,
      when included, registers them with PipelineFactory.
      As a result of the above, the test Lua pipeline had to be moved to
      `modules/preprocessing/pipelines/` and could be renamed
      References #1
    • Artur Grunau's avatar
      Fix out-of-tree and Visual Studio builds · 8079c98c
      Artur Grunau authored
      Out-of-tree builds were broken due to Lua and Swig header files not
      being correcly included. The state of Visual Studio builds was even
      worse: they failed because Lua modules, scripts and libraries were
      The issues mentioned above have been fixed by making the build system
      properly deal with out-of-tree builds and multi-config generators.
      References #1
    • Artur Grunau's avatar
      Lua and C++ parts of a pipeline can now interact · 31df41df
      Artur Grunau authored
      Lua functions invoked by LuaPipeline had no access to the pipeline
      instance and, as a result, couldn't configure or modify it in any way.
      In order to make it possible to actually define pipelines in Lua, each
      script can now access the C++ pipeline object it's supposed to augment
      via a global variable named instance. This variable is injected into the
      script by LuaPipeline and can be used to call standard pipeline methods
      (e.g. addProcessor).
      The functionality described has been tested by implementing a pipeline
      constructor that creates and registers several processors.
      References #1
    • Artur Grunau's avatar
      Make LuaPipeline responsible for creating states · 473dba97
      Artur Grunau authored
      Lua states used to be created externally and passed to LuaPipeline
      objects on instantiation. Because they shouldn't be shared anyway, and
      due to high state-pipeline coupling, states are now created by Lua
      pipelines directly.
      References #1
    • Artur Grunau's avatar
      Initial support for pipelines implemented in Lua · b3dba5f4
      Artur Grunau authored
      A new class, LuaPipeline, has been added to the scripting module. It
      provides a way of interfacing with pipelines implemented in Lua.
      For the time being only the most basic operations (i.e. init and deinit)
      are supported, but work on making it possible to implement
      fully-functional pipelines in Lua is underway.
      References #1
    • Artur Grunau's avatar
      Wrap several CAMPVis classes with SWIG · 4f6b4ba6
      Artur Grunau authored
      To test the feasibility of using SWIG to generate Lua bindings for
      CAMPVis several classes have been wrapped with SWIG interface files.
      If version 2.0.11 of SWIG is used to generate bindings, it must be
      patched to fix wrapper compilation errors:
      References #1
    • Artur Grunau's avatar
      CMake skeleton of the scripting feature · 82a6d86c
      Artur Grunau authored
      An option to enable CAMPVis scripting has been added to the top level
      CMakeLists.txt. Moreover, a minimal sub-project for the scripting
      feature has been created. There's also a new CMake macro, FindLua, that
      locates Lua's include and library files.