 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
With some of the experiments I have been working on lately I though of a
potential pattern type that could be developed for future consideration:
array
You would basically create a 1D,2D or 3D array with as many elements as you
would like and assign values to each element, then the pattern would fill a 1
unit cube space, similar to density_file pattern.
I came across this idea as I am currently doing this the long way: export array
to df3, then read as density_file. Would be much easier to cut out the middle
step somehow.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/2011 9:59 AM, Trevor G Quayle wrote:
> With some of the experiments I have been working on lately I though of a
> potential pattern type that could be developed for future consideration:
> array
>
> You would basically create a 1D,2D or 3D array with as many elements as you
> would like and assign values to each element, then the pattern would fill a 1
> unit cube space, similar to density_file pattern.
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/2011 10:51 AM, stbenge wrote:
> This can be accomplished with nested gradient x/y/z patterns and
> color_map #while loops.
Here's the basic idea:
#declare N_UnitsX = 32;
#declare N_UnitsY = 32;
#declare N_UnitsZ = 32;
#declare RSEED = seed(1001);
box{0, 1
pigment{
gradient z
pigment_map{
#local Z=0;
#while(Z<N_UnitsZ)
[Z/N_UnitsZ
gradient y
pigment_map{
#local Y=0;
#while(Y<N_UnitsY)
[Y/N_UnitsY
gradient x
pigment_map{
#local X=0;
#while(X<N_UnitsX)
[X/N_UnitsX
rgb <rand(RSEED),rand(RSEED),rand(RSEED)>
]
#local X=X+1;
#end
}
]
#local Y=Y+1;
#end
}
]
#local Z=Z+1;
#end
}
}
finish{ambient 1}
translate -1/2
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/2011 11:14 AM, stbenge wrote:
Oops, here's a fixed version:
#declare N_UnitsX = 4;
#declare N_UnitsY = 4;
#declare N_UnitsZ = 4;
#declare RSEED = seed(1001);
box{0, 1
pigment{
gradient z
pigment_map{
#local Z=0;
#while(Z<N_UnitsZ)
[Z/(N_UnitsZ-1)
gradient y
pigment_map{
#local Y=0;
#while(Y<N_UnitsY)
[Y/(N_UnitsY-1)
gradient x
pigment_map{
#local X=0;
#while(X<N_UnitsX)
[X/(N_UnitsX-1)
rgb <rand(RSEED),rand(RSEED),rand(RSEED)>
]
#local X=X+1;
#end
}
]
#local Y=Y+1;
#end
}
]
#local Z=Z+1;
#end
}
}
finish{ambient 1}
translate -1/2
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/18/2011 11:31 AM, Trevor G Quayle wrote:
> stbenge<"egnebts<-inverted"@hotmail.com> wrote:
>> This can be accomplished with nested gradient x/y/z patterns and
>> color_map #while loops.
>
> 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.
I just thought I'd throw it out there :) It's a terrible method for all
the reasons you mentioned, plus it's a big memory hog :(
An editable array pattern would indeed be a great thing, could be used
for all sorts of things... Even better yet would be the option to
specify linear or cubic blending between cells, and a way to instantly
turn an object pattern into an array pattern.
A few averaged object->array patterns of varying resolutions would make
proximity patterns easy to create :D
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I just thought I'd throw it out there :) It's a terrible method for all
> the reasons you mentioned, plus it's a big memory hog :(
>
> An editable array pattern would indeed be a great thing, could be used
> for all sorts of things... Even better yet would be the option to
> specify linear or cubic blending between cells, and a way to instantly
> turn an object pattern into an array pattern.
>
> A few averaged object->array patterns of varying resolutions would make
> proximity patterns easy to create :D
>
> Sam
For future reference I have found that my current workaround to creating one is
use "ARRAYS_WriteDF3()" macro in "arrays.inc" to dump to a df3 file, and read
that in as a desity_file pattern. But it may help simplify some of your
approaches rather than having to come up with the procedural gradient loop.
Unfortuneately this means having an external df3 file being created...
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.03.2011 17:59, schrieb Trevor G Quayle:
> With some of the experiments I have been working on lately I though of a
> potential pattern type that could be developed for future consideration:
>
> array
>
> You would basically create a 1D,2D or 3D array with as many elements as you
> would like and assign values to each element, then the pattern would fill a 1
> unit cube space, similar to density_file pattern.
>
> I came across this idea as I am currently doing this the long way: export array
> to df3, then read as density_file. Would be much easier to cut out the middle
> step somehow.
Your prior postings already had me thinking about that, too. Should be
pretty straightforward to implement - I guess the biggest problem would
be to decide on a syntax ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 18.03.2011 17:59, schrieb Trevor G Quayle:
> > With some of the experiments I have been working on lately I though of a
> > potential pattern type that could be developed for future consideration:
> >
> > array
> >
> > You would basically create a 1D,2D or 3D array with as many elements as you
> > would like and assign values to each element, then the pattern would fill a 1
> > unit cube space, similar to density_file pattern.
> >
> > I came across this idea as I am currently doing this the long way: export array
> > to df3, then read as density_file. Would be much easier to cut out the middle
> > step somehow.
>
> Your prior postings already had me thinking about that, too. Should be
> pretty straightforward to implement - I guess the biggest problem would
> be to decide on a syntax ;-)
array MyArray
Would likely be simple enough. The means are already there to poll the array to
check the number of dimensions and size if needed. Would just require MyArray
to be pre-defined and filled with numerical floats.
Would there be a need to declare the array on-the-fly? I.e. in the array
pattern statement, rather than being pre-declared? This may require declaring
of array dimensions and sizes much like mesh2, or it could be declared similar
to splines.
Another item of thought would be is there any need to have it a) appear only
once, with a value of 0 (or 1) outside the <0,0,0><1,1,1> cube, similar to
density_file pattern behaviour, or have it repeat on each axes, similar to other
patterns like checker, image_map. Either way it isn't difficult to manipulate
the pattern in POV to replicate the other. A general intuitive or easy
implementation may be similar to image_map, where it repeats endlessly, but the
keyword 'once' can be specified.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.03.2011 21:12, schrieb Trevor G Quayle:
> clipka<ano### [at] anonymousorg> wrote:
>> Your prior postings already had me thinking about that, too. Should be
>> pretty straightforward to implement - I guess the biggest problem would
>> be to decide on a syntax ;-)
>
> array MyArray
>
> Would likely be simple enough. The means are already there to poll the array to
> check the number of dimensions and size if needed. Would just require MyArray
> to be pre-defined and filled with numerical floats.
Another interesting option would be to alternatively allow for color
values, in which the array content might directly serve as the pigment.
> Would there be a need to declare the array on-the-fly? I.e. in the array
> pattern statement, rather than being pre-declared? This may require declaring
> of array dimensions and sizes much like mesh2, or it could be declared similar
> to splines.
I don't think that would be of much added value.
> Another item of thought would be is there any need to have it a) appear only
> once, with a value of 0 (or 1) outside the<0,0,0><1,1,1> cube, similar to
> density_file pattern behaviour, or have it repeat on each axes, similar to other
> patterns like checker, image_map. Either way it isn't difficult to manipulate
> the pattern in POV to replicate the other. A general intuitive or easy
> implementation may be similar to image_map, where it repeats endlessly, but the
> keyword 'once' can be specified.
Actually I was thinking of adding the "once" keyword to density files as
well; at the moment the implementation appears to be quite inconsistent
when interpolation is involved.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
