1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
Shader Calculation Model:
inputs - variables that control the object
shader - joint vertex and pixel shader necessary for calculation
Parameter Types:
Uniforms - things that are constant for the entire render setup
Layer render properties:
Blend - blends with layer behind (amount,blend-method), if complicated must use (pixel shader...).
Algorithmic - gets colors without sampling textures (exception for function look ups...).
Sampling - samples a texture map as part of the color calc process.
Behind - use result(s) below to calculate color.
Internal -
Functions/Inputs - CPU generated internal texture maps (uniform)
Dependent - GPU generated texture maps (unknown use...)
Parameters:
Uniforms - layer-wide stats (color, blend-mode, amount, below texture, coverage map, etc.)
Varying - pixel coordinate (in canv-space), texture coordinates for samplers, etc.
For optimized stuff:
For layer constants that aren't simple calculations (i.e. changing the blend type),
we can use global constants (however since OpenGL doesn't allow you to define those
manually, we can probably do it with #defines or the like)... Just in time compiling
(optimized by caching these changes of course) would allow us to operate in an optimal
manner (rather than having dynamic branching at run time).
Considerations for Framework:
For truly optimal rendering, caching textures would be great, but it would take up a lot of space. So an intelligent resource system should be implemented. The resource eviction routine should be intelligent and should deal with the resources deepest in the tree (of course this doesn't entirely count for CPU generated stuff). A priority system should be generated, mostly depending on how often it's used and even more, how expensive it is to generate (cpu and gpu side...).
Shader considerations for Operations:
Blend functionality can be done in a separate pass unless the blending shader part is also programmable (requires less JIT compiling).
Sampling function should be abstracted to use different forms of interpolation (for nearest and linear, the built in support is probably plenty).
Iterated calculations: either done using dynamic looping in GLSL or multipass rendering.
Shader considerations for layers:
solid_color - just use blend with an input global color parameter
circle - can calculate alpha in falloff based on interpolated pixel values and then use that and the amount... color to blend (must work out whether or not to out put an amount map + color blend, or a color map + amount blend... currently using the first on CPU side).
checker_board - same as circle, but a simpler calculation (antialiasing will require a few calculations using the values of the derivatives of the pixel coordinates)
rectangle - same thing as the checker_board, but only need to worry about 2 edges per dimension.
Coverage Map Based: outline,polygon,region,star,text
and Internal Samplers: import, noise
- would require CPU side computation of the coverage map/color map
(tiling would be a little more difficult... we'll see how effective it would be...)
Modifiers (algorithmic w/ direct below sample): clamp,colorcorrect (blend also classifies as this)
- modification of the colors underneath using math... easy....
Basic Transform: translate,stretch,zoom (should require no sampling),super_sample (simple down sample)
- simply requires the repositioning (and resizing in the case of the super sample) of the window
Behind Samplers:
Basic Transform: rotate,twirl,
In-place: bevel,blur,halftone2,shade
Warpers: inside_out, spherize, noise_distort (internal and behind sampler)
- requires access to the background texture (with increased window in order to not find distortions).
Iterated: mandelbrot,julia (used to warp, index into gradient, etc.)
- requires iterative refinement of the fractal values (with crazy swapping to consider stopping points)
Gradients (complicated... could require a CPU side color map, unless we have dynamic looping):
conical_gradient, linear_gradient, radial_gradient, spiral_gradient
|
