try using image_width to choose the photon count/spacing
Sven Littkowski napsal(a):
> Hi Ben,
> 
> but even so, based on what I heard already, meanwhile, the photon map would 
> still take 6 days, right?
> 
> Sven
> 
> 
> 
> "Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
> news:479bdf30$1@news.povray.org...
>> Sven Littkowski wrote:
>>> Hi.
>>>
>>> I have a scene, which already takes around 6 days to create the photon 
>>> map for, if it is done in the same resolution like the remaining scene.
>>>
>>> I would like to know, if it is possible to use a lower resolution (let's 
>>> say: 400x300) for the photon map (with the "save_file" option enabled), 
>>> and then to stop and continue the scene in a high resolution (now with 
>>> the "load_file" option enabled).
>> Sure, I do it myself.  However, since the photon map is independent from 
>> the scene resolution, you can set the image size absurdly low (like +w1 
>> +h1) and still get a full-quality photon map.
>>
>> -- 
>> ...Ben Chambers
>> www.pacificwebguy.com 
> 
>

Post a reply to this message

Hmm... THAT sounds interesting and promising, Jan. I looked into the POV 
help file, and see the keywords "image_width" and "image_height". And also 
some examples, how to use them. I really think, this could shorten the 
calculation time, if I can find out, how to use them properly in connection 
with my photon map creation.

Jan, can you give me some more advice in this? If you like, I could post the 
scene file to you. Please let me know. Thanks,

Sven





"Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
news:479c31b4$1@news.povray.org...
> try using image_width to choose the photon count/spacing
> Sven Littkowski napsal(a):
>> Hi Ben,
>>
>> but even so, based on what I heard already, meanwhile, the photon map 
>> would still take 6 days, right?
>>
>> Sven
>>
>>
>>
>> "Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
>> news:479bdf30$1@news.povray.org...
>>> Sven Littkowski wrote:
>>>> Hi.
>>>>
>>>> I have a scene, which already takes around 6 days to create the photon 
>>>> map for, if it is done in the same resolution like the remaining scene.
>>>>
>>>> I would like to know, if it is possible to use a lower resolution 
>>>> (let's say: 400x300) for the photon map (with the "save_file" option 
>>>> enabled), and then to stop and continue the scene in a high resolution 
>>>> (now with the "load_file" option enabled).
>>> Sure, I do it myself.  However, since the photon map is independent from 
>>> the scene resolution, you can set the image size absurdly low (like +w1 
>>> +h1) and still get a full-quality photon map.
>>>
>>> -- 
>>> ...Ben Chambers
>>> www.pacificwebguy.com
>>

Post a reply to this message

You might decide to shoot image_width*image_height*some_constant 
photons. Some_constant==1 might work well but feel free to increase for 
high quality or decrease for faster render. Use the count keyword and 
watch POV-ray do its best.
Sven Littkowski napsal(a):
> Hmm... THAT sounds interesting and promising, Jan. I looked into the POV 
> help file, and see the keywords "image_width" and "image_height". And also 
> some examples, how to use them. I really think, this could shorten the 
> calculation time, if I can find out, how to use them properly in connection 
> with my photon map creation.
> 
> Jan, can you give me some more advice in this? If you like, I could post the 
> scene file to you. Please let me know. Thanks,
> 
> Sven
> 
> 
> 
> 
> 
> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
> news:479c31b4$1@news.povray.org...
>> try using image_width to choose the photon count/spacing
>> Sven Littkowski napsal(a):
>>> Hi Ben,
>>>
>>> but even so, based on what I heard already, meanwhile, the photon map 
>>> would still take 6 days, right?
>>>
>>> Sven
>>>
>>>
>>>
>>> "Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
>>> news:479bdf30$1@news.povray.org...
>>>> Sven Littkowski wrote:
>>>>> Hi.
>>>>>
>>>>> I have a scene, which already takes around 6 days to create the photon 
>>>>> map for, if it is done in the same resolution like the remaining scene.
>>>>>
>>>>> I would like to know, if it is possible to use a lower resolution 
>>>>> (let's say: 400x300) for the photon map (with the "save_file" option 
>>>>> enabled), and then to stop and continue the scene in a high resolution 
>>>>> (now with the "load_file" option enabled).
>>>> Sure, I do it myself.  However, since the photon map is independent from 
>>>> the scene resolution, you can set the image size absurdly low (like +w1 
>>>> +h1) and still get a full-quality photon map.
>>>>
>>>> -- 
>>>> ...Ben Chambers
>>>> www.pacificwebguy.com
>

Post a reply to this message

Shooting the image with those keywords... Hmm, do you mean that I need to 
put these two keywords inside the camera directive? To be honest, due the 
lack of experience and knowledge with these two keywords, i would just like 
to ask you to give an example where and how to use these two keywords in a 
scene. I think, that should help me.

Thanks, Jan.

Sven



"Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
news:479cff7f@news.povray.org...
> You might decide to shoot image_width*image_height*some_constant photons. 
> Some_constant==1 might work well but feel free to increase for high 
> quality or decrease for faster render. Use the count keyword and watch 
> POV-ray do its best.
> Sven Littkowski napsal(a):
>> Hmm... THAT sounds interesting and promising, Jan. I looked into the POV 
>> help file, and see the keywords "image_width" and "image_height". And 
>> also some examples, how to use them. I really think, this could shorten 
>> the calculation time, if I can find out, how to use them properly in 
>> connection with my photon map creation.
>>
>> Jan, can you give me some more advice in this? If you like, I could post 
>> the scene file to you. Please let me know. Thanks,
>>
>> Sven
>>
>>
>>
>>
>>
>> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
>> news:479c31b4$1@news.povray.org...
>>> try using image_width to choose the photon count/spacing
>>> Sven Littkowski napsal(a):
>>>> Hi Ben,
>>>>
>>>> but even so, based on what I heard already, meanwhile, the photon map 
>>>> would still take 6 days, right?
>>>>
>>>> Sven
>>>>
>>>>
>>>>
>>>> "Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
>>>> news:479bdf30$1@news.povray.org...
>>>>> Sven Littkowski wrote:
>>>>>> Hi.
>>>>>>
>>>>>> I have a scene, which already takes around 6 days to create the 
>>>>>> photon map for, if it is done in the same resolution like the 
>>>>>> remaining scene.
>>>>>>
>>>>>> I would like to know, if it is possible to use a lower resolution 
>>>>>> (let's say: 400x300) for the photon map (with the "save_file" option 
>>>>>> enabled), and then to stop and continue the scene in a high 
>>>>>> resolution (now with the "load_file" option enabled).
>>>>> Sure, I do it myself.  However, since the photon map is independent 
>>>>> from the scene resolution, you can set the image size absurdly low 
>>>>> (like +w1 +h1) and still get a full-quality photon map.
>>>>>
>>>>> -- 
>>>>> ...Ben Chambers
>>>>> www.pacificwebguy.com
>>

Post a reply to this message

global_settings{
   photons{
     count image_width*image_height
     ...
   }
   ...
}

untested
Sven Littkowski napsal(a):
> Shooting the image with those keywords... Hmm, do you mean that I need to 
> put these two keywords inside the camera directive? To be honest, due the 
> lack of experience and knowledge with these two keywords, i would just like 
> to ask you to give an example where and how to use these two keywords in a 
> scene. I think, that should help me.
> 
> Thanks, Jan.
> 
> Sven
> 
> 
> 
> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
> news:479cff7f@news.povray.org...
>> You might decide to shoot image_width*image_height*some_constant photons. 
>> Some_constant==1 might work well but feel free to increase for high 
>> quality or decrease for faster render. Use the count keyword and watch 
>> POV-ray do its best.
>> Sven Littkowski napsal(a):
>>> Hmm... THAT sounds interesting and promising, Jan. I looked into the POV 
>>> help file, and see the keywords "image_width" and "image_height". And 
>>> also some examples, how to use them. I really think, this could shorten 
>>> the calculation time, if I can find out, how to use them properly in 
>>> connection with my photon map creation.
>>>
>>> Jan, can you give me some more advice in this? If you like, I could post 
>>> the scene file to you. Please let me know. Thanks,
>>>
>>> Sven
>>>
>>>
>>>
>>>
>>>
>>> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
>>> news:479c31b4$1@news.povray.org...
>>>> try using image_width to choose the photon count/spacing
>>>> Sven Littkowski napsal(a):
>>>>> Hi Ben,
>>>>>
>>>>> but even so, based on what I heard already, meanwhile, the photon map 
>>>>> would still take 6 days, right?
>>>>>
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>> "Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
>>>>> news:479bdf30$1@news.povray.org...
>>>>>> Sven Littkowski wrote:
>>>>>>> Hi.
>>>>>>>
>>>>>>> I have a scene, which already takes around 6 days to create the 
>>>>>>> photon map for, if it is done in the same resolution like the 
>>>>>>> remaining scene.
>>>>>>>
>>>>>>> I would like to know, if it is possible to use a lower resolution 
>>>>>>> (let's say: 400x300) for the photon map (with the "save_file" option 
>>>>>>> enabled), and then to stop and continue the scene in a high 
>>>>>>> resolution (now with the "load_file" option enabled).
>>>>>> Sure, I do it myself.  However, since the photon map is independent 
>>>>>> from the scene resolution, you can set the image size absurdly low 
>>>>>> (like +w1 +h1) and still get a full-quality photon map.
>>>>>>
>>>>>> -- 
>>>>>> ...Ben Chambers
>>>>>> www.pacificwebguy.com
> 
>

Post a reply to this message

[Posting to newsgroup since other people may be interested]

Now that you sent me the files... The scene is quite slow to render 
(55pps) even without radiosity or photons. I tried with photons, and 
there were very long periods where the "photons shot" counter didn't 
change, which could mean POV-Ray is shooting lots of photons but 
"missing the object".

What I'm suspecting is that POV-Ray is creating sub-optimal bounding 
boxes. I see a lot of difference objects on your scene. POV-Ray 
sometimes does a bad job bounding difference/intersection CSG.

I'm now rendering a 160x120 image to see the raytrace statistics at the 
end, and see if there were a lot of misses or not. Stay tuned...

Post a reply to this message

Nicolas Alvarez escribió:
> I'm now rendering a 160x120 image to see the raytrace statistics at the 
> end, and see if there were a lot of misses or not. Stay tuned...

Ray->Shape Intersection          Tests       Succeeded  Percentage

Plane                          3224478          124068      3.85
Torus                         12394622          976314      7.88
Torus Bound                   12394622         1072053      8.65
Cone/Cylinder                103967072        15537453     14.94
CSG Intersection              95235655        24004815     25.21
Sphere                        48158288        13067745     27.13
CSG Union                     28433556        12742408     44.81
Box                          261303211       123172730     47.14
Light Buffer                 418693292       219308071     52.38
Blob                          96908476        51630734     53.28
Blob Bound                   883968592       471672540     53.36
Bounding Box                 166046777       100557601     60.56
Vista Buffer                   2803512         1912181     68.21
Blob Component               317778794       254071826     79.95
CSG Merge                     25841750        25837528     99.98

