 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Attachments:
Download 'HF1.JPG' (66 KB)
Download 'HF2.JPG' (65 KB)
Download 'HF3.JPG' (34 KB)
Preview of image 'HF1.JPG'
Preview of image 'HF2.JPG'
Preview of image 'HF3.JPG'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 30 Jul 2002 13:08:28 -0400, "TinCanMan" <Tin### [at] hotmail com>
wrote:
> Comments/questions/problems (before I post the source).
How much memory use this detailed hf ? Have you tried the same function as
isosurface ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How much memory use this detailed hf ?
for the close-up (HF3) (P4, 1GHz, 256RAM, Win2000):
Statistics for C:\Raytracing\POVRay\scenes\ddd.pov, Resolution 512 x 384
----------------------------------------------------------------------------
Pixels: 196608 Samples: 277841 Smpls/Pxl: 1.41
Rays: 348820 Saved: 70979 Max Level: 1/250
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Height Field 629008 277892 44.18
Height Field Box 629008 629008 100.00
Height Field Triangle 2276187 278167 12.22
Height Field Block 1486076 836575 56.29
Height Field Cell 13307907 1231203 9.25
Bounding Box 866794 725805 83.73
Light Buffer 2457879 1305287 53.11
Vista Buffer 1578723 1365287 86.48
----------------------------------------------------------------------------
Calls to Noise: 0 Calls to DNoise: 10
----------------------------------------------------------------------------
Shadow Ray Tests: 275194 Succeeded: 0
Reflected Rays: 70979
----------------------------------------------------------------------------
Smallest Alloc: 25 bytes Largest: 98352
Peak memory used: 6013674 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 0 minutes 1.0 seconds (1 seconds)
Time For Trace: 0 hours 0 minutes 9.0 seconds (9 seconds)
Total Time: 0 hours 0 minutes 10.0 seconds (10 seconds)
----------------------------------------------------------------------------
CPU time used: kernel 0.16 seconds, user 9.67 seconds, total 9.83 seconds
Render averaged 19992.39 PPS over 196608 pixels
POV-Ray finished
> Have you tried the same function as
> isosurface ?
No, not yet.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 30 Jul 2002 13:22:54 -0400, "TinCanMan" <Tin### [at] hotmailcom>
wrote:
> Height Field Box 629008 629008 100.00
> Bounding Box 866794 725805 83.73
Hmm, where is hole in my knowledge? Why bounding box can be 83.7%. Is bounding
box for hf only considered or something else ?
> > Have you tried the same function as
> > isosurface ?
>
> No, not yet.
But You will ? :-)
Nice images, btw.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > > 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] hotmailcom> 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
|
|
| |
| |
|
|
|
|
| |
