stbenge <"egnebts <-inverted"@hotmail.com> wrote:
> On 3/18/2011 9:59 AM, Trevor G Quayle wrote:

> This can be accomplished with nested gradient x/y/z patterns and
> color_map #while loops.
>
> You can have a total of 256x256x256 cells if you don't mind linear
> blending, 128x128x128 if you want sharp transitions.
>
> Or if you're feeling brave, you can have as many units for each
> dimension you want, provided you are willing to exercise a little
> ingenuity to overcome the 256-entry-limit for color_maps.
>
> The resulting 'array' renders very quickly once all the values are set,
> but therein lies the problem: /each/and/every/ color_map entry needs to
> be set, which means the entire 3D loop structure needs to run its course.
>
> I used nested gradient patterns for the fastProx/fastSSS macros, and it
> seemed to work rather well!
>
> A native array pattern would be better, especially if you could assign
> the values you need, when you need them, without having to loop through
> the entire thing.
>
> Sam

I know it can be done this way presently and there are other workarounds, but
this was just an idea to seed for future consideration.

Also, for the particular circumstance I encountered at present, I would need
much more than 128 or 256 cells.

Writing procedural nested gradients can become an awkward task at times.
Availability of an 'array' pattern would simplify this considerably, and I could
see other potential uses for it when other patterns like "cell" or "checker"
etc, don't give the control you'd want.  It would kind of be like a
user-controlled cell pattern or an expanded checker or tile type pattern.  Also
having it as a simple pattern would allow it to be easily manupulated using
functions.

-tgq

Post a reply to this message