GitLab

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

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
wrapped.

References #1

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

All interface files used to live under `scripting/`. However, that
separated them from the code they were binding and clustered them
unnecessarily.

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

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
  clashes
- 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

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

To check if existing bindings for property classes work, the test Lua
pipeline has been updated to modify processor properties in its init
method.

References #1

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

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

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:
https://github.com/badshah400/swig/commit/ea4a4e435f721380555fea039bd5dc758eda43ae

References #1

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.