POV-Ray : Newsgroups : povray.binaries.images : high resolution height_field functions : Re: high resolution height_field functions Server Time
31 Jul 2024 06:13:08 EDT (-0400)
  Re: high resolution height_field functions  
From: clipka
Date: 18 Mar 2010 15:45:47
Message: <4ba282eb@news.povray.org>
scott schrieb:

> Thanks for the detailed analysis, after a rough look through the source 
> for the height field I assumed something similar was happening - I 
> couldn't believe it when I saw the normals were stored as 16 bit 
> integers!  I guess the code was written in a time where every byte 
> counted.

As indicated in my post, the normals' precision isn't the bottleneck - 
it's the limitation to 16 bit of the values from which the normals are 
computed.

As for memory consumption, with POV-Ray we're still living in a time 
where every byte does count. I recently tried to render an (admittedly 
pathological) scene and faild because POV-Ray would have had to generate 
more radiosity samples than my physical memory (6 GB) could hold. Trying 
to stabilize the system after it had started swapping was no fun, with 
every mouse click or keyboard press literally taking minutes to be 
processed >_<

... and that was even with a custom POV-Ray version that featured a 
smaller radiosity sample memory footprint than standard beta...

 > The code seems to be written in such a way that changing it to
> use floating point numbers is straightforward (I guess the original 
> author suspected that in the future someone might want to change it).

Or maybe he just had particularly good programming habits. Or someone 
already changed it from bytes to shorts. Or the original author wanted 
to provide a simple way to change the type on other platforms where a 
short int might be something else than 16 bit - after all, POV-Ray has 
been developed with such portability issues in mind.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.