> "LanuHum" <Lan### [at] yandexru> wrote:
>> In documentation there is an example
>>
> ///////////////////////////////////////////////////////////////////////////////
>>
>> Render time: 11 m
>> I created a similar scene in Blender, using mesh2
mesh or mesh2 are realy the same, internaly, once parsed.
>>
>> ///////////////////////////////////////////////////////////////////////////////
>>
>> //----------------------------------------------
>> //--Export to Povray from Blender--
>> //----------------------------------------------
>>
>> ////////////////////////////////////////////////////////////////////////////
>>
>> Render time very long!!!! 10 hours
>> In what reason of such difference? 11 minutes against 10 hours
>
> Maybe you look at this simple example:
>
> background { rgb <0.3, 0.6, 0.9> } versus background {rgbt<0.0509, 0.0509,
> 0.0509, 0>}
Both use floats. It don't mather how many decimal digits there are, 
internaly, it's always a double precision float.

>
> I think that calculatin inside POV-Ray using a Integer is faster then a Float.
> But i could be wrong
>
>
>

POV-Ray always use floats, never integers. Rendering rgb 1 and 
rgb<1,13/47,0.013752168> take exactly the same time.

In the purely POV-Ray scene, you use simple pigments and textures.

The blender textures use pigment_pattern with a texture_map. Those take 
longer to render.

Your light_source is a basic point_light, blender's light_source is a 
fading one. The fading light_source is a little slower as the distance 
must be calculated and the fading applied.

For your media, you use samples 30, and you use a very small extinction 
value of 0.1.
For the blender's media, it's samples 256, and use a HUGE, I may say 
insane, extinction value of 4.871 !

If your mesh contains long and narrow triangles, those can't be bounded 
effeciently. Subdividing the mesh, or not decimating it, can make it 
render faster.





Alain

Post a reply to this message