A Framework for Object-Oriented Shader Design

Kuck, Roland; Wesche, Gerold

doi:10.1007/978-3-642-10331-5_95

Cited by 6 publications

(3 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…If the tessellation (HS and DS) stages are also disabled, then all computation on the different flavors of vertices will be executed in the VS stage. This design has similar properties to the shader framework of Kuck and Wesche [2009], where operations defined in the "Post Geometry" stage are executed in the VS if no GS effect is active.…”

Section: Move Computations When Pipeline Stages Are Disabledmentioning

confidence: 40%

See 1 more Smart Citation

Spark

Foley

Hanrahan

2011

ACM SIGGRAPH 2011 Papers

View full text Add to dashboard Cite

Animation Tessellation Render to Cube Vertex Colors Displacement Texture Mapping VS HS DS GS PS Figure 1: A complex shading effect decomposed into user-defined modules in Spark. The dashed boxes show the programmable stages of the Direct3D 11 pipeline; the colored boxes show different concerns in the program. Some logical concerns cross-cut multiple pipeline stages. AbstractIn creating complex real-time shaders, programmers should be able to decompose code into independent, localized modules of their choosing. Current real-time shading languages, however, enforce a fixed decomposition into per-pipeline-stage procedures. Program concerns at other scales -including those that cross-cut multiple pipeline stages -cannot be expressed as reusable modules.We present a shading language, Spark, and its implementation for modern graphics hardware that improves support for separation of concerns into modules. A Spark shader class can encapsulate code that maps to more than one pipeline stage, and can be extended and composed using object-oriented inheritance. In our tests, shaders written in Spark achieve performance within 2% of HLSL.

show abstract

Section: Move Computations When Pipeline Stages Are Disabledmentioning

confidence: 40%

“…Effect systems [NVIDIA 2010;Microsoft 2010b;Lalonde and Schenk 2002] allow a set of per-stage shaders to be encapsulated, but do not address program concerns at other scales. Shader metaprogramming frameworks [McCool et al 2002;Lejdfors and Ohlsson 2004;Kuck and Wesche 2009] apply host-language abstractions to shaders.…”

Section: Cg Hlsl Glslmentioning

confidence: 44%

Spark

Foley

Hanrahan

2011

ACM SIGGRAPH 2011 Papers

View full text Add to dashboard Cite

show abstract

“…Similarly, Kuck et al [KW09] specialize shaders at run time using C++ classes as an abstraction layer. Again, the adaptation logic is fixed at compile time of the application and cannot be altered by the shader author.…”

Section: Related Workmentioning

confidence: 99%

shade.js: Adaptive Material Descriptions

Sons

Klein

Sutter

et al. 2014

Computer Graphics Forum

View full text Add to dashboard Cite

Figure 1: A collection of procedural materials written in shade.js and rendered in WebGL using forward shading (upper left), deferred shading (upper right), Blender Cycles ray-traced (lower left), and with global illumination (lower right). We achieve conceptually equal materials for all four rendering techniques. AbstractIn computer graphics a material is a visual concept that is parameterizable and should work for arbitrary 3D assets and rendering systems. Since provided parameters and attributes as well as the capabilities of rendering systems vary considerably, a material needs to adapt to its execution environment. In current approaches, the adaptation logic is 'baked' into the rendering application based on string manipulation, compiler directives, or metaprogramming facilities. However, in order to achieve application-independent and self-contained material descriptions, the adaptation logic needs to be part of the material description itself. In this paper we present shade.js, a novel material description using a dynamic language to achieve the necessary adaptivity. A shader can inspect its execution environment and adapt to the available parameters and renderer capabilities at run time. Additionally, shade.js exploits the polymorphism that comes with non-explicit declaration of types. These two novel features allow for writing adaptable and thus more general material descriptions. Based on the concrete execution environment at run time, the accompanied compiler generates specialized shader code that is specifically typed and optimized for the target rendering system and algorithm. We evaluate shade.js with examples targeting four different rendering approaches (forward and deferred rasterization, ray-tracing, and global illumination). We show that we can improve convenience and flexibility for specifying materials without sacrificing performance.

show abstract