2.12.2021, 9:00 - 11:00: Due to updates GitLab may be unavailable for some minutes between 09:00 and 11:00.

  1. 17 Oct, 2014 1 commit
  2. 15 Oct, 2014 2 commits
    • Christian Schulte zu Berge's avatar
      Moved AbstractJob and OpenGLJobProcessor from campvis-core to tgt and adapted... · fb8b1880
      Christian Schulte zu Berge authored
      Moved AbstractJob and OpenGLJobProcessor from campvis-core to tgt and adapted and cleaned up all necessary includes/references.
      fb8b1880
    • Christian Schulte zu Berge's avatar
      Started refactoring the CAMPVis OpenGL Wrapping API: · 58512d30
      Christian Schulte zu Berge authored
      The new OpenGL wrapping API allows for full multi-threaded access to OpenGL contexts. Instead of one single thread scheduling all OpenGL jobs for all contexts, the new GlContextManager allows for OpenGL access from multiple threads while ensuring that each OpenGL context is acquired by only one thread at a time.
      
      Detailed list of changes:
      * tgt::GlContextManager keeping track of which threads acquire which OpenGL contexts and which threads currently have a context acquired.
      * OpenGLJobProcessor does no longer schedules and execute the OpenGL calls for all existing contexts, but only for one single context that can be used for background tasks or other jobs that explicitly need a valid OpenGL context.
      * AbstractPipeline now implements the Runnable interface and thus runs in it's own thread. This thread also owns the pipeline's OpenGL context.
      * AbstractPipeline has a new pure virtual method executePipeline() that has to perform all computations done by the pipeline.
      * AbstractPipeline now takes directly care of calling Painter::paint() of the pipeline's canvas (instead of signalling the Painter). However, the Painter interface needs further cleanup.
      * AutoEvaluationPipeline was adapted to the new AbstractPipeline API, hence executing processors is no longer delegated to the OpenGLJobProcessor or the SimpleJobProcessor but entirely done in AutoEvaluationPipeline::executePipeline() and thus in the pipeline's thread.
      * Adjusted CampVisApplication, DataContainerInspectorWidget, and GeometryTransferFunctionEditor to the new API.
      58512d30
  3. 08 Oct, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Improved CAMPVis deployment: · 665c2036
      Christian Schulte zu Berge authored
      Added directories of various needed resources (textures, sampledata) to the CampvisShaderDirectories CMake variable, which is used for deployment. Replaced various occurences of CAMPVIS_SOURCE_DIR with ShdrMgr.completePath().
      665c2036
  4. 30 Sep, 2014 2 commits
  5. 07 Aug, 2014 1 commit
  6. 03 Aug, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Finished work on implementing asynchroneous signals: · bc11fde2
      Christian Schulte zu Berge authored
      * Slight changes to the API: renamed signal::trigger() to signal::triggerSignal() and signal::queue() to signal::queueSignal()
      * Replaced all sigslot signal emits through operator() with emits through emitSignal() to enable debug feature.
      * Fixed a possible race condition when deleting a GeometryTransferFunction and its editor window at the same time (as this will happen from different threads).
      
      refs #384
      bc11fde2
  7. 27 Jul, 2014 2 commits
    • Christian Schulte zu Berge's avatar
      Started working on Issue implementing asynchroneous signals with signalslot: · 30e14065
      Christian Schulte zu Berge authored
      * Moved campvis::Runnable interface to tgt namespace (since it's needed by sigslot, which only depends on tgt)
      * Introduced sigslot::signal_manager singleton class that will manage the dispatching of signals in its own thread
      * Started proof-of-concept implementation of asynchroneous signals for signal0<> and signal1<>. Both classes define their own signal_handleN deriving from _signal_handle_base, which defines the signal to dispatch.
      
      Proof-of-concept implementation seems to work so far.
      
      refs #384
      
      Conflicts:
      	core/tools/opengljobprocessor.h
      	ext/tgt/runnable.h
      
      Conflicts:
      	application/CMakeLists.txt
      	core/tools/opengljobprocessor.h
      30e14065
    • Christian Schulte zu Berge's avatar
      Introducing C++11 support switch for <thread> and <condition_variable>. · c488b267
      Christian Schulte zu Berge authored
      If you need one of these two C++11 headers, include <ext/threading.h> instead, which will use C++11 headers if present or TBB's compatibility layer otherwise.
      
      closes #567
      c488b267
  8. 10 Jul, 2014 1 commit
  9. 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.
      f1b3cd9a
  10. 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.
      a33ee468
  11. 10 May, 2014 2 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
      ResamplingDemoLua.
      
      References #1
      c2348225
    • 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
      36d964b1
  12. 05 May, 2014 2 commits
  13. 24 Apr, 2014 1 commit
  14. 13 Feb, 2014 1 commit
  15. 07 Feb, 2014 1 commit
  16. 06 Feb, 2014 1 commit
  17. 15 Jan, 2014 1 commit
  18. 13 Jan, 2014 1 commit
  19. 02 Jan, 2014 1 commit
  20. 13 Dec, 2013 1 commit
  21. 15 Oct, 2013 2 commits
  22. 11 Oct, 2013 1 commit
  23. 09 Oct, 2013 1 commit
  24. 08 Oct, 2013 6 commits
  25. 27 Sep, 2013 1 commit
  26. 10 Sep, 2013 1 commit
  27. 04 Sep, 2013 1 commit
  28. 29 Aug, 2013 1 commit
    • Christian Schulte zu Berge's avatar
      Branching work to introduce new FBO handling concept: · 42480c65
      Christian Schulte zu Berge authored
       * each VisualizationProcessor manages its own FBO
       * instead of creating a whole new FBO each process(), the processors shall only create and attach textures to the FBO
       * the FramebufferActivationGuard offers automatic (de)activation and detachment of all textures
      
      SimpleRaycaster already uses the new concept, the rest still uses the legacy API
      42480c65
  29. 19 Aug, 2013 1 commit