(table sorted by percentage)

Intersection wasn't as bad as I expected. Torus has a particularly low 
value. Plane calculation is quite fast, so that one isn't important.

It's still possible that some manual bounding could improve things.

Post a reply to this message

Nicolas Alvarez napsal(a):
> Nicolas Alvarez escribió:
>> I'm now rendering a 160x120 image to see the raytrace statistics at 
>> the end, and see if there were a lot of misses or not. Stay tuned...
> 
> Ray->Shape Intersection          Tests       Succeeded  Percentage
> 
> Plane                          3224478          124068      3.85
> Torus                         12394622          976314      7.88
> Torus Bound                   12394622         1072053      8.65
> Cone/Cylinder                103967072        15537453     14.94
> CSG Intersection              95235655        24004815     25.21
> Sphere                        48158288        13067745     27.13
> CSG Union                     28433556        12742408     44.81
> Box                          261303211       123172730     47.14
> Light Buffer                 418693292       219308071     52.38
> Blob                          96908476        51630734     53.28
> Blob Bound                   883968592       471672540     53.36
> Bounding Box                 166046777       100557601     60.56
> Vista Buffer                   2803512         1912181     68.21
> Blob Component               317778794       254071826     79.95
> CSG Merge                     25841750        25837528     99.98
> 
> (table sorted by percentage)
> 
> Intersection wasn't as bad as I expected. Torus has a particularly low 
> value. Plane calculation is quite fast, so that one isn't important.
> 
> It's still possible that some manual bounding could improve things.
torus is tested only if its bound fails. It is bounded by a tight 
difference of two cyliders.

Post a reply to this message

Jan Dvorak escribió:
> torus is tested only if its bound fails. It is bounded by a tight 
> difference of two cyliders.

Interesting fact. I knew it, now that you mention it; but I didn't 
remember (been a while since I read it).

Any idea why both torus and its bounding shape have such low hit percentage?

Post a reply to this message

Nicolas Alvarez escribió:
> I tried with photons, and 
> there were very long periods where the "photons shot" counter didn't 
> change, which could mean POV-Ray is shooting lots of photons but 
> "missing the object".

Photon count went up until a minute of shooting passed, then it got 
stuck at 41294 photons shot. Been at that number for *20 minutes*.

There is clearly some bounding issue!

Post a reply to this message

Nicolas Alvarez napsal(a):
> Jan Dvorak escribió:
>> torus is tested only if its bound fails. It is bounded by a tight 
>> difference of two cyliders.
> 
> Interesting fact. I knew it, now that you mention it; but I didn't 
> remember (been a while since I read it).
> 
> Any idea why both torus and its bounding shape have such low hit 
> percentage?
It seems that the number of torus bound tests is used to calculate the 
success percentage. See the table, rays shot. The actual success rate 
for torus in that table is 976314/1072053=91%

Post a reply to this message

Thanks!

Sven


"Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
news:479d4019@news.povray.org...
> global_settings{
>   photons{
>     count image_width*image_height
>     ...
>   }
>   ...
> }
>
> untested
> Sven Littkowski napsal(a):
>> Shooting the image with those keywords... Hmm, do you mean that I need to 
>> put these two keywords inside the camera directive? To be honest, due the 
>> lack of experience and knowledge with these two keywords, i would just 
>> like to ask you to give an example where and how to use these two 
>> keywords in a scene. I think, that should help me.
>>
>> Thanks, Jan.
>>
>> Sven
>>
>>
>>
>> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
>> news:479cff7f@news.povray.org...
>>> You might decide to shoot image_width*image_height*some_constant 
>>> photons. Some_constant==1 might work well but feel free to increase for 
>>> high quality or decrease for faster render. Use the count keyword and 
>>> watch POV-ray do its best.
>>> Sven Littkowski napsal(a):
>>>> Hmm... THAT sounds interesting and promising, Jan. I looked into the 
>>>> POV help file, and see the keywords "image_width" and "image_height". 
>>>> And also some examples, how to use them. I really think, this could 
>>>> shorten the calculation time, if I can find out, how to use them 
>>>> properly in connection with my photon map creation.
>>>>
>>>> Jan, can you give me some more advice in this? If you like, I could 
>>>> post the scene file to you. Please let me know. Thanks,
>>>>
>>>> Sven
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
>>>> news:479c31b4$1@news.povray.org...
>>>>> try using image_width to choose the photon count/spacing
>>>>> Sven Littkowski napsal(a):
>>>>>> Hi Ben,
>>>>>>
>>>>>> but even so, based on what I heard already, meanwhile, the photon map 
>>>>>> would still take 6 days, right?
>>>>>>
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
>>>>>> news:479bdf30$1@news.povray.org...
>>>>>>> Sven Littkowski wrote:
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> I have a scene, which already takes around 6 days to create the 
>>>>>>>> photon map for, if it is done in the same resolution like the 
>>>>>>>> remaining scene.
>>>>>>>>
>>>>>>>> I would like to know, if it is possible to use a lower resolution 
>>>>>>>> (let's say: 400x300) for the photon map (with the "save_file" 
>>>>>>>> option enabled), and then to stop and continue the scene in a high 
>>>>>>>> resolution (now with the "load_file" option enabled).
>>>>>>> Sure, I do it myself.  However, since the photon map is independent 
>>>>>>> from the scene resolution, you can set the image size absurdly low 
>>>>>>> (like +w1 +h1) and still get a full-quality photon map.
>>>>>>>
>>>>>>> -- 
>>>>>>> ...Ben Chambers
>>>>>>> www.pacificwebguy.com
>>

