scam wrote:
> Hi all,
> 
> I am using a heightfield in an animation that takes about 5 seconds to 
> process for each frame.

I understand the situation, but I don't see what the problem is.

Unless you meant five minutes (still not bad for an animation) or five 
hours (which would be something worth worrying about).

Regards,
John

Post a reply to this message

Warp wrote:
> Alain <ele### [at] netscapenet> wrote:
> 
>>If your heightfield is generated from a function, you can save it to a file 
>>during the first frame. Then, you reload it for each subsequent frame. It should 
>>be faster then recreating it everytime.
> 
>   There's no way of storing a heightfield in a file.

Sure you can.  You have POV-Ray render the height_field with a gradient 
texture running from rgb <0,0,0> to rgb <1,1,1>, with the hf_gray 
setting on.  The high parts of the height_field are white, and the low 
parts are black.  The height_field is saved as a picture in the render 
output file.

Oddly enough, this is what Alain described.

If the original poster is generating a large height field from a 
function or pigment pattern (which I did for a recent IRTC entry), he 
can try breaking up the height_field into several smaller sections (of 
equal precision, or he'll get cracks between sections), and test them to 
see which are on-camera and which aren't.

Regads,
John

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> Sure you can.  You have POV-Ray render the height_field with a gradient
> texture running from rgb <0,0,0> to rgb <1,1,1>, with the hf_gray
> setting on.  The high parts of the height_field are white, and the low
> parts are black.  The height_field is saved as a picture in the render
> output file.
>
But won't the image file need to be converted back into a mesh at parse
time?

Just to clarify, I have 5000x5000 pixel png image that I have generated in
another program. When POV-Ray parses my scene it spends 5-10 seconds
processing the image, converting it into a mesh (which is what I believe
height_field does). Would this approach actually speed things up in my
case?
>
> If the original poster is generating a large height field from a
> function or pigment pattern (which I did for a recent IRTC entry), he
> can try breaking up the height_field into several smaller sections (of
> equal precision, or he'll get cracks between sections), and test them to
> see which are on-camera and which aren't.
>
> Regads,
> John

This sounds promising, although most of the height_field is visible
throughout the animation.

Thanks for the suggestions all.

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> >   There's no way of storing a heightfield in a file.

> Sure you can.  You have POV-Ray render the height_field with a gradient 
> texture running from rgb <0,0,0> to rgb <1,1,1>, with the hf_gray 
> setting on.

  That's not a heightfield, that's an image file. The heightfield will
need to be generated from it. There's no advantage.

-- 
                                                          - Warp

Post a reply to this message

scam <sca### [at] mailusydeduau> wrote:
> How feasible would it be to write a patch whereby you could store an object
> (like a mesh or heightfield) in memory, and then reference that object's
> memory address as opposed to the object in your scene file?

  Such a patch exists/existed for MegaPOV.

  POV-Ray 3.7 has been restructured in a way that will most probably easily
allow this in the future.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Such a patch exists/existed for MegaPOV.
> 
>   POV-Ray 3.7 has been restructured in a way that will most probably easily
> allow this in the future.
> 

Hmmm, that sounds very handy. I don't suppose you can remember the name 
of the patch? I had a look on the MegaPOV site (both official patches 
and other patches) but couldn't spot it. Thanks for your help by the way.

Post a reply to this message

scam wrote:
> But won't the image file need to be converted back into a mesh at parse
> time?
> 
> Just to clarify, I have 5000x5000 pixel png image 

That is at least 25 MB, even if it is compressed to like 12 MB, which do
take a second or two to read from disk alone - if you have a fast disk and
the file is stored linearly on disk!

Heightfields in POV-Ray are not converted to meshes.

	Thorsten

Post a reply to this message

Thorsten Froehlich nous apporta ses lumieres en ce 12-03-2007 14:10:
> scam wrote:
>> But won't the image file need to be converted back into a mesh at parse
>> time?

>> Just to clarify, I have 5000x5000 pixel png image 

> That is at least 25 MB, even if it is compressed to like 12 MB, which do
> take a second or two to read from disk alone - if you have a fast disk and
> the file is stored linearly on disk!

> Heightfields in POV-Ray are not converted to meshes.

> 	Thorsten
Somebody know how to make a virtual drive in windows? That way, assuming that 
you have enough RAM, the access will get a huge boost.

-- 
Alain
-------------------------------------------------
"The way England treats her prisoners, she doesn't deserve to have any." 
        --Oscar Wilde

Post a reply to this message

Warp wrote:
> John VanSickle <evi### [at] hotmailcom> wrote:
> 
>>>  There's no way of storing a heightfield in a file.
> 
> 
>>Sure you can.  You have POV-Ray render the height_field with a gradient 
>>texture running from rgb <0,0,0> to rgb <1,1,1>, with the hf_gray 
>>setting on.
> 
> 
>   That's not a heightfield, that's an image file. The heightfield will
> need to be generated from it. There's no advantage.

There is if an image-based height field parses faster than a 
formula-based one.

Regards,
John

Post a reply to this message

Alain  wrote in message <45f5dc94$1@news.povray.org>:
> Somebody know how to make a virtual drive in windows? That way, assuming that 
> you have enough RAM, the access will get a huge boost.

That is not a good idea. If the file is read twice and there is enough
memory, the OS will keep it in memory, and the second read does not require
disc access. If there is not enough memory, the OS needs to free memory, and
discarding a cached file to re-read it later is cheaper than swapping
something out and later in.

Post a reply to this message