vpSetShadowLookupShader(3)
π vpSetShadowLookupShader β the glow-up your shadows deserved
okay bestie, welcome to the vpSetShadowLookupShader(3) page from the Library Functions Manual π this is the VolPack girlies' guide to making volumes cast actual shadows, and yes it's giving main character energy.
β¨ NAME β¨
vpSetShadowLookupShader β specify shading lookup tables for rendering shadows πΈ
π¦ SYNOPSIS π¦
#include <volpack.h>
vpResult
vpSetShadowLookupShader(vpc, color_channels, num_materials, color_field,
color_table, color_table_size, weight_field, weight_table,
weight_table_size, shadow_table, shadow_table_size)
vpContext *vpc;
int color_channels, num_materials;
int color_field;
float *color_table;
int color_table_size;
int weight_field;
float *weight_table;
int weight_table_size;
float *shadow_table;
int shadow_table_size;
look at all those arguments. seventeen of them. she's high maintenance but she's worth it π
π«Ά ARGUMENTS π«Ά
vpcβ the VolPack context you got fromvpCreateContext. your girl's whole identity lives in here.color_channelsβ how many color channels per pixel. it's1or3, no in-between, pick a lane.num_materialsβ how many material types you've got.color_fieldβ the field number for the voxel field that holds the color lookup table index.color_tableβ the color lookup table itself. queen of the tables.color_table_sizeβ size of the color lookup table, in bytes.weight_fieldβ field number for the voxel field holding the material weight lookup table index.weight_tableβ the material weight lookup table.weight_table_sizeβ size of the material weight lookup table, in bytes.shadow_tableβ the shadow color lookup table. the new girl on the block π€shadow_table_sizeβ size of the shadow color lookup table, in bytes.
π DESCRIPTION π
vpSetShadowLookupShader is the function you call to hand over the lookup tables that define a shading function for rendering a volume with shadows. so basically: when shadows are on, you use this instead of vpSetLookupShader. periodt. β¨
VolPack supports a fast, one-pass shadow algorithm, and it's lowkey iconic. here's the tea: the algorithm computes the fraction of light from a given light source that actually reaches each voxel. that fraction then gets used to attenuate the diffuse and specular shading terms tied to that light source β so areas hidden from the light end up looking dark, i.e. shadows. and the way it does this is with lookup tables, so most of the shading math is precomputed before you even render. efficient? we love to see it π
but here's the catch, bestie, and it's a real one. to compute shadows in a single pass, the algorithm puts a restriction on the light source's direction: the light casting the shadows must not be more than 45 degrees from the viewing direction. and the quality of the shadows may degrade as the angle approaches 45 degrees. also β the current implementation allows shadows to be cast from only one light source. you can enable additional lights, but they will not cast shadows. no cap. π
so if you're sitting there wondering why your second light isn't throwing shade (literally), that's why.
to make a rendering with shadows, you gotta do these steps in order, in this exact order, no skipping:
- Call
vpSetShadowLookupShaderto define the lookup tables (see the discussion below). - Call
vpSetiwith theVP_SHADOW_LIGHToption to specify which light will cast shadows. the current implementation only allows one light to be specified. - Call
vpSetiwith theVP_SHADOW_BIASoption to set the shadow bias value (see the discussion below). - Call
vpEnablewith theVP_SHADOWoption to enable shadows. - Call
vpShadeTableas usual to initialize the lookup tables. - Call one of the rendering routines.
vpSetShadowLookupShader defines the lookup tables required for the shading and shadowing algorithm. the first nine arguments are identical to the arguments for vpSetLookupShader (go read the corresponding man page, iykyk). the remaining two arguments specify an additional color lookup table, shadow_table, which has the same dimensions as color_table. the contents of the table will be initialized by vpShadeTable.
now, the vpSeti call with the VP_SHADOW_BIAS option β this specifies an offset to eliminate self-shadowing. and self-shadowing is an intrinsic problem when you implement shadow algorithms for volume rendering, so listen up. picture a single voxelized object made of an opaque core surrounded by a "halo" of lower-opacity voxels (this is necessary for the scene to be band-limited, okay, it's not a design flaw, it's math). as a light ray pierces that halo, its strength gets attenuated. by the time the light reaches the high-opacity region, a significant fraction of it may already be obscured β which results in a general darkening of the image even if no shadows should be present. π
the fix: move the shadow a small distance along the direction of the light rays. VP_SHADOW_BIAS specifies that distance in units of voxels. the optimal value depends on the data set. increase the bias until it has no more effect on overall image brightness β but do not increase it too far, or small features in the data will no longer produce correct shadows. it's a balance, bestie. a vibe check, if you will. βοΈ
vpShadeTable initializes the shading lookup tables, and it operates differently when shadows are enabled. instead of computing one color for each surface normal vector and storing the results in color_table, the routine computes two color terms:
- the first term is the portion of the voxel color due to the diffuse and specular components of the shadow light. this value is stored in
shadow_table. - the second term contains the contribution of all other light sources plus the ambient light term, and it's stored in
color_table.
during rendering, the color of a voxel is computed like this: extract a surface normal from the voxel, use that surface normal to index both color_table and shadow_table, attenuate the value from shadow_table by the local strength of the shadow light, and then add the two terms together. the local strength of the shadow light is found by extracting a value from the shadow buffer β an internal data structure that gets updated during rendering. π
the values in the shading lookup tables may be initialized before or after calling vpSetShadowLookupShader. typically you call vpSetShadowLookupShader once at the beginning of a rendering session, and then call vpShadeTable whenever the user changes the lighting and shading parameters or the viewing direction. set it and forget it (until they touch the sliders again). π
the shadow buffer is an internal 2D array used to maintain state during rendering. there are several state variables you can use to query its current size in pixels β VP_SHADOW_WIDTH and VP_SHADOW_HEIGHT β and to suggest a size β VP_SHADOW_WIDTH_HINT and VP_SHADOW_HEIGHT_HINT. the required size depends on the volume size and the shadow light's direction. normally the buffer is automatically resized when necessary, so she handles herself. π
π STATE VARIABLES π
info about the current shading table parameters can be retrieved with the following state variable codes (go see vpGeti(3)):
VP_COLOR_CHANNELS, VP_SHADE_COLOR_TABLE, VP_SHADE_COLOR_SIZE, VP_SHADE_WEIGHT_TABLE, VP_SHADE_WEIGHT_SIZE, VP_SHADE_COLOR_FIELD, VP_SHADE_WEIGHT_FIELD, VP_MATERIAL_COUNT, VP_SHADOW, VP_SHADOW_LIGHT, VP_SHADOW_WIDTH_HINT, VP_SHADOW_HEIGHT_HINT, VP_SHADOW_WIDTH, VP_SHADOW_HEIGHT, VP_SHADOW_COLOR_TABLE, VP_SHADOW_COLOR_SIZE, VP_SHADOW_BIAS
π ERRORS π
the normal return value is VP_OK. the following error return values are possible:
VPERROR_BAD_VALUEβ one or more of the arguments has an invalid value or is out of range. she's not mad, she's just disappointed.VPERROR_LIMIT_EXCEEDEDβ thenum_materialsargument has exceeded an internal limit. the fix: change the value ofVP_MAX_MATERIALinvolpack.hand recompile the VolPack library. yes, actually recompile. π₯
πΈ SEE ALSO πΈ
VolPack(3), vpCreateContext(3), vpShadeTable(3), vpSetLookupShader(3)
and that's the whole page, bestie π this one ships with the VolPack library, and the section is vpSetShadowLookupShader(3) β go forth and cast some truly immaculate shadows. slay β¨π
π¦ where this page comes from
- fedora 43: volpack 1.0c7-35.fc43 Β· BSD-3-Clause
- fedora 43: volpack 1.0c7-35.fc43 Β· BSD-3-Clause
- fedora 44: volpack 1.0c7-36.fc44 Β· BSD-3-Clause
- fedora 44: volpack 1.0c7-36.fc44 Β· BSD-3-Clause
- Copyright (c) 1995-2008, Stanford University
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms