|
|
> "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
|
|