Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

On 2/4/07, Daniel J Sebald <dan...@ie...> wrote:
> Pierre wrote:
>
> > I put a meaningless example here: http://blog.thepimp.net/misc/gdshading/
> >
> > The color stop points are in the comments, it is something like a
> > range -0.25..1.0 used "black blue red yellow".
> >
> > The results has no special value (besides being a nice shading effect
> > ;),
>
> psychedelic
>
> > but it may help to see how gdShadedTriangle works and what should
> > be done to match your needs.
>
> I've looked through the code a bit and your examples.  (What command does one need to compile this program?)

gcc colormap.c -o colormap -I/path/to/usr/include -L/path/to/usr/lib -lgd

or if you use 2.0.34RC2 or  CVS version of libgd you can simply add
something like (CMake must installed, see README.TESTING):

add_executable(colormap "colormap.c")
target_link_libraries(colormap  ${GD_LIB})

at the end of the CMakeLists.txt.

> I'd have to think about your approach to be certain about the result.  You've broken the thing down into a series of one dimensional linearities, first along the sides of the triangle to get a color, and then across the x dimension to further interpolate between those two.  Seems logical, but it may be open for rounding problems.

yes, it is a linear interpolation between the two edges of each scan
line. I use the following doc to implement it:

http://tfpsly.free.fr/Docs/3dIca/3dica3.htm

> Another thing that makes me wonder a bit (and this may be a visual effect), is that I look at your gouraud3.png example:
>
> http://bugs.libgd.org/?getfile=25
>
> and imagine looking at just one of the triangles, with blue in one corner, red in another, green in the third.  Somehow it appears that they aren't blending together the way I would think.  Would it be possible to generate a fairly big equilateral triangle, say,
>
>         x0 = 10; y0 = 10;
>         x1 = 310; y1 = 10;
>         x2 = 160; y2 = 270;
>
> so that we'd expect a nice symmetrical blending of the components?

Yes, there is maybe a rounding problem as the precision is limited by
the fixed point arithmetic), but it is relatively easy to solve by
increasing the precision. I like fixed point arithmetic because it is
fast (in embedded systems too).

> I'll offer up an alternative construction, not that I'm suggesting a change,

There is absolutely no problem to suggest changes. My current
implementation is only a proposal as I used it for some basic 3D
rendering and I was happy with the quality and speed.

> but just for the sake of brainstorming.  If one thinks in terms of a single color component, it can be imagined as a two dimensional plane in three dimensional space (x and y are two dimensions, c the color a third dimension).  Generalizing the z = m x + b idea for a line, we have three points for which we want a plane to pass through.  Let w be a two dimensional vector, b a constant.  Color is then
>
> c = w' * [x y]' + b
>
> i.e., if we know w and b, we can find any color value on that plane from the above formula.  Given triplets (x_1, y_1, c_1), (x_2, y_2, c_2), (x_3, y_3, c_3), define matrix:
>
> A =
>
> | x_1  y_1  1 |
> | x_2  y_2  1 |
> | x_3  y_3  1 |
>
> and vector c = [c_1 c_2 c_3]' and vector d = [w b]'.  Then
>
> A d = c
>
> and solving for d gives
>
> d = inv(A) c
>
> I wrote a 3D inverse routine the other day.  Ultimately, this approach wouldn't mean much less code because of the inversion, but its advantage might be a little more precision, not sure.

I'm not sure either. However this solution is elegant, if you have an
implementation already (even without the gd part), I can try to
provide it as a separate patch/example. It will help to run tests
against a serie of cases.

> Anyway, I'd be interested in the equilateral "color triangle".

Please find it here (Example 2): http://blog.thepimp.net/misc/gdshading/

--Pierre