Post a reply to this message

Definatively, I will stay tunes! I am eager for the result, as well as I am 
in such a big need for that photon map file!

Be assured, you will like what you see, as soon as you can see the image 
itself.

The object(s) even allow you to set different day or night times (which 
influences the light inside the scene), as well as you have influence on the 
object self (such as rotor rotation and anges, open doors, etc.).

Best greetings,

Sven




"Nicolas Alvarez" <nic### [at] gmailisthebestcom> schrieb im 
Newsbeitrag news:479d42ea$1@news.povray.org...
> [Posting to newsgroup since other people may be interested]
>
> Now that you sent me the files... The scene is quite slow to render 
> (55pps) even without radiosity or photons. I tried with photons, and there 
> were very long periods where the "photons shot" counter didn't change, 
> which could mean POV-Ray is shooting lots of photons but "missing the 
> object".
>
> What I'm suspecting is that POV-Ray is creating sub-optimal bounding 
> boxes. I see a lot of difference objects on your scene. POV-Ray sometimes 
> does a bad job bounding difference/intersection CSG.
>
> I'm now rendering a 160x120 image to see the raytrace statistics at the 
> end, and see if there were a lot of misses or not. Stay tuned...

Post a reply to this message

Hi Sven!

I haven't seen your scene or know anything about it, but it could be
that two of Mike's excellent tutorials could help you with your bounding
issues:

Mike's isosurface tutorial:
http://www.econym.demon.co.uk/isotut/

Mike's holes tutorial:
http://www.econym.demon.co.uk/holetut/index.htm


HTH,
Florian

Post a reply to this message

Hi Jan,

I added that line to my photon global statement, and so far, I recognize 
that POV-Ray behaves very different to how it was doing the map before.

Yes, there is a clear speed bonus, I recognized that when setting POV to a 
resolution of 160x120. Now I have started at 3200x2400, and wait until some 
result or crash comes. The blocks of photos are now much smaller (before: 
ca. 40,000 before each break, now only 320). I will keep you up to date.

Sven



"Sven Littkowski" <sven [] jamaica-focus [] com> schrieb im Newsbeitrag 
news:479d75c1@news.povray.org...
> Thanks!
>
> Sven
>
>
> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
> news:479d4019@news.povray.org...
>> global_settings{
>>   photons{
>>     count image_width*image_height
>>     ...
>>   }
>>   ...
>> }
>>
>> untested
>> Sven Littkowski napsal(a):
>>> Shooting the image with those keywords... Hmm, do you mean that I need 
>>> to put these two keywords inside the camera directive? To be honest, due 
>>> the lack of experience and knowledge with these two keywords, i would 
>>> just like to ask you to give an example where and how to use these two 
>>> keywords in a scene. I think, that should help me.
>>>
>>> Thanks, Jan.
>>>
>>> Sven
>>>
>>>
>>>
>>> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
>>> news:479cff7f@news.povray.org...
>>>> You might decide to shoot image_width*image_height*some_constant 
>>>> photons. Some_constant==1 might work well but feel free to increase for 
>>>> high quality or decrease for faster render. Use the count keyword and 
>>>> watch POV-ray do its best.
>>>> Sven Littkowski napsal(a):
>>>>> Hmm... THAT sounds interesting and promising, Jan. I looked into the 
>>>>> POV help file, and see the keywords "image_width" and "image_height". 
>>>>> And also some examples, how to use them. I really think, this could 
>>>>> shorten the calculation time, if I can find out, how to use them 
>>>>> properly in connection with my photon map creation.
>>>>>
>>>>> Jan, can you give me some more advice in this? If you like, I could 
>>>>> post the scene file to you. Please let me know. Thanks,
>>>>>
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Jan Dvorak" <jan### [at] centrumcz> schrieb im Newsbeitrag 
>>>>> news:479c31b4$1@news.povray.org...
>>>>>> try using image_width to choose the photon count/spacing
>>>>>> Sven Littkowski napsal(a):
>>>>>>> Hi Ben,
>>>>>>>
>>>>>>> but even so, based on what I heard already, meanwhile, the photon 
>>>>>>> map would still take 6 days, right?
>>>>>>>
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> "Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
>>>>>>> news:479bdf30$1@news.povray.org...
>>>>>>>> Sven Littkowski wrote:
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> I have a scene, which already takes around 6 days to create the 
>>>>>>>>> photon map for, if it is done in the same resolution like the 
>>>>>>>>> remaining scene.
>>>>>>>>>
>>>>>>>>> I would like to know, if it is possible to use a lower resolution 
>>>>>>>>> (let's say: 400x300) for the photon map (with the "save_file" 
>>>>>>>>> option enabled), and then to stop and continue the scene in a high 
>>>>>>>>> resolution (now with the "load_file" option enabled).
>>>>>>>> Sure, I do it myself.  However, since the photon map is independent 
>>>>>>>> from the scene resolution, you can set the image size absurdly low 
>>>>>>>> (like +w1 +h1) and still get a full-quality photon map.
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> ...Ben Chambers
>>>>>>>> www.pacificwebguy.com
>>>
>

Post a reply to this message

Thanks, Florian. I am gonna check 'em out.

Sven



"Florian Brucker" <tor### [at] torfboldcom> schrieb im Newsbeitrag 
news:479dbd61$1@news.povray.org...
> Hi Sven!
>
> I haven't seen your scene or know anything about it, but it could be
> that two of Mike's excellent tutorials could help you with your bounding
> issues:
>
> Mike's isosurface tutorial:
> http://www.econym.demon.co.uk/isotut/
>
> Mike's holes tutorial:
> http://www.econym.demon.co.uk/holetut/index.htm
>
>
> HTH,
> Florian

