Warp wrote:
> Warp wrote:
>>   Note, however, that there's evidence that heightfields don't always
>> render correctly (perhaps precisely because of bugs in this optimized
>> code). "Smooth" heightfields are not always so "smooth", even though
>> equivalent smooth meshes are.
> 
>   Actually this isn't necessarily true. Height_field uses a rather
> different algorithm for calculating normal vectors than a mesh. In
> some cases this produces *better* smoothing than an equivalent mesh
> gives. However, in some cases it doesn't seem to work perfectly.
> I just tested this.
> 
>   In the attached image the upper heightfields are made with the
> height_field primitive, and the lower heighfields are meshes created
> with the HF_Square macro.
>   The non-smooth versions are obviously identical. The smooth versions
> have a considerable difference, the height_field being better.

Hm, interesting. How does the height_field generate the normals, do you 
know from the POV-Ray source-code? Perhaps by calculating the gradient 
from the image instead of averaging the normals?

Nontheless, as you said, sometimes the "smooth"-feature on the 
heightfield doesn't look like it's working too well. It'd be interesting 
if it might be better to pre-generate a mesh and use that instead of 
heightfields. Of course, the first time generating it would take longer, 
but if the loading of the final mesh doesn't take much longer than the 
heightfield, it might be a good trade.

Regards,
Tim

-- 
aka "Tim Nikias"
Homepage: <http://www.nolights.de>

Post a reply to this message