Hi all,

I am using a heightfield in an animation that takes about 5 seconds to 
process for each frame. Is there any way to store the heightfield mesh 
in memory between frames, or perhaps write it to a file (although that 
won't provide much speed up I think)?

Perhaps it is just my ignorance and it is possible, but it would be 
really nice to be able to operate on POV-Ray's internal data structures 
directly using SDL.

Cheers.

Post a reply to this message

scam nous apporta ses lumieres en ce 10-03-2007 20:34:
> Hi all,
> 
> I am using a heightfield in an animation that takes about 5 seconds to 
> process for each frame. Is there any way to store the heightfield mesh 
> in memory between frames, or perhaps write it to a file (although that 
> won't provide much speed up I think)?
> 
> Perhaps it is just my ignorance and it is possible, but it would be 
> really nice to be able to operate on POV-Ray's internal data structures 
> directly using SDL.
> 
> Cheers.
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.
You can also preprocess it and save is as a heightfield image file, use hf_16 to 
get beter vertical resolution. Save as a TGA file. That's the way it was dome 
before the use of function was implemented.
Create the heightfield with an amplitude of 1 unit in a plane perpendicular to 
the camera. Use an orthographic camera. Apply this texture:
texture{gradient z }finish{ambient 1}}
Change the gradient orientation if needed.

-- 
Alain
-------------------------------------------------
Everything can be filed under "miscellaneous".

Post a reply to this message

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. You can store a mesh,
but a mesh is not the same thing as a heightfield (lighting is different).

-- 
                                                          - Warp

Post a reply to this message

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?

If a function could be written that could store any povray object/data
structure in memory for later use I think many people would be able to find
a use for it.

Post a reply to this message

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