Post a reply to this message

Nicolas Alvarez escribió:
> Nicolas Alvarez escribió:
>> I tried with photons, and there were very long periods where the 
>> "photons shot" counter didn't change, which could mean POV-Ray is 
>> shooting lots of photons but "missing the object".
> 
> Photon count went up until a minute of shooting passed, then it got 
> stuck at 41294 photons shot. Been at that number for *20 minutes*.

12 hours later, 208446 photons shot.

Post a reply to this message

My PC came to around 32,000, before it crashed. Let's see...

Sven



"Nicolas Alvarez" <nic### [at] gmailisthebestcom> schrieb im 
Newsbeitrag news:479dfa02$1@news.povray.org...
> Nicolas Alvarez escribió:
>> Nicolas Alvarez escribió:
>>> I tried with photons, and there were very long periods where the 
>>> "photons shot" counter didn't change, which could mean POV-Ray is 
>>> shooting lots of photons but "missing the object".
>>
>> Photon count went up until a minute of shooting passed, then it got stuck 
>> at 41294 photons shot. Been at that number for *20 minutes*.
>
> 12 hours later, 208446 photons shot.

Post a reply to this message

Sven Littkowski escribió:
> My PC came to around 32,000, before it crashed. Let's see...
> 

I added autostop 0.0. It's supposed to improve speed. The manual says 
"always use autostop unless it causes problems". I can't tell if it 
"causes problems" until I see the final image :)

Post a reply to this message

Nicolas Alvarez escribió:
> 12 hours later, 208446 photons shot.

Elapsed: 17h 41m
Photons shot so far: 249561

I still see extremely long periods of the counter not moving.

Post a reply to this message

Autostop? Hmm, I just checked the help manual. Interesting! I added it to my 
photon map.

Render Time: Seems, your PC renders fast, too.. Your one is even faster 
since I had to run plenty other programs at the same time. I reached the 
30,000s on day 3. You should reach them on the 24th hour, I think.

Then it will get exciting. Then it will be the time to see, if your system 
masters the crash borderline where my system failed, or not. The countdown 
is on.

Sven



"Nicolas Alvarez" <nic### [at] gmailisthebestcom> schrieb im 
Newsbeitrag news:479e435b@news.povray.org...
> Nicolas Alvarez escribió:
>> 12 hours later, 208446 photons shot.
>
> Elapsed: 17h 41m
> Photons shot so far: 249561
>
> I still see extremely long periods of the counter not moving.

Post a reply to this message

Nicolas Alvarez escribió:
> Nicolas Alvarez escribió:
>> 12 hours later, 208446 photons shot.
> 
> Elapsed: 17h 41m
> Photons shot so far: 249561

Elapsed: 1d 15h 26m
Photons shot: 578211

Post a reply to this message

You passed the crash borderline and are on unknown ground now. That will 
become the mother of all photon map files!

Please keep on keeping me up to date - I am excited to hear more!

Big thanks, best greetings,

Sven



"Nicolas Alvarez" <nic### [at] gmailisthebestcom> schrieb im 
Newsbeitrag news:479f9184$1@news.povray.org...
> Nicolas Alvarez escribió:
>> Nicolas Alvarez escribió:
>>> 12 hours later, 208446 photons shot.
>>
>> Elapsed: 17h 41m
>> Photons shot so far: 249561
>
> Elapsed: 1d 15h 26m
> Photons shot: 578211

Post a reply to this message

"Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
> You passed the crash borderline and are on unknown ground now.

Corageosly going where no other raytracer ever dared...

> That will
> become the mother of all photon map files!

ah, the 1 GB photon map!

Post a reply to this message

nemesis escribió:
>> That will
>> become the mother of all photon map files!
> 
> ah, the 1 GB photon map!
> 

Not really. At the horribly-slow speed this is going, I saw POV-Ray only 
using like 300MB of RAM, which means that's how much of the photon map 
it generated. I have had my own scenes generate 1GB of photons in a few 
minutes :) Let me check exactly how much RAM it's using now.

What?

8MB? And no CPU time?

IT FINISHED??

Post a reply to this message

It did finish! Here are some statistics.

Total rays traced: 1331912707

Biggest number shown in stats: 292325860305, the amount of tests done 
against "Blob bound". Thanks POV-Ray for using 64-bit integers in stats! 
2^32 rays are NOT enough for everybody :)

Roots tested: 37510258644

Number of photons shot:      1328994234
Surface photons stored:         1481333 (0.11% of total photons shot)
Priority queue insert:          1758546
Priority queue remove:          1023832
Gather function called:           37107
Gather radius expanded:               1

Peak memory used:          52514507 bytes (50MB)

Total Scene Processing Times
   Parse Time:    0 hours  0 minutes  2 seconds (2 seconds)
   Photon Time:  47 hours  5 minutes 12 seconds (169512 seconds)
   Render Time:   0 hours  7 minutes  1 seconds (421 seconds)
   Total Time:   47 hours 12 minutes 15 seconds (169935 seconds)
CPU time used: kernel 12.09 seconds, user 168811.69 seconds, total 
168823.78 seconds

Image resolution was 160x120, since all I wanted was the photons. It 
rendered at 6 pixels per minute.

The photon map file is only 29MB!

@Sven: I'll send you the photon map. Can I post the (tiny) image to the 
newsgroup, or is the scene "secret"? :)

Post a reply to this message

Nicolas Alvarez escribió:
> I saw POV-Ray only 
> using like 300MB of RAM

