 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > > Have you tried the same function as
> > > isosurface ?
> >
> > No, not yet.
>
> But You will ? :-)
It doesn't seem to be translating well to an isosurface, perhaps my brain
isn't functioning to well today.
>
> Nice images, btw.
Thanx
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I really like the first one and would like to try and animate it. Could you
let me/us know when you post the code?
thanks much,
D.
"TinCanMan" <Tin### [at] hotmail com> wrote in message
news:3d46c824@news.povray.org...
> Someone was asking a while ago about creating repeatable patterns in POV.
I
> think I have come up with a manageable solution without resorting to
> mirroring the pattern.
> The attached images are of heightfields generated using the method tiled
> together. HF1 is just the hf with the image_map, HF2 highlights the the
> individual hfs. HF3 shows a closeup at the corner seam of 4 hfs.
> Comments/questions/problems (before I post the source).
>
> -tgq
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scenes to be posted shortly in p.b.s-f
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How much memory use this detailed hf ?
BTW, if you didn't notice, the actual hf was only the size of 1 of the
checker squares and was tiled.
> Have you tried the same function as
> isosurface ?
I think I may have figured it out, but render times are horrendous compared
to HF.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How much memory use this detailed hf ?
It seems greatly improved if I use the funtion image pattern (6.7.11.16
Function Image) for the hf (internal) rather than a separately processed hf
image.
With external hf image, 512x384:
Peak memory used: 2297685 bytes
With internal hf image, 512x384:
Peak memory used: 902579 bytes
For some reason, the pattern comes out different for each of the two methods
(though they appear equal in their scales, randomness). Perhaps something
different in the way the noise used to calculate the pattern is perceived?
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've found that the "pattern image function" will
switch up and down of an image. It uses the
section from <0,0,0> to <1,1,0>, and <1,1,0>
will be, on a heightfield, the foremost right
corner, when looking from -z towards z.
(Hope that explains something... Think about it)
So, in effect, you might be using different
parts of your pattern (not the y-planar
<0,0,0> to <1,0,1>, but the z-planar), or
its used upside down. Don't know for sure though.
--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3d480dce@news.povray.org...
> I've found that the "pattern image function" will
> switch up and down of an image. It uses the
> section from <0,0,0> to <1,1,0>, and <1,1,0>
> will be, on a heightfield, the foremost right
> corner, when looking from -z towards z.
> (Hope that explains something... Think about it)
>
> So, in effect, you might be using different
> parts of your pattern (not the y-planar
> <0,0,0> to <1,0,1>, but the z-planar), or
> its used upside down. Don't know for sure though.
Yes, that was it. I found another little phenomenon. The attached images
(sorry for the terrible jpg artifacts) show hfs of the same function.
TPGenTestE.JPG uses an external hf image whereas TPGenTestI.JPG uses the
internal type, both at the same res (512x384). As can be seen, the lumps in
the internal one have a much sharper, less rounded shape. Do they interpret
the input image differently or perhaps the "pattern image function" uses a
different waveform.
-tgq
Post a reply to this message
Attachments:
Download 'TPGenTestI.JPG' (57 KB)
Download 'TPGenTestE.JPG' (59 KB)
Preview of image 'TPGenTestI.JPG'
Preview of image 'TPGenTestE.JPG'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Another little phenomenon that I found out:
When creating a hf from an image with res m*n, the hf has a res of
(m-1)*(n-1), ie. each pixel represents a vertex on the hf (this is mentioned
in "6.5.1.5 Height Field"), this requires the input image I use to need an
"extra" row and column of pixels to join seamlessly. However, with the
"function image pattern", this is not necessary.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d481ce5@news.povray.org>,
"TinCanMan" <Tin### [at] hotmailcom> wrote:
> Yes, that was it. I found another little phenomenon. The attached images
> (sorry for the terrible jpg artifacts) show hfs of the same function.
> TPGenTestE.JPG uses an external hf image whereas TPGenTestI.JPG uses the
> internal type, both at the same res (512x384). As can be seen, the lumps in
> the internal one have a much sharper, less rounded shape. Do they interpret
> the input image differently or perhaps the "pattern image function" uses a
> different waveform.
Gamma correction of the external image? Maybe something with the
color_map or waveform you used to generate the external image?
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Gamma correction of the external image? Maybe something with the
> color_map or waveform you used to generate the external image?
There it is, it was because my display_gamma was set to 1.8 in my .ini
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
