On 12/05/2015 11:13 AM, Alain wrote:

>> On 12/05/2015 02:23 AM, ILM wrote:
>>> ...
>>>
>>> I edited the pov file in a text editor and removed the extra 30.000
>>> declare
>>> lines. Unfortunately that did not reduce the parsing time.
>>>
>>> Furthermore I tried the following:
>>> - Changed the png file to a 1x1 px file. Parsing now only takes 40
>>> seconds.
>>> - Changed the png file to a 1x1 px file AND removed the 30.000 declare
>>> lines.
>>> parsing now takes about 15 seconds.
>>>
>>> So we found the spot where we have to apply the tweaking.
>>>
>>> Something I can do by myself: Use smaller PNG file (even they are not
>>> really big
>>> actually).
>>>
>>> The big question is: How can we (or better said the developer)
>>> optimize the
>>> loading of png files. Only removing the declare line has not changed a
>>> lot.
>>>
>>>
>
>> ....
>>
>> A guess, but wondering if due the finish block being inside the texture
>> block of the texture list, whether povray isn't creating many internal
>> textures for each face/vertice of the mesh instead of referencing just
>> one.
>>
>> As for macros, there is documentation at:
>> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_2_8 for a start.
>>
>> Bill P.
>>
>>
>
> There is absolutely nothing wrong with the finish block as it is. In
> fact, it could have been included in the #declare as follow for the
> exact same end result:
> #declare cube=texture { image_map { png "povincludes/cube.png"} finish {
> ambient 1 diffuse 1 reflection 0 } }
>
> The real problem is that #declare cube=pigment { image_map { png
> "povincludes/cube.png"} } is repeated 30000 times. It's probably the
> case for all image_map that are used.
>
> As for the parsing time not scalling with multiple cores, it's that the
> parsing is strictly linear and only support a single thread. In
> contrast, the rendering is multi threaded and can use all the available
> cores, up to 256 if I remember correctly.
>
>
> Alain
Thanks Alain,

I didn't have a large mesh2 handy with which to test. I again think you 
and Christoph are correct in that :

 > The real problem is that #declare cube=pigment { image_map { png
 > "povincludes/cube.png"} } is repeated 30000 times.

Before posting yesterday I'd created a test scene in my own space with 
30K+ lines of declares as ILM posted with a PNG file of 30K bytes in 
size I just grabbed. My parse time increased about 25 seconds which put 
it more or less in line with what ILM reported at a 35 seconds decrease 
for deleting the duplicate declare lines in his 1x1 set of pix test. 
This test led me to believe ILM's result that the removing the duplicate 
lines changed little even with his original PNGs.

This morning I looked at the PNG I grabbed for my 30K declare experiment 
and it turned out to be only 160x120 pixels... I scaled this PNG up to 
1600x1600 and re-ran and the parse time jumped to 14 minutes even using 
a memory disk. So, the thousands of duplicate declares absolutely can 
drive large parse times if the PNG files are larger as you and Christoph 
have suggested.

Let's see... 160x120 & 30K declares at 25sec we get 0.013 sec/pixel. 
1600x1600 & 30K declares at 820sec we get 0.0003sec/pixel so nothing 
wrong in the direction that is scaling with larger PNGs either.

Bill P.

Post a reply to this message