From K-3D

K-3D Shader Development Road Map

FIRST DRAFT.

The importance of Shading is often overlooked in favour of Geometry, however due to computational constrains on rendering methods and geometry complexity, much of a final frame's look is the result of ingenious shading and post processing. For reference see any of the Pixar authored SIGGRAPH documents or the how-to documentaries that often accompany movies on DVD.

Given the importance of Shading, and the rapid progression of the geometric capabilities of K-3D the time has come to focus some of our efforts on optimising the collection of shaders that are distributed with K-3D, the tools and libraries for writing them and how shaders are managed within the application.

The shaders fall into the following categories, in order of importance:

1. Surface

2. Light source

3. Displacement

4. Volume

5. Imager

The following tasks must be completed in order to maximise the usability of shaders in K-3D

STAGE ONE.

Test and RenderMan_Shaders document the current state of all shaders,

1. Their intended purpose,

2. the terms used in their variables,

3. internal and included functions,

4. and if any, their render engine specificity.

Document the schema for the *.slmeta files produced by k3d-sl2xml. Investigate and expand the functionality of k3d-sl2xml.

STAGE TWO.

Fix all current shaders using minimum effort required to get them working, in particular ensure that header files are successfully included during shader compilation, this is failing in a lot of shaders at the moment.

Edit all existing shaders to maximise the quality of output from k3d-sl2xml.

Rewrite all existing .slmeta files to maximise the benefits of recent improvements in the format.

Document the functionality of each shader and produce example files and tutorials if required.

• • Having done the above we will have nothing more than we have now, except that it will be fully functional, coherent and documented. i.e. end user friendly.

STAGE THREE

Formulate a common set of terms, functions and sub routines used in all shaders.

Move all reusable code into a well documented library of header files.

Rewrite all shaders to use unified terms for variable names and replace relevant code with library function calls.

Add debugging code to all shaders, write library code to facilitate this.

At this stage similar shaders should be consolidated into a single shader that is sufficiently parametric to allow for multiple related effects.

Produce the saved objects that hold the shader variable configuration sets for a given look or effect, for each effect that such "urber shaders" are intended to achieve. Name these .set.k3d files, document there purpose and save them into a folder hierarchy in shared.

Fully document resulting code as well as update user documentation on how to use the shaders in K-3D.

• • at this stage we should now have the foundations for filling out the Shader library to cover most features required by users and the code libraries for the rapid prototyping of new shader code.

STAGE FOUR

Rewrite k3d-sl2xml to be a LOT smarter so as to reduce the hand coding of .slmeta files to a minimum.

Allow for the reloading of .sl and .slmeta files in K-3D to facilitate writing and testing of new shaders, including better management of the shader cache. We may wish the reexamine the purpose of the shader cache and if it is of much benefit.

Add functionality to K-3D to allow for prebaking of shaders and or using a shader as input for a bitmap object. allow for pre and post render scripting to allow for processing of data output from shaders via printf().

Allow a script to be the input for a texture map this will facilitate the integration of 2D vector artwork rasterisation for the purpose of decals and painting such artwork onto objects.

Develop tools and functions required for tasks related to rotoscoping for purposes such as environment mapping from video, compositing over video and using a video as a image based lighting source.

Develop tools for visual shader construction based on code libraries, i.e. a new version of Shrimp.

Expand the functionality of K-3D so as to facilitate the rapid location, setup and use of shaders by end users.

Develop tools to assist end users in finding, documenting, saving and sharing shader variable configuration sets through the use of a live preview of shader variable changes and through genetic/breeding tools.

The breeding tools fall into two classes, one breeds new shader code, this would be part of shrimp and may include genetic code to target shader generation toward matching an existing texture map supplied by the user. The second class of breeder would be part of K-3D and would only work with variables. The user would select one, or more, .set.k3d files as the parents of a set of offspring, they would also be able to determine the mixing ratio between variables from each parent and or the amount of randomisation applied to each variable. Once the offspring are generated the user can select one or more to be saved, and one or more to be used to generate the next set of offspring.

• • at this stage there will be few limits on what the end user can achieve.

STAGE FIVE

Make a movie.

Standard K-3D Headers

Random Notes:

• We need a cute name or acronym for the library
• I guess we could also wrap all the !RenderMan built-in function into the k3d_ nomenclature.

Basic Headers

k3d_base.h

Basic header with macros and routines needed all-over-the-place (and stuff that couldn't fit elsewere.)

• k3d_filterabs
• k3d_sinhcosh
• k3d_sinh
• k3d_cosh
• k3d_arraytomatrix
• k3d_rotate2d
• k3d_translate2d
• k3d_scale2d
• k3d_topolar2d
• k3d_lerp
• k3d_filterwidth
• k3d_filterwidthp
• k3d_fadeout
• k3d_isshadowpass

k3d_displacement.h

Displacement specific functions.

• ...

k3d_illumination.h

Functions for handling illuminations models.

Local illumination models:

• k3d_illum_orennayar
• k3d_illum_wardanisotropic
• k3d_illum_glossy

Bidirectional reflection distribution functions:

• k3d_brdf_plastic
• k3d_brdf_matte
• k3d_brdf_roughmetal
• k3d_brdf_thinplastic
• k3d_brdf_shinyplastic
• k3d_brdf_shinymetal
• k3d_brdf_clay
• k3d_brdf_metal
• k3d_brdf_brushedmetal
• k3d_brdf_ceramic
• k3d_brdf_glass

Illumination layering:

• k3d_km_estimatecoeffs
• k3d_km_compute
• k3d_km_infinite
• k3d_km_compose_r
• k3d_km_compose_t
• k3d_km_overglossy

k3d_reflection.h

Functions for handling reflections (flat and spherical.)

• k3d_raysphere
• k3d_reflectionmap
• k3d_environmentmap

k3d_texture.h

Functions for texture mapping (projection and compositing.)

Projection:

• k3d_projection_spherical
• k3d_projection_cylindrical
• k3d_projection_to2d

Texture:

• k3d_texture_colorandalpha
• k3d_texture_floatandalpha
• k3d_texture_colorover
• k3d_texture_floatover

General Patterns

k3d_noise.h

Functions for generating stocastic patterns.

Uniform:

• k3d_udnoise
• k3d_udnoise2

Signed:

• k3d_snoise
• k3d_filtersnoise
• k3d_snoise2
• k3d_filtersnoise2
• k3d_vsnoise
• k3d_filtervsnoise

Brownian:

• k3d_fBm
• k3d_vfBm

Vector:

• k3d_vlnoise
• k3d_filtervlnoise
• k3d_vlfBm

Turbulence:

• k3d_turbulence

Voronoi:

• k3d_voronoi_f1_3d
• k3d_voronoi_f1f2_3d
• k3d_voronoi_f1_2d
• k3d_voronoi_f1f2_2d

k3d_pattern.h

Functions for generating regular patterns.

Transitions:

• k3d_filtersmoothstep
• k3d_pulse
• k3d_filterpulse
• k3d_smoothpulse
• k3d_filtersmoothpulse
• k3d_pulsetrain
• k3d_filterpulsetrain
• k3d_smoothpulsetrain
• k3d_filtermsoothpulsetrain

Tiling:

• k3d_repeat
• k3d_whichtile
• k3d_odd
• k3d_even
• k3d_tilepattern
• k3d_brickpattern
• k3d_hexpattern

Shapes:

• k3d_rect
• k3d_filterrect
• k3d_disk
• k3d_filterdisk
• k3d_ring
• k3d_filterring
• k3d_line
• k3d_filterline
• k3d_star
• k3d_filterstar

Boolean:

• k3d_intersection
• k3d_union
• k3d_difference
• k3d_complement

Material Patterns

k3d_cork.h

• k3d_cork
• ...

k3d_leather.h

• k3d_leather
• ...

k3d_marble.h

• k3d_marble
• ...

k3d_rubber.h

• k3d_rubber
• ...

k3d_wood.h

• k3d_wood
• ...

k3d_stone.h

• k3d_stone
• ...