I mean 30MB of course; peak was only 50!

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Nicolas Alvarez escribió:
> > I saw POV-Ray only
> > using like 300MB of RAM
>
> I mean 30MB of course; peak was only 50!

yes, I like the fact that povray is very generous on memory consumption...

Post a reply to this message

Hi Nicolas,

first of all, thanks a lot for your render time! I appreciate it a lot! And 
yes, i woukld love to get that photon map.

Wanna try a 3200 x 2400 photon map..?

Posting the Image:
sure, if you like, post it. But an image of only 160 x 120 is - emmm - not 
thaaat big. I followed up the advices of some other well-informed POV users, 
and used the following keywords inside the global PHOTON statement:
- count image_width*image_height
- autostop 0.0

Create a 3200 x 2400 photon map, and give a try to those keywords. They work 
wonders! Might be, experimenting with their values might even bring 
different optical results...

I am posting here soon a 800 x 600 version of the picture, but go ahead with 
the smaller result. I would like it.

Best greetings, tons of thanks,

Sven





"Nicolas Alvarez" <nic### [at] gmailisthebestcom> schrieb im 
Newsbeitrag news:479fe932$1@news.povray.org...
> Nicolas Alvarez escribió:
>> I saw POV-Ray only using like 300MB of RAM
>
> I mean 30MB of course; peak was only 50!

Post a reply to this message

No, Nemesis, not quite. But this way:

"Sven's photon maps, the final frontier. These are the calculations of the 
raytracer POV-Ray. Its five-year renders: To explore strange new crashes. To 
seek out new pictures and new render arts. To boldly go where no render 
program has gone before."

ORIGINAL
Starship Enterprise (Star Trek):
"Space, the final frontier. These are the voyages of the starship 
Enterprise. Its five-year mission: To explore strange new worlds. To seek 
out new life and new civilizations. To boldly go where no man has gone
before."

Sven



"nemesis" <nam### [at] gmailcom> schrieb im Newsbeitrag
news:web.479fe300af2cf505e094060@news.povray.org...
> "Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
>> You passed the crash borderline and are on unknown ground now.
>
> Corageosly going where no other raytracer ever dared...
>
>> That will
>> become the mother of all photon map files!
>
> ah, the 1 GB photon map!
>
>
>

Post a reply to this message

"to boldly go..."  yes, thanks!  All I ever got from ST was already dubbed to
portuguese...

"These are the calculations of the raytracer POV-Ray"... :)

"Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
> No, Nemesis, not quite. But this way:
>
> "Sven's photon maps, the final frontier. These are the calculations of the
> raytracer POV-Ray. Its five-year renders: To explore strange new crashes. To
> seek out new pictures and new render arts. To boldly go where no render
> program has gone before."
>
> ORIGINAL
> Starship Enterprise (Star Trek):
> "Space, the final frontier. These are the voyages of the starship
> Enterprise. Its five-year mission: To explore strange new worlds. To seek
> out new life and new civilizations. To boldly go where no man has gone
> before."
>
> Sven
>
>
>
> "nemesis" <nam### [at] gmailcom> schrieb im Newsbeitrag
> news:web.479fe300af2cf505e094060@news.povray.org...
> > "Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
> >> You passed the crash borderline and are on unknown ground now.
> >
> > Corageosly going where no other raytracer ever dared...
> >
> >> That will
> >> become the mother of all photon map files!
> >
> > ah, the 1 GB photon map!
> >

Post a reply to this message

Nicolas, if you want to post the pictureinside the images newsgroup, please 
go ahead! i don't mind it at all! I owe you a lot of thanks!

Remember, I still need the photon map file.

Thanks again,

Sven

Post a reply to this message

Sven Littkowski escribió:
> Nicolas, if you want to post the pictureinside the images newsgroup, please 
> go ahead! i don't mind it at all! I owe you a lot of thanks!

I rendered a 640x480 too, took a few hours :) Posting it now.

> Remember, I still need the photon map file.

I already sent it to you... Maybe it got filtered?

Post a reply to this message

Jan Dvorak wrote:
> You might decide to shoot image_width*image_height*some_constant 
> photons. Some_constant==1 might work well but feel free to increase for 
> high quality or decrease for faster render. Use the count keyword and 
> watch POV-ray do its best.

That's a good idea, linking the photon quality to the image resolution. 
  I would assume that if you find a good ratio for a lower resolution, 
it would tend to be a  good ratio for a higher one as well?

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

nemesis wrote:
> "Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
>> You passed the crash borderline and are on unknown ground now.
> 
> Corageosly going where no other raytracer ever dared...
> 
>> That will
>> become the mother of all photon map files!
> 
> ah, the 1 GB photon map!

Been there, done that, crashed my PC at 2Gb utilized by POV-Ray alone :)

Note to self: 3Gb in your system doesn't get around the fact that most 
XP programs are only able to address 2...

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:

> nemesis wrote:
>> "Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
>>> You passed the crash borderline and are on unknown ground now.
>> 
>> Corageosly going where no other raytracer ever dared...
>> 
>>> That will
>>> become the mother of all photon map files!
>> 
>> ah, the 1 GB photon map!
> 
> Been there, done that, crashed my PC at 2Gb utilized by POV-Ray alone :)
> 
> Note to self: 3Gb in your system doesn't get around the fact that most
> XP programs are only able to address 2...
> 
Addendum to note: Having 8GB in your system doesn't prevent Povray from
still having to use the swap space.
-- 
Ger

Post a reply to this message

