An update will be applied today, Nov30th, between 12PM and 1:00PM EST (UTC -5:00). The site may be slow during that time.

  1. 05 Nov, 2009 1 commit
    • whitlocb's avatar
      I could not get around build problems related to rendering_visit_vtk depending · 1b475a32
      whitlocb authored
      on avtPlotter on my cmake branch due avt::glew::initialize. I'm not using 
      -unresolved,dynamic_lookup for gcc which lets the linker skip unresolved 
      symbols. I find this is a good test for measuring compatibility with Windows, 
      which is our most strict platform. CMake dependencies will need to remain strict
      to ensure that the code continues to build on Windows.
      
      The problem is where to put avt::glew::initialize. Since it relies on
      state from avtCallbacks, it makes sense to keep it in avt. This is why I did
      not move avt::glew::initialize into rendering_visit_vtk. Anyway, I decided to
      move rendering_visit_vtk and parallel_visit_vtk into the avtPlotter library 
      itself so the vtkMappers can use avt::glew::initialize without introducing bad
      library dependencies. Plot plugins also use avt::glew::initialize but, as plots,
      they already have avtPlotter dependencies so it's okay. Moving 
      parallel_visit_vtk also helps with a library dependency problem for parallel.
      If I remember correctly, it had a dependence on avtPipeline. Coupled with
      Makefile LIBS= updates we can now build in parallel without the 
      -unresolved,dynamic_lookup options on the Mac.
      
      While I was at it, I removed the engine/parstate library, moving MPIXfer into
      the engine. The other part of engine/parstate was deprecated in 1.12.0 so the
      library did not have much reason to exist.
      
      Not much is different from a Linux point of view other than we have 3 fewer
      libraries now.
      
      
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@8845 18c085ea-50e0-402c-830e-de6fd14e8384
      1b475a32
  2. 03 Nov, 2009 1 commit
  3. 04 Aug, 2009 1 commit
    • brugger's avatar
      · 546e8915
      brugger authored
      1) I changed the year in the copyright notice from 2008 to 2009 in a
         bunch of files. A total of 5231 files were changed.
      
      2) I corrected the LLNL review and release number in the copyright notices.
         It turns out I transposed 2 of the digits in many of the files when I
         originally put the new copyright notice in.
      
      
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@8045 18c085ea-50e0-402c-830e-de6fd14e8384
      546e8915
  4. 01 Aug, 2009 3 commits
  5. 22 Jul, 2009 2 commits
  6. 20 Jul, 2009 2 commits
  7. 17 Jul, 2009 1 commit
  8. 02 Jul, 2009 7 commits
  9. 30 Jun, 2009 1 commit
  10. 27 Jun, 2009 1 commit
  11. 26 Jun, 2009 2 commits
  12. 25 Jun, 2009 1 commit
  13. 19 Jun, 2009 1 commit
  14. 18 Jun, 2009 1 commit
  15. 17 Jun, 2009 2 commits
  16. 15 Jun, 2009 1 commit
  17. 12 Jun, 2009 1 commit
  18. 28 May, 2009 2 commits
    • fogal1's avatar
      Invalidate the transparency cache earlier. · c3c6e49c
      fogal1 authored
      In some cases, we'd render earlier than expected, before getting
      through RenderSetup.  The cache would be at it's old value then
      (except on first renderings!), and wouldn't know to recalculate.
      By invalidating here, we'll force this to get recalculated if some
      code needs to know about transparencies before RenderSetup
      completes.
      
      AFAICT, this also means that `simple' re-renders, such as rotating
      the volume, will cause the calculation (and ensuing global
      communication) to occur.  This is undesirable, but no worse than a
      week ago.
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7441 18c085ea-50e0-402c-830e-de6fd14e8384
      c3c6e49c
    • fogal1's avatar
      Make an image dump happen sooner. · 90f0665f
      fogal1 authored
      It was giving misleading results before.  We were dumping images
      after we did our opaque composite, but also after we'd broadcast
      out the resultant image to image-less nodes.  This meant that
      nodes that didn't render anything looked as if they rendered the
      entire volume.
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7440 18c085ea-50e0-402c-830e-de6fd14e8384
      90f0665f
  19. 27 May, 2009 3 commits
  20. 25 May, 2009 2 commits
    • fogal1's avatar
      Do ad hoc memoization of the transparency calculation. · d7c4a728
      fogal1 authored
      In some SR mode configurations, we have the issue that rendering
      will involve global communication due to the need to sort
      transparent geometry.  This is undesirable because 1) we don't
      know the sort order until rendering is underway, thus preventing
      us from using that knowledge for more intelligent compositing, and
      2) certain compositors, such as IceT, do not call our render
      method synchronously in all cases, leading to deadlock in the
      worst case.
      
      This commit changes the transparency actor so that it keeps an
      internal cache of the transparency calculation.  Clients are now
      expected to clear ("Invalidate") the cache periodically.  In SR
      mode we'll do that once per render.  In standard rendering modes,
      we'll invalidate the cache every time we add a plot to the window.
      
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7402 18c085ea-50e0-402c-830e-de6fd14e8384
      d7c4a728
    • fogal1's avatar
      Minor formatting / alignment change. · b0804c78
      fogal1 authored
      git-svn-id: http://visit.ilight.com/svn/visit/trunk/src@7400 18c085ea-50e0-402c-830e-de6fd14e8384
      b0804c78
  21. 04 May, 2009 2 commits
  22. 30 Apr, 2009 1 commit
  23. 24 Apr, 2009 1 commit