Drop shadow i_pix variant

[robo git]

I was mucking around in "lesson.cfdg" (as you do) and decided I wanted to see if I could get drop-shadows on the text easily. "Simple" thinks I, just do this before the "real" call to TITLES:

Code: Select all

    TITLES { x 0.05 y -0.05 b 0.7 }
    TITLES { }

Here's the result:

[img]http://lan.net.nz/cfdg/one.png[/img]

While a fairly funky look, it was not quite what I intended.

Why is this? Well, as near as I can determine, it's because the order the shapes are drawn in is only seeded by the script, due to the highly parallel nature of processing the rules: If you want to specify draw-order, it either needs to be at the primitives level, or with a sufficiently delayed start that it becomes irrelevant.

The problem with adding delay (through drawing the object shadow, drawing other stuff, then drawing the object over the shadow) is that even that will not guarantee the draw-order, plus if there is any randomness in the object, then you're not going to be able to repeat the object on top of the shadow.

This leaves us with drawing on primitives. At first I thought this would be a rather large task (having not looked into the i_pix file before)

Here are the changes you need to make to your i_pix.cfdg to get drop-shadows working:

Code: Select all

rule block_5by5 {
   SQUARE {size 0.7 x 0.2 y -0.2 b 0.7 }
   SQUARE {size 0.7}
}

Unfortunately, that's not quite enough, as reading further along, we see things like:

Code: Select all

rule W_5by5 {
     M_5by5 {rotate 180}
}

So we need to explicitly state the layout of the letters I, W and Z as well, else the drop-shadow will point in the wrong direction!

So make the following changes:

Code: Select all

rule I_5by5 {
     pix_5by5_00 {}
     pix_5by5_10 {}
     pix_5by5_20 {}
     pix_5by5_30 {}
     pix_5by5_40 {}
     pix_5by5_21 {}
     pix_5by5_22 {}
     pix_5by5_23 {}
     pix_5by5_04 {}
     pix_5by5_14 {}
     pix_5by5_24 {}
     pix_5by5_34 {}
     pix_5by5_44 {}
//   H_5by5 {rotate 90}
}

Code: Select all

rule W_5by5 {
     pix_5by5_40 {}
     pix_5by5_41 {}
     pix_5by5_42 {}
     pix_5by5_43 {}
     pix_5by5_44 {}
     pix_5by5_00 {}
     pix_5by5_01 {}
     pix_5by5_02 {}
     pix_5by5_03 {}
     pix_5by5_04 {}
     pix_5by5_34 {}
     pix_5by5_23 {}
     pix_5by5_14 {}
//  M_5by5 {rotate 180}
}

Code: Select all

rule Z_5by5 {
     pix_5by5_00 {}
     pix_5by5_10 {}
     pix_5by5_20 {}
     pix_5by5_30 {}
     pix_5by5_40 {}
     pix_5by5_04 {}
     pix_5by5_14 {}
     pix_5by5_24 {}
     pix_5by5_34 {}
     pix_5by5_44 {}
     pix_5by5_13 {}
     pix_5by5_22 {}
     pix_5by5_31 {}
//   N_5by5 {rotate 90}
}

Or if you just want to use this, grab it from here



Cheers!
-Trav

PS:

Code: Select all

rule the5by5_testWin {
   F_5by5 {x 0}
   O_5by5 {x 1.2 }
   R_5by5 {x 2.4}
   T_5by5 {x 4.0}
   H_5by5 {x 5.2}
   E_5by5 {x 6.4}
   W_5by5 {x 8.0}
   I_5by5 {x 9.2}
   N_5by5 {x 10.6}
   Exclaim_5by5 {x 11.8}
   Exclaim_5by5 {x 12.2}
   Exclaim_5by5 {x 12.6}
}

Code: Select all

rule Exclaim_5by5 {
    pix_5by5_00 {}
    pix_5by5_01 {}
    pix_5by5_02 {}
    pix_5by5_04 {}
}

[robo git]

Note that I've kept the rule-names the same, as I was pretty much picturing this as a drop-in replacement for i_pix wherever shadow-text was wanted, and to maintain forward compatibility with this change.

Well... that, and I'm lazy

Oh, and my rambling about draw-order is all best-guess stuff - I've not been through the code, so take what I said with a sizable grain of salt.

[chris]

well done!

[mtnviewmark]

Well, you are right - by the very nature of being context-free, the order of drawing is not defined. That said, many people rely on the order of drawing that our implementation uses to achieve certain effects (like your shadows, or the eyes in the octopi). Alas, even our implementation doesn't use the same drawing order in all circumstances....

One solution to this is to define a drawing order -- we are not inclined to do this as it starts ruling out all sorts of performance options (using multiprocessors on CPUs that have them, etc...).

The other solution is to use a drawing operation that doesn't matter what order you draw the overlapping shapes: Something like a water-color blend. This would change the kinds of things you could do, would would probably have to be an option.

[MtnViewJohn]

The ink blending model will certainly allow for some very cool images. But I think many users will be turned off by the fact that overlapping shapes of the same color will have a different color in the overlapping part.

And yet, we have to solve this if we are going to change the rendering algorithm to take advantage of the power of the multi-threaded and multi-core CPUs that are poised to become mainstream. When we add the ink blending model I want to also add a depth-based color blending model using a 16-bit Z-buffer. This would be context free and it would emulate the blending properties that Context Free has today.

[MtnViewJohn]

There should be some way of overriding the pixels in i_pix.cfdg. Maybe if we gave them a rule weight of zero, which would mean that the rule is never used unless there are no non-zero-weight rules. But this is a real hack. Maybe we could have an undefine directive that removes all rules with a given name from the rule list.

[chris]

I lke the idea of not having any terminal shapes at all in the includes (instead of square, just have something called i_pix_brush which you then declare whatever you want in the parent)...but I'm afraid it would confuse new users too much.

-cc

[robo git]

I've got an idea for a variant of your i_pix_brush idea Chris, but it's going to have to wait until I get home tonight (it's 10:40am now, for reference)

[robo git]

Hmm... thinking about this further, the ideal way to handle this would be to be able to pass parameters and set defaults for parameters, and/or to inherit parameters.... making a post in the suggestions forum under this related thread, rather then clutter this thread.