Ger <No.### [at] ThankYou> wrote:
> Chambers wrote:
> > Been there, done that, crashed my PC at 2Gb utilized by POV-Ray alone :)
> >
> > Note to self: 3Gb in your system doesn't get around the fact that most
> > XP programs are only able to address 2...
> >
> Addendum to note: Having 8GB in your system doesn't prevent Povray from
> still having to use the swap space.

you guys are nuts! :P

Post a reply to this message

Chambers, Ger:

Thanks for that information. I thought until now, the operating system 
handles the RAM, and the programs just forward their RAM requests to Windows 
which would give them, what they need.

I don't knew that programs self address the RAM.

Bad to hear that software developers don't want to work with higher RAM 
addresses. Thought, if RAM is available, the programs could reach it 
dynamically, independent from intented borderlines (2 GB).

Thanks for the information, greetings,

Sven



"Chambers" <ben### [at] pacificwebguycom> schrieb im Newsbeitrag 
news:47a172b4@news.povray.org...
> nemesis wrote:
>> "Sven Littkowski" <sven [] jamaica-focus [] com> wrote:
>>> You passed the crash borderline and are on unknown ground now.
>>
>> Corageosly going where no other raytracer ever dared...
>>
>>> That will
>>> become the mother of all photon map files!
>>
>> ah, the 1 GB photon map!
>
> Been there, done that, crashed my PC at 2Gb utilized by POV-Ray alone :)
>
> Note to self: 3Gb in your system doesn't get around the fact that most XP 
> programs are only able to address 2...
>
> -- 
> ...Ben Chambers
> www.pacificwebguy.com

Post a reply to this message

Sven Littkowski wrote:
> Bad to hear that software developers don't want to work with higher RAM 
> addresses. Thought, if RAM is available, the programs could reach it 
> dynamically, independent from intented borderlines (2 GB).

The issue is that the numbers used to address memory get too big for the
processor to handle. 32-bit pointers simply cannot reference memory
beyond 4 GB -- you need a 64-bit processor with a 64-bit operating
system and 64-bit applications to go beyond that.

Now, I may be wrong, but my understanding is that the 32-bit version of
Windows XP can't use more than 2GB *total* for the entire system.
(That's 4 GB minus 2 GB worth of addresses hard-coded in to refer to
hardware peripherals...) Microsoft helpfully released a patch that makes
memory beyond 2 GB show up as available in the information pane, but XP
still can't actually use it. :-D

Vista can handle 4 GB just fine, but that is offset by the operating
system itself using twice as much memory...

(Nice time to switch to Linux, BTW. We've had a 64-bit version of the OS
available much longer than Microsoft, and have had time to work most of
the compatibility kinks out!)

-- 
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when all your browser bookmarks
have something to do with raytracing.
    -- Taps a.k.a. Tapio Vocadlo

Post a reply to this message

"Sven Littkowski" <sven [] jamaica-focus [] com> wrote:

> Chambers, Ger:
> 
> Thanks for that information. I thought until now, the operating system
> handles the RAM, and the programs just forward their RAM requests to
> Windows which would give them, what they need.
> 
> I don't knew that programs self address the RAM.
> 
> Bad to hear that software developers don't want to work with higher RAM
> addresses. Thought, if RAM is available, the programs could reach it
> dynamically, independent from intented borderlines (2 GB).
> 
> Thanks for the information, greetings,
> 
> Sven
> 
> 

Sven,

I think you have things mixed up. Any modern program lets the operating
system handle the memory. For a program to bypass the OS and try and do the
memory management itself is a sure way to disaster.
The difference is that the older Windows versions don't access anything
above 3GB because they can't address it. It's out of their range. The newer
versions do address it, and in my case with 64bit linux 2^128 bytes is the
theoretical limit (340282366920938463463374607431768211456 which is a LOT).
Having programs go for the "higher" ram addresses is old style DOS
programming.

And as an aside, I do have 8GB RAM and 12GB swap and still manage to have
povray crash with an "out of memory" error :)

-- 
Ger

Post a reply to this message

Chambers escribió:
> Note to self: 3Gb in your system doesn't get around the fact that most 
> XP programs are only able to address 2...
> 

I think there is a way to make it address up to 3GB; but if you have 
4GB, you can't use it all unless you have a 64-bit system.

Post a reply to this message

On Thu, 31 Jan 2008 14:43:59 -0200, Nicolas Alvarez wrote:

> I think there is a way to make it address up to 3GB; but if you have
> 4GB, you can't use it all unless you have a 64-bit system.

PAE lets you get around this.

Jim

Post a reply to this message

Respect!   :-)

Sven



"Ger" <No.### [at] ThankYou> schrieb im Newsbeitrag 
news:47a1f485@news.povray.org...
> And as an aside, I do have 8GB RAM and 12GB swap and still manage to have
> povray crash with an "out of memory" error :)
>
> -- 
> Ger

Post a reply to this message

Please more information on PAE. I would be very interested to hear your 
experiences with it. And a link (but i am gonna search for it now, too).

Thanks!

Sven



"Jim Henderson" <nos### [at] nospamcom> schrieb im Newsbeitrag 
news:47a21a2e$1@news.povray.org...
> On Thu, 31 Jan 2008 14:43:59 -0200, Nicolas Alvarez wrote:
>
>> I think there is a way to make it address up to 3GB; but if you have
>> 4GB, you can't use it all unless you have a 64-bit system.
>
> PAE lets you get around this.
>
> Jim
>

Post a reply to this message

On Thu, 31 Jan 2008 22:57:27 -0500, Sven Littkowski wrote:

> Please more information on PAE. I would be very interested to hear your
> experiences with it. And a link (but i am gonna search for it now, too).

Physical (or Paged) Address Extensions.  Wikipedia has an article on it.

