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