![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> rather than using a 3D grid of points that is
> randomly jittered, it uses a user-specified set of points.
Can they be 4D? =)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3febe5bb$1@news.povray.org>, "Slime" <fak### [at] email address>
wrote:
> > rather than using a 3D grid of points that is
> > randomly jittered, it uses a user-specified set of points.
>
> Can they be 4D? =)
It would actually be pretty easy to do, and it's a feature I've been
looking at implementing. In a way, they are already...the offset feature
specifies the distance along the fourth dimension of all the points. You
just can't have variation in that direction.
Anyway, I do plan on trying it out, as part of some extensions to the
BSP code to more optimally handle the 2D and 1D cases (where all points
are in a axis-aligned plane or aligned along a line).
I'd also like to implement a 4D noise pattern, which is something I've
seen used for things like flames...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3febc82e@news.povray.org>, Jim Charter <jrc### [at] msn com>
wrote:
> Looks very exciting. What are the options for specifyimg points? Could
> the vertices of a mesh be used for instance?
You either specify point vectors or float-vector pairs. If the latter,
the result is similar to crackle with the solid feature turned on,
except that it uses the specified value for that cell rather than a
pseudo-random one. The points can be whatever you want...mesh vertices
would work, but you would have to extract the actual vertex locations.
voronoi {
offset FLOAT
form FLOAT
metric FLOAT (actually a vector, but only the x component is used)
POINTS
}
POINTS:
VECTOR,
VECTOR,
VECTOR...
or:
[FLOAT VECTOR]
[FLOAT VECTOR]
[FLOAT VECTOR]
You must specify at least 3 points, but that is the only restriction.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
in news:cja### [at] netplex aussie org Christopher
James Huff wrote:
> Here's a little patch I've been working on. It is very similar to the
> crackle pattern, but rather than using a 3D grid of points that is
> randomly jittered, it uses a user-specified set of points.
Looks very interesting.
Is the pattern infinite?
A thought, triggerd by your pattern: In the crackle pattern, would it be
possible to make the position of the centeroids controlable by some
function?
I'm thinking of something like, put all the centeroids in the centre and
than give them a random deviation from there with a certain (Gauss)
distribution.
Or, make the position of the centeroid in the box depend on another
pattern. Imagine a wood pattern, in the light parts of it the centeroids
are "more random" where as in the dark parts they are very close to the
centre of the box. That would give bands of more and less uniform
crackles.
Or, with the same wood pattern, in the lighter area's the centeroids are
closer to the sides of the box and in the darker area they ar closer to
the center.
Ingo
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <Xns### [at] netplex aussie org>,
ingo <ing### [at] tag povray org> wrote:
> Is the pattern infinite?
It's infinite, but not very interesting far away from the points. As you
can see in the examples I posted, it turns into uniform rays.
> A thought, triggerd by your pattern: In the crackle pattern, would it be
> possible to make the position of the centeroids controlable by some
> function?
It certainly would be, though slower.
> I'm thinking of something like, put all the centeroids in the centre and
> than give them a random deviation from there with a certain (Gauss)
> distribution.
I'm not sure what exactly you're thinking, but you pretty closely
describe the first 2 images...just random points, more dense in the
center.
> Or, make the position of the centeroid in the box depend on another
> pattern. Imagine a wood pattern, in the light parts of it the centeroids
> are "more random" where as in the dark parts they are very close to the
> centre of the box. That would give bands of more and less uniform
> crackles.
> Or, with the same wood pattern, in the lighter area's the centeroids are
> closer to the sides of the box and in the darker area they ar closer to
> the center.
I don't think this would have the effect you expect...you would just get
a strong grid pattern where the points were less random. Varying point
density would be more interesting. Or point importance...maybe if offset
were controlled by a pattern...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff wrote:
> Here's a little patch I've been working on. It is very similar to the
> crackle pattern, but rather than using a 3D grid of points that is
> randomly jittered, it uses a user-specified set of points. It is
> actually very fast, usually faster than the crackle pattern. It stores
> the points in a binary space partition tree, which it can then search
> very quickly, while the crackle pattern must always check a large number
> of points, and sometimes recompute all of them. The options available
> are the same as for the crackle pattern, with the addition of the
> points. You can specify the points alone, or with a blend map index for
> each point, giving you an effect similar to the "solid" feature, but
> with much more control.
That looks very nice and offers a lot of interesting possibilities (for
both textures and isosurfaces). Could the speed improvements also be
used for the regular crackle pattern?
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <f0d### [at] triton imagico de>,
Christoph Hormann <chr### [at] gmx de> wrote:
> That looks very nice and offers a lot of interesting possibilities (for
> both textures and isosurfaces). Could the speed improvements also be
> used for the regular crackle pattern?
Very unlikely. The crackle pattern stores a cache of 125 points in an
array. Running through a BSP tree for those points would be faster than
testing each of them for every evaluation of the pattern, but building
that tree would be much slower than building the array. However, I have
found several other, completely unrelated ways to speed up the crackle
pattern...my updated version is a few percent faster with the default
settings, and up to 6 times as fast with non-0 offset and a metric of 3.
A pure 2D version would also be much faster...it would only need to
handle points in 21 squares, rather than 125 cubes.
My voronoi patch is getting closer to finished...it now detects the case
where all points are in an axis-aligned plane, and switches to a 2D
partition tree. It will still break when there's a mixture of the
cases...not all points coplanar, but a large group of coplanar points.
I'm still thinking about the best way to handle that case...
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tag povray org>
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff wrote:
>
>>That looks very nice and offers a lot of interesting possibilities (for
>>both textures and isosurfaces). Could the speed improvements also be
>>used for the regular crackle pattern?
>
>
> Very unlikely. The crackle pattern stores a cache of 125 points in an
> array. Running through a BSP tree for those points would be faster than
> testing each of them for every evaluation of the pattern, but building
> that tree would be much slower than building the array.
I feared something like that. But in many cases where the crackle
pattern is nice to use only a relatively small area of the pattern space
is actually evaluated. In these cases i could imagine a system like this:
- initially build a BSP tree for all points within a certain area
(possibly customizable with a parameter).
- when a point outside this area is evaluated use the old technique.
- when a certain number of points outside needed to be evaluated rebuild
the BSP tree for a different/larger area.
I don't know if this idea is feasible or would be efficient of course.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <8ei### [at] triton imagico de>,
Christoph Hormann <chr### [at] gmx de> wrote:
> I feared something like that. But in many cases where the crackle
> pattern is nice to use only a relatively small area of the pattern space
> is actually evaluated. In these cases i could imagine a system like this:
>
> - initially build a BSP tree for all points within a certain area
> (possibly customizable with a parameter).
It would have to be customizeable with a parameter...POV has no way of
determining where you are going to use the pattern.
> - when a point outside this area is evaluated use the old technique.
This much could be done with the Voronoi patch. Just use an object
pattern with a box, the voronoi pattern with appropriately placed points
inside the box, and the crackle pattern outside it. Computing the right
points to get a smooth transition would be tricky though...a couple
extra functions such as hash3d() would make it easier.
> - when a certain number of points outside needed to be evaluated rebuild
> the BSP tree for a different/larger area.
This would require actual patch work. Figuring out how big the cache has
to be to make it worth having, when to rebuild it, etc...an interesting
problem.
--
Christopher James Huff <cja### [at] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tag povray org>
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff wrote:
>In article <3febe5bb$1@news.povray.org>, "Slime" <fak### [at] email address>wrote:
>> [...]
>> Can they be 4D? =)
>
> I'd also like to implement a 4D noise pattern, which is something I've
> seen used for things like flames...
I've made a cute swirling smoke using 4D noise from this guy... :-)
http://www.slimeland.com/slimepov/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |