Starting from 2021-07-01, all LRZ GitLab users will be required to explicitly accept the GitLab Terms of Service. Please see the detailed information at https://doku.lrz.de/display/PUBLIC/GitLab and make sure that your projects conform to the requirements.

  1. 23 Mar, 2015 2 commits
    • Christian Schulte zu Berge's avatar
      Two fixes: · 4d134fe3
      Christian Schulte zu Berge authored
      * Fixed signal issues in VolumeRenderer when updating the raycasting processor.
      * Fixed assertions in AutoEvaluationPipeline::onPropertyCollectionPropertyAdded() and AutoEvaluationPipeline::onPropertyCollectionPropertyRemoved().
      
      Conflicts:
      	modules/vis/processors/volumerenderer.cpp
      	modules/vis/processors/volumerenderer.h
      4d134fe3
    • Christian Schulte zu Berge's avatar
      Added AutoEvaluationPipeline also monitoring PropertyCollection's... · a3fa1064
      Christian Schulte zu Berge authored
      Added AutoEvaluationPipeline also monitoring PropertyCollection's s_propertyAdded and s_propertyRemoved signals.
      a3fa1064
  2. 23 Oct, 2014 3 commits
  3. 17 Oct, 2014 2 commits
    • Christian Schulte zu Berge's avatar
      * Tied tgt::OpenGLJobProcessor and tgt::OpenGLGarbageCollector closer together... · a1f23eb3
      Christian Schulte zu Berge authored
      * Tied tgt::OpenGLJobProcessor and tgt::OpenGLGarbageCollector closer together regarding OpenGL garbage collection
      * AutoEvaluationPipeline checks for valid OpenGL state after each processor call (only in debug)
      a1f23eb3
    • Christian Schulte zu Berge's avatar
      Various fixes/improvements · 25e14d19
      Christian Schulte zu Berge authored
      * Fixed AutoEvaluationPipeline missing some updates
      * Fixed AutoEvaluationPipeline::executePipeline() to execute processors too often
      * Fixed ParticleFlowRenderer overwriting bound FBO
      * Added Debug checks to tgt::FramebufferObject and tgt::Shader to print warnings when FBO/Shader activation would overwrite an already active FBO/Shader
      25e14d19
  4. 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
  5. 13 Oct, 2014 1 commit
  6. 08 Aug, 2014 1 commit
  7. 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
  8. 27 Jul, 2014 2 commits
  9. 05 May, 2014 1 commit
  10. 14 Jan, 2014 1 commit
  11. 12 Jan, 2014 1 commit
  12. 13 Dec, 2013 1 commit
  13. 15 Oct, 2013 1 commit
  14. 11 Oct, 2013 1 commit
  15. 09 Oct, 2013 1 commit
  16. 08 Oct, 2013 4 commits
  17. 27 Sep, 2013 1 commit
  18. 25 Sep, 2013 2 commits
    • Christian Schulte zu Berge's avatar
      Revised LQ mode concept for visualization pipelines/processors: · b3913e3d
      Christian Schulte zu Berge authored
      Instead of having the LQ mode tied to the pipeline, each VisualizationProcessor has now a lqMode property effectively halfsampling the viewport size. The TrackballNavigationEventHandler was adapted to these changes and thus simplified.
      b3913e3d
    • Artur Grunau's avatar
      NumericProperty: provide a default step value · 8fcbfb5b
      Artur Grunau authored
      Even though all integer-based properties derived from NumericProperty
      used the same step value, T(1), it had to be specified when
      instantiating them. To reduce boilerplate code in property
      constructors, NumericProperty now uses T(1) as the default step value.
      8fcbfb5b
  19. 24 Sep, 2013 1 commit
  20. 21 Sep, 2013 1 commit
    • Artur Grunau's avatar
      Support setting the step of numeric properties · ec9a8b81
      Artur Grunau authored
      A new attribute has been added to all numeric properties: step value. It
      determines the value of a single increment/decrement that numeric
      property widgets use when their associated properties are modified using
      sliders or spin boxes (users are still able to type any valid property
      value in text edits).
      
      Numerous processors and pipelines had to be updated to work with the
      changed NumericProperty interface. However, choosing a well-suited step
      value for each property can make it easier for users to modify the
      property — using one step value for all properties leads to cases where
      it is either too small, causing users to go through property values
      which don't cause any visible change, or too big, making it difficult to
      quickly determine the right property value.
      ec9a8b81
  21. 04 Sep, 2013 1 commit
  22. 19 Aug, 2013 1 commit
  23. 15 Jul, 2013 1 commit
  24. 24 May, 2013 1 commit
  25. 14 May, 2013 1 commit
  26. 13 Feb, 2013 1 commit
  27. 12 Feb, 2013 1 commit
  28. 08 Feb, 2013 1 commit
  29. 05 Feb, 2013 2 commits