|
| 1 | +////////////////////////////////////////////////////////////////////////// |
| 2 | +// |
| 3 | +// Copyright (c) 2025, Image Engine Design Inc. All rights reserved. |
| 4 | +// |
| 5 | +// Redistribution and use in source and binary forms, with or without |
| 6 | +// modification, are permitted provided that the following conditions are |
| 7 | +// met: |
| 8 | +// |
| 9 | +// * Redistributions of source code must retain the above copyright |
| 10 | +// notice, this list of conditions and the following disclaimer. |
| 11 | +// |
| 12 | +// * Redistributions in binary form must reproduce the above copyright |
| 13 | +// notice, this list of conditions and the following disclaimer in the |
| 14 | +// documentation and/or other materials provided with the distribution. |
| 15 | +// |
| 16 | +// * Neither the name of Image Engine Design nor the names of any |
| 17 | +// other contributors to this software may be used to endorse or |
| 18 | +// promote products derived from this software without specific prior |
| 19 | +// written permission. |
| 20 | +// |
| 21 | +// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS |
| 22 | +// IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, |
| 23 | +// THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR |
| 24 | +// PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR |
| 25 | +// CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, |
| 26 | +// EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, |
| 27 | +// PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR |
| 28 | +// PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF |
| 29 | +// LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING |
| 30 | +// NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS |
| 31 | +// SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. |
| 32 | +// |
| 33 | +////////////////////////////////////////////////////////////////////////// |
| 34 | + |
| 35 | +#ifndef IECORE_RAMP_H |
| 36 | +#define IECORE_RAMP_H |
| 37 | + |
| 38 | +#include "IECore/Export.h" |
| 39 | +#include "IECore/Spline.h" |
| 40 | +#include "IECore/MessageHandler.h" |
| 41 | + |
| 42 | +IECORE_PUSH_DEFAULT_VISIBILITY |
| 43 | +#include "Imath/ImathColor.h" |
| 44 | +IECORE_POP_DEFAULT_VISIBILITY |
| 45 | + |
| 46 | +#include <map> |
| 47 | + |
| 48 | +namespace IECore |
| 49 | +{ |
| 50 | + |
| 51 | +// This lives outside the class because we don't want multiple incompatible templated versions of |
| 52 | +// the same enum floating around |
| 53 | +enum class RampInterpolation |
| 54 | +{ |
| 55 | + Linear = 0, |
| 56 | + CatmullRom = 1, |
| 57 | + BSpline = 2, |
| 58 | + MonotoneCubic = 3, |
| 59 | + Constant = 4, |
| 60 | +}; |
| 61 | + |
| 62 | +/// A Ramp represents a spline-like curve as it is represented in a simple UI: with a set of independent |
| 63 | +/// control points, and an interpolation type selected from RampInterpolation. |
| 64 | +/// |
| 65 | +/// Rather than storing the lower level IECore::Spline*, we now store this Ramp type in shader networks, |
| 66 | +/// and only convert to the lower level class with the evaluator() function when evaluation is needed. |
| 67 | +template<typename X, typename Y> |
| 68 | +class IECORE_EXPORT Ramp |
| 69 | +{ |
| 70 | + |
| 71 | +public : |
| 72 | + |
| 73 | + typedef X XType; |
| 74 | + typedef Y YType; |
| 75 | + |
| 76 | + typedef CubicBasis<XType> Basis; |
| 77 | + typedef std::multimap<X, Y> PointContainer; |
| 78 | + typedef typename PointContainer::value_type Point; |
| 79 | + |
| 80 | + |
| 81 | + |
| 82 | + Ramp() : interpolation( RampInterpolation::CatmullRom ) |
| 83 | + { |
| 84 | + } |
| 85 | + |
| 86 | + Ramp( const PointContainer &p, RampInterpolation i ) |
| 87 | + : points( p ), interpolation( i ) |
| 88 | + { |
| 89 | + } |
| 90 | + |
| 91 | + PointContainer points; |
| 92 | + RampInterpolation interpolation; |
| 93 | + |
| 94 | + |
| 95 | + // Convert to Cortex Spline |
| 96 | + // In the future, IECore::Spline may be replaced with IECore::SplineEvaluator, and this |
| 97 | + // function would be the only way to setup one. |
| 98 | + IECore::Spline<X, Y> evaluator() const; |
| 99 | + |
| 100 | + // In order to write shader parameters to renderers or USD, we need to convert Ramps to a convention |
| 101 | + // that can be stored in raw OSL. Based on the arguments to the OSL spline() function, we've come up |
| 102 | + // with a convention for storing a string basis and separate position and value arrays, where the |
| 103 | + // the position and value arrays contain any duplicated end points necessary for the resulting OSL |
| 104 | + // spline to cover the full range of the ramp. |
| 105 | + // |
| 106 | + // These functions convert to and from this convention ( and can also be used for converting from other |
| 107 | + // similar conventions with some pre-processing ). |
| 108 | + // |
| 109 | + // NOTE: Some aspects of the convention we've picked are not actually very universal. We haven't |
| 110 | + // found any shader's in the wild that actually expect duplicated end point ( aside from Gaffer's |
| 111 | + // shader library ). Other shader authors seem to be implementing their own spline functions that don't |
| 112 | + // require duplicated endpoints ( 3delight ), or put code to perform the duplication in their shader |
| 113 | + // before calling spline ( PRMan ). We've stuck to duplicating the end points because unnecessarily |
| 114 | + // duplicating endpoints doesn't cause any problems other than being a minor waste of performance. |
| 115 | + // It seems like there's an argument that the best approach would be to put the endpoint duplication |
| 116 | + // inside the shader like PRMan, but this is working fine for now. |
| 117 | + void fromOSL( const std::string &basis, const std::vector<X> &positions, const std::vector<Y> &values, const std::string &identifier ); |
| 118 | + void toOSL( std::string &basis, std::vector<X> &positions, std::vector<Y> &values ) const; |
| 119 | + |
| 120 | + // If there are connections to a Ramp, and we convert it to the OSL convention with duplicated endpoints, |
| 121 | + // then the connections will need to be offset to match - this defines the offset. |
| 122 | + int oslAdaptorOffset() const; |
| 123 | + |
| 124 | + // In Cortex 10.6 and earlier, shader parameters were represented uing IECore::Spline*Data instead of |
| 125 | + // IECore::Ramp*Data. This is used in converting SCC files to the new standard. |
| 126 | + // \todo : This can probably be removed in the next major version - we're not actually aware of any |
| 127 | + // significant users of Cortex who both use SCC files, and cache shaders, so this compatibility shim |
| 128 | + // is only needed theoretically. |
| 129 | + void fromDeprecatedSpline( const IECore::Spline<X, Y> &deprecated ); |
| 130 | + |
| 131 | + bool operator==( const Ramp<X,Y> &rhs ) const; |
| 132 | + bool operator!=( const Ramp<X,Y> &rhs ) const; |
| 133 | + |
| 134 | +}; |
| 135 | + |
| 136 | +using Rampff = Ramp<float, float>; |
| 137 | +using RampfColor3f = Ramp<float, Imath::Color3f>; |
| 138 | +using RampfColor4f = Ramp<float, Imath::Color4f>; |
| 139 | + |
| 140 | +template<typename X, typename Y> |
| 141 | +inline void murmurHashAppend( IECore::MurmurHash &h, const Ramp<X,Y> &data ) |
| 142 | +{ |
| 143 | + h.append( data.interpolation ); |
| 144 | + for ( auto &p : data.points ) |
| 145 | + { |
| 146 | + h.append( p.first ); |
| 147 | + h.append( p.second ); |
| 148 | + } |
| 149 | +} |
| 150 | + |
| 151 | +} // namespace IECore |
| 152 | + |
| 153 | +#endif // IECORE_RAMP_H |
0 commit comments