1. 25 Jul, 2019 1 commit
  2. 15 Jul, 2019 1 commit
  3. 04 Jul, 2019 1 commit
  4. 14 May, 2019 1 commit
  5. 22 Apr, 2019 1 commit
  6. 25 Jan, 2019 1 commit
  7. 08 Jan, 2019 1 commit
  8. 16 Aug, 2018 2 commits
  9. 31 Jul, 2018 3 commits
  10. 30 Jul, 2018 1 commit
    • Graham Linden's avatar
      MAINT-8915 · 60d256e8
      Graham Linden authored
      Fix sync of material rotation and offset values when using aligned planar faces.
      
      Make it possible to set a specific TE's normal/spec offset/rotation values.
      
      Eliminate redundant conversions in LLSD -> struct handler.
      60d256e8
  11. 19 Jul, 2018 1 commit
  12. 18 Jul, 2018 1 commit
  13. 16 Jul, 2018 1 commit
  14. 23 Apr, 2018 1 commit
  15. 25 Apr, 2018 1 commit
  16. 16 Nov, 2017 2 commits
  17. 08 Nov, 2017 1 commit
  18. 01 Nov, 2017 1 commit
  19. 26 Oct, 2017 1 commit
  20. 29 Sep, 2017 1 commit
  21. 22 Sep, 2017 1 commit
  22. 04 Aug, 2017 1 commit
  23. 19 Jul, 2017 1 commit
  24. 17 Jul, 2017 1 commit
  25. 13 Jul, 2017 1 commit
  26. 30 Mar, 2017 1 commit
    • Nat Goodspeed's avatar
      DRTVWR-418: Xcode 8.3 complains about LLSafeHandle<T> implementation. · e9fe0714
      Nat Goodspeed authored
      The previous LLSafeHandle<T> implementation declares a static data member of
      the template class but provides no (generic) definition, relying on particular
      specializations to provide the definition. The data member is a function
      pointer, which is called in one of the methods to produce a pointer to a
      "null" T instance: that is, a dummy instance to be dereferenced in case the
      wrapped T* is null.
      
      Xcode 8.3's version of clang is bothered by the call, in a generic method,
      through this (usually) uninitialized pointer. It happens that the only
      specializations of LLSafeHandle do both provide definitions. I don't know
      whether that's formally valid C++03 or not; but I agree with the compiler: I
      don't like it.
      
      Instead of declaring a public static function pointer which each
      specialization is required to define, add a protected static method to the
      template class. This protected static method simply returns a pointer to a
      function-static T instance. This is functionally similar to a static
      LLPointer<T> set on demand (as in the two specializations), including lazy
      instantiation.
      
      Unlike the previous implementation, this approach prohibits a given
      specialization from customizing the "null" instance function. Although there
      exist reasonable ways to support that (e.g. a related traits template), I
      decided not to complicate the LLSafeHandle implementation to make it more
      generally useful. I don't really approve of LLSafeHandle, and don't want to
      see it proliferate. It's not clear that unconditionally dereferencing
      LLSafeHandle<T> is in any way better than conditionally dereferencing
      LLPointer<T>. It doesn't even skip the runtime conditional test; it simply
      obscures it. (There exist hints in the code that at one time it might have
      immediately replaced any wrapped null pointer value with the pointer to the
      "null" instance, obviating the test at dereference time, but this is not the
      current functionality. Perhaps it was only ever wishful thinking.)
      
      Remove the corresponding functions and static LLPointers from the two classes
      that use LLSafeHandle.
      e9fe0714
  27. 13 Mar, 2017 1 commit
  28. 23 Feb, 2017 1 commit
  29. 15 Feb, 2017 1 commit
  30. 27 Jan, 2017 1 commit
  31. 25 Jan, 2017 1 commit
  32. 30 Nov, 2016 1 commit
  33. 21 Oct, 2016 1 commit
  34. 05 Aug, 2016 1 commit
  35. 11 Jan, 2016 1 commit
  36. 08 Dec, 2015 1 commit