1. 13 Dec, 2017 2 commits
  2. 29 Sep, 2016 1 commit
  3. 05 Sep, 2016 1 commit
  4. 05 Jul, 2016 1 commit
    • Jakob Weiss's avatar
      Usage example for reusable data · 079e0bb3
      Jakob Weiss authored
      Very crude demonstration, mainly to prove that everything compiles and (probably?) works as intended. No writable image representations, hence the weird loopholes to remove the representations from the representations list. No deadlocks! yaay!
      079e0bb3
  5. 20 Jul, 2015 1 commit
  6. 16 Jan, 2015 1 commit
  7. 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
  8. 24 Oct, 2014 3 commits
  9. 23 Oct, 2014 2 commits
  10. 09 Oct, 2014 1 commit
  11. 05 May, 2014 1 commit
  12. 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
  13. 13 Jan, 2014 1 commit
  14. 13 Dec, 2013 1 commit
  15. 05 Dec, 2013 1 commit
  16. 28 Nov, 2013 2 commits
  17. 15 Oct, 2013 2 commits
  18. 25 Sep, 2013 1 commit
  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. 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
  23. 12 Feb, 2013 1 commit
  24. 02 Nov, 2012 1 commit
  25. 31 Oct, 2012 1 commit
  26. 26 Oct, 2012 1 commit
  27. 10 Aug, 2012 1 commit
  28. 03 Aug, 2012 1 commit
  29. 24 Jul, 2012 1 commit
  30. 18 Jul, 2012 1 commit
    • schultezub's avatar
      One huge commit including: · 9130371f
      schultezub authored
      Major revisions to the class layout / data structure:
       * Introduced ImageDataConverter interface (still not really happy with the design)
       * Removed support for Int64 and double images from WeaklyTypedPointer
       * Added ImageDataGL::bind()
       * AbstractProcessor::init() method, gets called by AbstractPipeline::init()
       * added VisualizationProcessor
      
      Updated/New processors:
       * fixed MhdImageReader
       * SliceExtractor stub for very simple slice rendering
      
      Various fixes:
       * DataContaier: managing of DataHandle ownership
       * GenericImageDataLocal::getSubImage()
       * ImageDataRenderTarget bindings
       * GenericProperty
       * linking issues with StringUtils
      
      Hence, all this enables the first usable implementation of a specific pipeline:
      The SliceVis pipeline combines MhdImageReader and SliceExtractor for a very simple 2D slice rendering
      
      git-svn-id: https://camplinux.in.tum.de/svn/campvis/trunk@188 bb408c1c-ae56-11e1-83d9-df6b3e0c105e
      9130371f