http://en.wikipedia.org/wiki/Physical_Address_Extension

Basically, it's very similar to the changes that led to 32-bit protected 
mode.  If you've programmed in x86 assembly, you know about 
segment:offset addressing.  PAE is a similar concept, but instead of 
using 16-bit registers, it uses 32-bit registers.  The upshot is that you 
can use it to address memory > 4 GB.

I've used it on Linux boxen that have 4 GB of memory or more (though at 
least with SUSE Linux, the PAE-enabled kernels are installed if you have 
> 2 GB of memory, and using it with less doesn't hurt anything.  I 
believe in OpenSUSE/SLE11, they're going to just use PAE kernels 
consistently as if you start with a machine with < 2 GB and then upgrade 
to > 4 GB, you need to switch out the kernel currently).

Jim
-- 
 Jim Henderson, CNA6, CDE, CNI, LPIC-1
 Novell Training Services

Post a reply to this message

Thanks, Jim. Hmm, sounds like it is made for Linux only. But let me research 
a while on Wikipedia and so on...

Sven



"Jim Henderson" <nos### [at] nospamcom> schrieb im Newsbeitrag 
news:47a2a1f3@news.povray.org...
> On Thu, 31 Jan 2008 22:57:27 -0500, Sven Littkowski wrote:
>
>> Please more information on PAE. I would be very interested to hear your
>> experiences with it. And a link (but i am gonna search for it now, too).
>
> Physical (or Paged) Address Extensions.  Wikipedia has an article on it.
>
> http://en.wikipedia.org/wiki/Physical_Address_Extension
>
> Basically, it's very similar to the changes that led to 32-bit protected
> mode.  If you've programmed in x86 assembly, you know about
> segment:offset addressing.  PAE is a similar concept, but instead of
> using 16-bit registers, it uses 32-bit registers.  The upshot is that you
> can use it to address memory > 4 GB.
>
> I've used it on Linux boxen that have 4 GB of memory or more (though at
> least with SUSE Linux, the PAE-enabled kernels are installed if you have
>> 2 GB of memory, and using it with less doesn't hurt anything.  I
> believe in OpenSUSE/SLE11, they're going to just use PAE kernels
> consistently as if you start with a machine with < 2 GB and then upgrade
> to > 4 GB, you need to switch out the kernel currently).
>
> Jim
> -- 
> Jim Henderson, CNA6, CDE, CNI, LPIC-1
> Novell Training Services
>
>

Post a reply to this message

On Fri, 01 Feb 2008 00:55:51 -0500, Sven Littkowski wrote:

> Hmm, sounds like it is made for Linux only.

No, it's a hardware-level implementation used by more than just Linux.  I 
just happen to use Linux almost exclusively, so I haven't run into it 
with other OSes.  For example, NetWare 5.1 (or maybe 6) required machines 
that had PAE functionality, even if the machine had no memory over 4 GB.

Which meant the minimum requirement was a Pentium Pro or P-II, the first 
platform that introduced PAE.  It's been around for a long time.

Jim

Post a reply to this message

Ah... Thanks, Jim. Good knowledge you got there.

But that means, ifit is not some software solution, I can't get it for my 
current system. A pity.

Thanks a lot,

Sven



"Jim Henderson" <nos### [at] nospamcom> schrieb im Newsbeitrag 
news:47a354b7@news.povray.org...
> On Fri, 01 Feb 2008 00:55:51 -0500, Sven Littkowski wrote:
>
>> Hmm, sounds like it is made for Linux only.
>
> No, it's a hardware-level implementation used by more than just Linux.  I
> just happen to use Linux almost exclusively, so I haven't run into it
> with other OSes.  For example, NetWare 5.1 (or maybe 6) required machines
> that had PAE functionality, even if the machine had no memory over 4 GB.
>
> Which meant the minimum requirement was a Pentium Pro or P-II, the first
> platform that introduced PAE.  It's been around for a long time.
>
> Jim

Post a reply to this message

On Fri, 01 Feb 2008 22:31:24 -0500, Sven Littkowski wrote:

> But that means, ifit is not some software solution, I can't get it for
> my current system. A pity.

Only if your system is a 486 or earlier.  As I said, it's in the 
hardware, you just need the software to be written to leverage it.

My original comment was in rsponse to Nicolas' statement that you'd have 
to have a 64-bit system in order to access memory over 4 GB; PAE lets you 
do that on 32-bit systems, so as long as the software is compiled for 
PAE, it can address memory > 4 GB.

Jim

Post a reply to this message

Nicolas Alvarez wrote:
> Chambers escribió:
>> Note to self: 3Gb in your system doesn't get around the fact that most 
>> XP programs are only able to address 2...
>>
> 
> I think there is a way to make it address up to 3GB; but if you have 
> 4GB, you can't use it all unless you have a 64-bit system.

There is a way, but it's not certain to be stable.

XP, being a 32bit OS, allows each program to address up to 4GB of 
memory.  However, this is partitioned into 2GB for the program and 2GB 
for the system.  How having more RAM (say, 3GB like in my system) helps, 
is that each individual program is really addressing a *different* 2GB 
of their own memory.  So although each only uses up to 2Gb locally, the 
total can be up to 4GB of RAM still.

The hack is to make programs think that they have 3GB, and the system 
has 1GB - but this isn't always guaranteed to work, and a lot of 
programs won't with it.

Programs that are compiled for 64bit, or are made aware of large 
addressing systems (I don't remember the MS name for the flag in the 
EXE), aren't limited like this, and will simply use whatever memory the 
system gives them.

-- 
...Ben Chambers
www.pacificwebguy.com

Post a reply to this message