1. 15 Jul, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Fixed GCC compatability of scripting module: · 92c3bdef
      Christian Schulte zu Berge authored
      * CMake build files now support unix builds
      * SWIG interface files and Lua wrappers are now fully C++ compliant to comfort GCC
      * Hacked shared/static builds of the campvis-modules module even more, but now it works on both MSVC and GCC
  2. 10 Jul, 2014 1 commit
  3. 02 Jun, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Further work on Lua scripting console: · f1b3cd9a
      Christian Schulte zu Berge authored
      * Implemented one single gloabel Lua VM for the entire CampVisApplication instead of one VM for each pipeline.
      * The global Lua VM has a "pipelines" table/array, holding the pointers to each loaded pipeline
      * ScriptingWidget support cycling through last executed commands via the arrow keys
      * LuaVmState supports redirecting Lua's print() function to a custom one that uses tgt::Logmanager for printing (just as proof-of-concept). This shall later be extended to pass all Lua output to the scripting console.
  4. 31 May, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Started implementation of a Lua console in campvis-application. · a33ee468
      Christian Schulte zu Berge authored
      With scripting enabled, the main window now has an additional scripting widget that allows to interact with a Lua VM. The current proof-of-concept implementation creates a Lua VM for every instantiated CAMPVis pipeline while the console just interacts with the first pipeline's one.
      However, the Lua VM concept has to be reiterated later anyway. It may make more sense to have just a single central Lua VM for the entire application, which is shared by each pipeline.
  5. 30 May, 2014 1 commit
  6. 16 May, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Merge branch 'swig' into 'development' · 418c5e78
      Christian Schulte zu Berge authored
      Initial implementation of a Lua scripting layer
      Over the last several months a scripting layer that allows pipelines to be defined in Lua has been developed. It uses SWIG to generate Lua modules with bindings for CAMPVis classes. It is an opt-in feature, and tries to be as non-intrusive to standard CAMPVis code as possible.
      The implementation of the scripting layer has reached a state where it's possible to write fully-functional pipelines in Lua. In fact, 2 existing pipelines have been reimplemented in Lua for testing purposes and added to the project. In my opinion, this marks a good point to merge the initial implementation into the development branch — that would make it easier to test and improve it.
      Naturally, there are still many rough edges that should eventually be dealt with, but they can be addressed separately as new features:
      - bindings coverage is rather low
      - Lua pipelines currently need to be statically registered
      - pipeline definition syntax could be streamlined (e.g. by getting rid of the `instance` global variable)
  7. 11 May, 2014 3 commits
    • Artur Grunau's avatar
      Update the Lua submodule to the newest version · 2a838d8f
      Artur Grunau authored
      The CMake-enabled version of Lua that CAMPVis' scripting layer uses
      hasn't been updated in a while. Synchronise it with upstream now that
      we're getting ready to merge the `swig` branch in.
      References #1
    • Artur Grunau's avatar
      Remove `scripting/testapp.cpp` · e5b278ec
      Artur Grunau authored
      `scripting/testapp.cpp` contains a simple console application that was
      used to test CAMPVis' scripting layer before it was ready for
      integration with the main GUI application. Now that Lua pipelines can be
      registered and executed the same way regular ones are, the test
      application is no longer needed. Consequently, this commit removes it
      from the project.
      References #1
    • Artur Grunau's avatar
      Improve documentation of LuaPipeline and related classes · dc76b535
      Artur Grunau authored
      Glue classes that live in the `scripting/glue` directory were mostly
      undocumented, and the documentation of LuaPipeline was incomplete.
      Improve the documentation of LuaPipeline and LuaVmState. Document
      LuaTable, RegularLuaTable and GlobalLuaTable from the `scripting/glue`
      References #1
  8. 10 May, 2014 31 commits
    • Artur Grunau's avatar
      Add a light source to Lua pipelines · 080b3ae3
      Artur Grunau authored
      Starting with commit d6fec679, pipelines need to provide their own light
      source to function properly. Lua pipelines didn't, which caused them to
      fail to render.
      Add a SWIG wrapper for LightSourceProvider to make it accessible from
      Lua. Instantiate and attach a light source in existing Lua pipelines.
      References #1
    • Artur Grunau's avatar
      Adapt bindings to the new invalidation level system · 16ee3af2
      Artur Grunau authored
      Commit 293d43dd introduced breaking changes to the way invalidation
      levels are handled. As a result, property and processor-related bindings
      failed to compile.
      Update all SWIG bindings affected by the above problem to make them
      compatible with the current property and processor-related APIs.
      References #1
    • Artur Grunau's avatar
      Hide superfluous targets provided by LuaDist · 0786655c
      Artur Grunau authored
      LuaDist, the CMake-enabled distribution of Lua that the scripting
      feature uses on Windows, provides several targets (lua, luac, wlua) for
      which there's not much use in CAMPVis. This commit hides them from the
      target list to make project files generated by CMake cleaner.
      References #1
    • Artur Grunau's avatar
      Better error message when Lua submodule is missing · 1aa809a1
      Artur Grunau authored
      If CAMPVIS_BUILD_LIB_LUA was set but the Lua Git submodule wasn't checked
      out, the user would get a generic "could not find CMakeLists.txt" error
      message which wasn't of much help.
      Log a custom error message that provides a hint how to fix the problem in
      the above situation.
      References #1
    • Artur Grunau's avatar
      FindLua: only set LUA_FOUND if CAMPVIS_BUILD_LIB_LUA is ON · 2a946aa2
      Artur Grunau authored
      The FindLua CMake script would previously set LUA_FOUND if the directory
      containing the source code of Lua existed without checking if it was
      actually part of the build. This could lead to compilation errors if
      CAMPVIS_BUILD_LIB_LUA was disabled.
      Add an additional check to FindLua to only set LUA_FOUND if
      CAMPVIS_BUILD_LIB_LUA is ON and the directory containing the source code
      of Lua exists.
      References #1
    • Artur Grunau's avatar
      Disable the scripting feature by default · 7d4857ae
      Artur Grunau authored
      Scripting was so far enabled by default on the `swig` branch to make its
      development easier. However, it should be an opt-in feature once it's
      merged in. As that time is quickly approaching, the scripting feature has
      been disabled by default.
      References #1
    • Artur Grunau's avatar
      Remove the `campvis-scripting-test` target · bdc4817c
      Artur Grunau authored
      Early in the development of the scripting feature the
      `campvis-scripting-test` target was used to test bindings generated by
      SWIG. Now that pipelines defined in Lua have been integrated into the
      main application (where the bindings they use can be tested much more
      thoroughly) the console test application is no longer needed and has
      been removed.
      References #1
    • Artur Grunau's avatar
      Add support for all signal arities to SWIG wrappers for siglot · 9ee1138f
      Artur Grunau authored
      SWIG wrappers for siglot only supported unary signals until now. This
      commit adds support for all remaining signal arities to make it possible
      to connect to arbitrary signals from Lua.
      The implementation makes heavy use of templates but, due to the
      limitations of VS 2010 (no variadic templates), still contains lots of
      duplicated boilerplate code.
      `sigslot.i` has been moved from `scripting/` to `ext/sigslot/` to keep
      it close to the code it's wrapping.
      References #1
    • Artur Grunau's avatar
      Add support for disconnecting slots defined in Lua · 2d4761ba
      Artur Grunau authored
      Up until now it wasn't possible to manually disconnect slots defined in
      Lua: they could only be disconnected automatically when their
      corresponding signals were destroyed.
      Add a special `disconnect` method to sigslot's Lua wrapper that makes it
      possible to manually disconnect slots defined in Lua.
      References #1
    • Artur Grunau's avatar
      Guard accesses to Lua state with a mutex · a337b188
      Artur Grunau authored
      Now that support for signals and slots has been added to Lua pipelines,
      each Lua state has to be protected with a mutex because it's not
      thread-safe and different threads (running LuaPipeline or a processor
      attached to it) may try to access it simultaneously.
      The mutex needs to be recursive due to the fact that Lua code can
      trigger the emission (or copying) of signals that have slots defined it
      Lua connected to them. This in turn causes the state to be accessed from
      a thread that, unbeknownst to it, already holds a lock on the mutex.
      A pointer to the mutex is stored in the state's registry; this way code
      that accesses Lua state directly (e.g. connections between sigslot's
      signals and slots defined in Lua) can retrieve and lock it when
      References #1
    • Artur Grunau's avatar
      Make Lua connections work with copyable signals · 8f1dd0c9
      Artur Grunau authored
      Until now, Lua connections had only stub implementations of several
      sigslot's API methods, including clone() and getdest(). This led to
      crashes when signals that contained Lua connections were copied.
      Provide proper (if somewhat forced) implementations of clone() and
      getdest() for Lua connections. This makes Lua connections work with
      signals that may be copied.
      References #1
    • Artur Grunau's avatar
      Scripting: fixes related to building shared libs · 2e595fd0
      Artur Grunau authored
      Now that BUILD_SHARED_LIBS is a top-level CAMPVis option, we could take
      advantage of that and make the way we build Lua more robust. Also,
      campvis-scripting has been marked as static library to prevent the build
      from failing when BUILD_SHARED_LIBS is set.
      References #1
    • Artur Grunau's avatar
      Reimplement VolumeRendererDemo in Lua · 497b2b38
      Artur Grunau authored
      To properly test the initial support for slot functions defined in Lua,
      VolumeRendererDemo has been reimplement as a Lua pipeline.
      References #1
    • Artur Grunau's avatar
      Initial support for using Lua functions as slots · 785ba7de
      Artur Grunau authored
      Certain types of pipelines need to react to changes in their constituent
      processors. CAMPVis uses a signal-slot mechanism (based on the sigslot
      library) for this purpose. Up until now, however, there was no way to
      connect to a signal from a pipeline defined in Lua.
      This commit adds initial support for connecting Lua functions to
      sigslot's signals. The current implementation only works with unary
      signals, and should be considered a proof of concept. To test it,
      AbstractProcessor's s_validated signal has been wrapped using SWIG.
      References #1
    • Artur Grunau's avatar
      Get rid of ExtendedAutoEvaluationPipeline · d41681ec
      Artur Grunau authored
      Lua pipelines need to access certain protected properties of
      AbstractPipeline but can't reference them directly as they don't
      actually inherit from any class. ExtendedAutoEvaluationPipeline was
      added to generated bindings to expose public getters for the properties
      in question. LuaPipeline instances could then be cast to
      ExtendedAutoEvaluationPipeline to give Lua code access to these new
      However, now that HasPropertyCollection has been wrapped, the protected
      properties can be accessed via its getProperty method. This approach is
      preferred as it's much cleaner and simplifies our interface files. As a
      result, ExtendedAutoEvaluationPipeline has been removed.
      References #1
    • Artur Grunau's avatar
      Lua bindings: wrap campvis::VolumeRenderer · de05bfe3
      Artur Grunau authored
      In order to reimplement VolumeRendererDemo in Lua
      campvis::VolumeRenderer from the vis module has been wrapped using SWIG.
      References #1
    • Artur Grunau's avatar
      Add Lua bindings for several classes from campvis-core · 816fdc50
      Artur Grunau authored
      Several classes from campvis-core that are needed to reimplement
      VolumeRendererDemo in Lua have been wrapped using SWIG. Among the
      classes are: ImageData, CameraProperty,
      TrackballNavigationEventListener, and their respective super-classes.
      References #1
    • Artur Grunau's avatar
      Lua bindings: wrap tgt::Vector3 and tgt::Camera · 1fc1219c
      Artur Grunau authored
      As a prerequisite to wrapping campvis::CameraProperty, bindings for two
      new classes from TGT have been added: tgt::Vector3 and tgt::Camera.
      References #1
    • 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
    • Christian Schulte zu Berge's avatar
      Lua scripting: add a wrapper for FloatProperty · 0ed0a6bb
      Christian Schulte zu Berge authored
      To make it possible to access GlImageResampler's p_resampleScale
      property from Lua, FloatProperty and the classes it depends on have been
      wrapped using SWIG.
      References #1
    • Artur Grunau's avatar
      Finalise the implementation of the first Lua pipeline · 818c79cc
      Artur Grunau authored
      Now that TGT and campvis-core can be built as shared libraries, the few
      remaining issues with the first Lua pipeline could be tracked and fixed.
      As a result, the pipeline can be executed without any issues, and its
      functionality exactly corresponds to that of ResamplingDemo. To achieve
      this, several additional classes, methods and constants had to be
      References #1
    • Artur Grunau's avatar
      Use Lua helper classes to simplify LuaPipeline · 1d99f396
      Artur Grunau authored
      LuaPipeline used to create a Lua VM itself and interact with it
      directly. That caused its code to be unnecassarily bloated and complex as
      it dealt with rather low-level details.
      Delegate the management of Lua VM's state to the recently introduced
      LuaVmState class and use the new table helpers to simplify LuaPipeline.
      References #1
    • Artur Grunau's avatar
      Add several helper classes for accessing Lua state · 4e87e812
      Artur Grunau authored
      Interacting with Lua using its low-level C API quickly becomes cumbersome
      and error-prone. In such cases introducing an object-oriented glue layer
      makes accessing Lua state considerably easier.
      This commit adds several helper classes to campvis-scripting. The abstract
      LuaTable and its concrete sub-classes RegularLuaTable and GlobalLuaTable
      should make working with Lua tables more pleasant by reducing common
      operations to a single method call. LuaVmState's task is to simplify the
      management of Lua VM's state with various high level methods that do
      automatic error checking.
      The new classes are largely undocumented. This will be fixed in a future
      References #1
    • Artur Grunau's avatar
      Work around a bug in SWIG_ADD_MODULE · 59e4f6c7
      Artur Grunau authored
      There's a bug in SWIG_ADD_MODULE that breaks out-of-tree builds by not
      creating wrapper output directories:
      Manually create missing directories for the time being to fix the
      References #1
    • Artur Grunau's avatar
      Lua scripting: rearrange interface files · 382d1c52
      Artur Grunau authored
      All interface files used to live under `scripting/`. However, that
      separated them from the code they were binding and clustered them
      Make each interface file part of the CAMPVis component whose code it's
      binding. This fixes the issues mentioned above and makes it possible to
      build Lua modules conditionally, depending on what components of CAMPVis
      are enabled.
      References #1
    • Artur Grunau's avatar
      Disable BUILD_SHARED_LIBS before processing liblua · 32780169
      Artur Grunau authored
      When Lua is included in the build, its CMakeLists.txt enables
      BUILD_SHARED_LIBS if it isn't explicitly disabled. This breaks the build
      as CMake tries and fails to build all of CAMPVis' libraries as shared
      Disable BUILD_SHARED_LIBS before including `ext/lua` to prevent that.
      Please note that this is a temporary fix; we'd like to eventually build
      Lua and at least some of CAMPVis' libraries as shared libraries.
      References #1
    • Artur Grunau's avatar
      Clean up how CAMPVis' Lua modules are built · 2be90976
      Artur Grunau authored
      There were several problems with how CAMPVis' Lua modules were built:
      - modules were placed in the same directory as all other CAMPVis'
        libraries, which polluted Lua's module path and could lead to name
      - SWIG interface files included instead of importing one another; this
        resulted in duplicated bindings being generated
      To fix these probles place all of CAMPVis' Lua modules in one
      sub-directory and let the code know what that sub-directory is so that
      it can instruct Lua to search it. Moreover, use %import instead of
      %include when one SWIG interface file needs to have access to
      definitions from another one.
      References #1
    • Artur Grunau's avatar
      Make a sample Lua pipeline available to the app · 36d964b1
      Artur Grunau authored
      This commit marks the start of work on making Lua pipelines as easy to
      register and instantiate as regular ones. A sample Lua pipeline has been
      made available to the application so that problems with integrating Lua
      pipelines can be discovered and fixed.
      References #1
    • Artur Grunau's avatar
      Modify processor properties in the test Lua pipeline · 32a7ae10
      Artur Grunau authored
      To check if existing bindings for property classes work, the test Lua
      pipeline has been updated to modify processor properties in its init
      References #1
    • Artur Grunau's avatar
      Wrap several TransferFunction-related classes · e53c9f06
      Artur Grunau authored
      To make it possible to interact with TransferFunctionProperties from
      Lua, several TransferFunction-related classes have been wrapped.
      References #1
    • Artur Grunau's avatar
      Fix how the SWIG run-time header is generated · e117d555
      Artur Grunau authored
      The header with SWIG run-time functions was generated in the PRE_BUILD
      phase which is only fully supported by Visual Studio builds. Add an
      explicit dependency on swigluarun.h to the campvis-scripting target to
      make sure that the former exists before the latter is built.
      References #1