1. 05 Dec, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Completely refactored and cleaned up cgt::Texture interface: · 3df24932
      Christian Schulte zu Berge authored
      * cleaned up cgt::Texture's constructors: only two left - to create an empty texture or a non-empty one
      * cgt::Texture will no longer hold a copy of the image data in local memory
      * removed a lot of redundant/confusing methods
      * no longer needed to call uploadTexture() even though you don't want to upload sth.
      * Adapted all known code to the new interface
      * Removed cgt::TextureReaderDevil
      
      refs #613
      3df24932
  2. 17 Nov, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Some work on AdvancedUsVis module: · f67886eb
      Christian Schulte zu Berge authored
      * Introducing PredicateDemoSmallHeart pipeline draft.
      * Fixed double signal callback registration in predicate-based rendering demo pipelines.
      * Fixed PredicateVolumeExplorer not re-rendering when predicate histogram property changed.
      * Disabled hiding of Add Predicate buttons in pointpredicatehistogrampropertywidget.cpp
      f67886eb
  3. 24 Oct, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Finished work on refactoring the camera API · 3c921952
      Christian Schulte zu Berge authored
      * Removed CameraProperty, CameraPropertyWidget and TrackballNavigationEventListener
      * replaces all known occurrences of the above three with the new TrackballCameraProvider processor
      * introduced TrackballCameraProvider::reinitializeCamera()
      
      refs #141
      3c921952
  4. 23 Oct, 2014 2 commits
  5. 22 Oct, 2014 1 commit
  6. 08 Aug, 2014 2 commits
    • Christian Schulte zu Berge's avatar
    • Christian Schulte zu Berge's avatar
      Refactoring SliceExtractor processor: · b7817eb2
      Christian Schulte zu Berge authored
      To better support sharing the functionality of slice rendering, the SliceExtractor processor was refactored: Similar to the RaycastingProcessor, the main functionality was moved to an abstract base class, the SliceRenderProcessor. This takes care of computing all the necessary transformation matrices, optionally rendering crosshair and integrating geometry, as well as handling user input to support scribbling. The actual SliceExtractor processor now only implements the rendering of the slice itself, i.e. applying the transfer function.
      
      In this regard, VolumeExplorer was updated to use the generic SliceRenderProcessor, and TransFuncWindowingEventListener supports changing of its assigned property.
      b7817eb2
  7. 27 Jul, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Streamlined AbstractProcessor API: · 36ab435a
      Christian Schulte zu Berge authored
      INVALID_RESULT, INVALID_PROPERTIES, INVALID_SHADER is validated automatically by AbstractProcessor::process(). Hence, there is finally no need anymore to validate these three different levels in each processor.
      36ab435a
  8. 05 May, 2014 2 commits
  9. 22 Apr, 2014 1 commit
  10. 07 Apr, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Moved invalidation level from AbstractProperty to AbstractProcessor: · 293d43dd
      Christian Schulte zu Berge authored
      To now, each property hat an _invalidationLevel field that was evaluated by processors when the property had changed in order to determine what has to be done. However, since properties could also be owned by other classes, this design was semantically misleading.
      Therefore, it was removed with this commit and replaced by the invalidation map of each processor. Now, this per-processor mapping of property -> invalidation level is managed by the processor itself. Furthermore, the invalidation level is no longer setup during property creation but during AbstractProcessor::addProperty(), which also makes much more sense.
      
      ATTENTION: Due to these intrusive API changes, the code of all processors and other classes handling properties needs to be changed. As a reminder, the implementation of addProperty() also now takes a reference instead of a pointer, so that old code does no longer compile.
      
      refs #542
      293d43dd
  11. 06 Apr, 2014 2 commits
  12. 23 Jan, 2014 2 commits
  13. 13 Jan, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Fixing commit 5f72759e: · 56724724
      Christian Schulte zu Berge authored
      C++ implicit conversion rules made ShaderManager::loadSeparate() ambiguous in some cases. So I decided to cut loose ends and completely refactored loading with standard version into ShaderManager::load() and loading with custom version into ShaderManager::loadWithCustomGlslVersion().
      ShaderManager::loadSeparate() is no longer available!
      56724724
  14. 08 Jan, 2014 1 commit
    • Christian Schulte zu Berge's avatar
      Refactoring AbstractProcessor::process() for clearer semantics and better and... · cd9d3feb
      Christian Schulte zu Berge authored
      Refactoring AbstractProcessor::process() for clearer semantics and better and more uniform handling of invalidation levels:
       * AbstractProcessor::process() now calls updateShader(), updateProperties() and/or updateResult() with respect to the current invalidation level
       * each processor shall no longer override process() but the updateXYZ() methods, at minimum updateResult()
       * AbstractProcessor::process() takes care of (un)locking the processor itself (no need to do this from the outside anymore)
      
      Further implicit changes:
       * Removed redundant HasPropertyCollection::updateProperties()
      cd9d3feb
  15. 13 Dec, 2013 1 commit
  16. 15 Oct, 2013 2 commits
  17. 08 Oct, 2013 2 commits
  18. 27 Sep, 2013 1 commit
  19. 25 Sep, 2013 2 commits
    • Artur Grunau's avatar
      FloatingPointProperty: provide a default step value · 4853ed7d
      Artur Grunau authored
      Even though many float-based properties derived from
      FloatingPointProperty used the same step value, T(0.01), it had to be
      specified when instantiating them. To reduce boilerplate code in
      property constructors, FloatingPointProperty now uses T(0.01) as the
      default step value.
      4853ed7d
    • 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
  20. 24 Sep, 2013 2 commits
    • Christian Schulte zu Berge's avatar
      work on #135: changed VisualizationProcessor::_renderTargetSize to pointer and... · ec04c28e
      Christian Schulte zu Berge authored
      work on #135: changed VisualizationProcessor::_renderTargetSize to pointer and introducing VisualizationProcessor::setViewportSizeProperty()
      ec04c28e
    • Artur Grunau's avatar
      Update the typedefs of floating point properties · f318af5c
      Artur Grunau authored
      Floating point properties were previously typedef'd to specific
      instantiations of NumericProperty. Now that we have
      FloatingPointProperty, which extends NumericProperty to control how many
      decimal places should be shown when displaying the property's value, all
      typedefs for floating point properties have been updated to point to it
      instead.
      
      As a result, many processors and pipelines needed to have their includes
      and/or constructors fixed to import and work with the new typedefs.
      f318af5c
  21. 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
  22. 17 Sep, 2013 1 commit
  23. 05 Sep, 2013 1 commit
  24. 04 Sep, 2013 1 commit
  25. 05 May, 2013 1 commit
  26. 11 Apr, 2013 1 commit
  27. 23 Feb, 2013 1 commit
  28. 19 Feb, 2013 1 commit
  29. 13 Feb, 2013 1 commit
  30. 12 Feb, 2013 2 commits