On 2018-09-30 11:48 p.m., clipka wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
> 
While not related to the updated features, this was the winpov64 I used.
Using a newer computer and going though some older scenes.


With no included Work_Threads, or commented out, Work_Threads

Render Time:
   Photon Time:      No photons
   Radiosity Time:   No radiosity
   Trace Time:       0 hours 22 minutes  9 seconds (1329.351 seconds)
               using 3 thread(s) with 3988.077 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 1.16 seconds, user 3992.17 seconds, total 3993.33 
seconds.
Elapsed time 1331.39 seconds, CPU vs elapsed time ratio 3.00.
Render averaged 2433.55 PPS (811.35 PPS CPU time) over 3240000 pixels.

Adding:
Work_Threads = 32
To my .INI file gave me the following outputs.

Render Time:
   Photon Time:      No photons
   Radiosity Time:   No radiosity
   Trace Time:       0 hours  3 minutes 10 seconds (190.047 seconds)
               using 32 thread(s) with 6039.815 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 1.03 seconds, user 6043.08 seconds, total 6044.11 
seconds.
Elapsed time 192.08 seconds, CPU vs elapsed time ratio 31.47.
Render averaged 16867.97 PPS (536.06 PPS CPU time) over 3240000 pixels.


Is there a default some where?

WinPov editor:
Render/Thread Count is set to 32

StephenS

Post a reply to this message

Am 14.10.2018 um 22:26 schrieb StephenS:

> While not related to the updated features, this was the winpov64 I used.
> Using a newer computer and going though some older scenes.
> 
> 
> With no included Work_Threads, or commented out, Work_Threads
> 
> Render Time:
>   Photon Time:      No photons
>   Radiosity Time:   No radiosity
>   Trace Time:       0 hours 22 minutes  9 seconds (1329.351 seconds)
>               using 3 thread(s) with 3988.077 CPU-seconds total
> POV-Ray finished

...
> Is there a default some where?

Yes:

> WinPov editor:
> Render/Thread Count is set to 32

To the best of my knowledge, the mechanism in POV-Ray for Windows is as
follows:

- The number of threads set in the "Render Thread Count" dialog is the
default for each render.

- Any change you make in the dialog is only valid for the current
session; if you close POV-Ray and re-start it, the dialog is
re-populated with the number of cores as reported by the operating system.

- Any `+wtN`, `-wtN` or `Work_Threads=N` in any applicable INI file will
override this setting.

- Any `+wtN`, `-wtN` or `Work_Threads=N` specified in the so-called
"command line" inut field will also override this setting.

- Any `+wtN`, `-wtN` or `Work_Threads=N` passed to the POV-Ray
executable as an actual command line parameter should also affect the
setting, though I'm not sure whether it will change the value in the
dialog or be equivalent to setting it in an INI file. My guess is the
latter.


Obviously the "Render Thread Count" dialog is not initialized to 3 in
your case, so the core count auto-detection works fine, and there must
be /something/ overridding the default.

The master `povray.ini` as well as any `povray.ini` in the same
directory as the scen come to mind.

Post a reply to this message

On 2018-10-15 2:08 a.m., clipka wrote:
...
> The master `povray.ini` as well as any `povray.ini` in the same
> directory as the scen come to mind.
> 

Good call, there was indeed a povray.ini in the same directory.

Separately, I will no longer be reporting WinXP32 feedback unless asked. 
The computer is no longer plugged in with all of it's parts.

StephenS

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> > archive with scene to same email?
> The usual procedure, yes.

did you receive the email?


regards, jr.

Post a reply to this message

Am 17.10.2018 um 15:57 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>>> archive with scene to same email?
>> The usual procedure, yes.
> 
> did you receive the email?

Nope.

Post a reply to this message

Am 21.10.2018 um 01:51 schrieb clipka:
> Am 17.10.2018 um 15:57 schrieb jr:
>> hi,
>>
>> clipka <ano### [at] anonymousorg> wrote:
>>>> archive with scene to same email?
>>> The usual procedure, yes.
>>
>> did you receive the email?
> 
> Nope.

Nevermind. I was a bit confused. Yes, the e-mail did reach me, and I
managed to come up with a fix in no time flat(*), but hadn't gotten
around to providing feedback yet, or push the fix to the repo for that
matter.

(*Interestingly, the bug was in a piece of code I had always been
suspicious about whether I had implemented it correctly. Turns out I
hadn't.)

Post a reply to this message

On 6-10-2018 13:14, William F Pokorny wrote:
> Aside 2: IIRC there is still a thread collision in the current 
> implementation (which Thomas, in 3.8 no longer needs to be "naked" 
> thanks to Christoph's updates) - 
Hmmm... is that so? I am currently using an isosurface and the 
max_gradient warning only shows if the isosurface is "naked" i.e. 
without #declare.

Using v 3.8.0-xtokenizer.9844488+av609.msvc with Win7

-- 
Thomas

Post a reply to this message

On 10/21/18 3:29 AM, Thomas de Groot wrote:
> On 6-10-2018 13:14, William F Pokorny wrote:
>> Aside 2: IIRC there is still a thread collision in the current 
>> implementation (which Thomas, in 3.8 no longer needs to be "naked" 
>> thanks to Christoph's updates) - 
> Hmmm... is that so? I am currently using an isosurface and the 
> max_gradient warning only shows if the isosurface is "naked" i.e. 
> without #declare.
> 
> Using v 3.8.0-xtokenizer.9844488+av609.msvc with Win7
> 

While I'm a couple more days busy with real life, please post as simple 
a scene as you can showing the issue. I'll take a look later this week 
should no one else.

While the issue is certainly fixed for simple cases in 3.8, I've myself 
a mental flag(1) set. A "perhaps we sometimes still get no warnings" flag...

--- Detail
On the periphery of testing late last year or early this, I wondered if 
I'd created such a scene while re-arranging scene code. Isosurface 
warnings went away during that code clean up I thought should probably 
not have disappeared.

It was a less simple scene where the isosurface #declare'd name was used 
across multiple CSG blocks also named and used via #declares. I was 
chasing other stuff at the time and didn't immediately follow up. I 
tried a quick scene I "thought" similar prior to my response to you 
above. It though, worked/warned as it should.

The "naked" max gradient for a given isosurface can be different where 
the isosurface scene usage is other than simple - where not just a 
#declare wrapper. Said another way, if you shoot a different collection 
of rays at an isosurface you can easily have different determined max 
gradients(2).

Bill P.

(1) Mental notes. Why I tend toward drowning in detail instead of 
getting things done. Drives too my footnoting madness. :-)

(2) One of several reasons isosurfaces can be difficult to use in 
animations.

Post a reply to this message

Am 21.10.2018 um 09:29 schrieb Thomas de Groot:
> On 6-10-2018 13:14, William F Pokorny wrote:
>> Aside 2: IIRC there is still a thread collision in the current
>> implementation (which Thomas, in 3.8 no longer needs to be "naked"
>> thanks to Christoph's updates) - 
> Hmmm... is that so? I am currently using an isosurface and the
> max_gradient warning only shows if the isosurface is "naked" i.e.
> without #declare.
> 
> Using v 3.8.0-xtokenizer.9844488+av609.msvc with Win7

It doesn't matter whether you use `#declare` or not; what really matters
is whether there are actually rays shot at the isosurface during the render.

So a `#declare`d isosurface that is never actually inserted into the
scene will never get a warning.

Post a reply to this message

On 22-10-2018 23:33, clipka wrote:
> It doesn't matter whether you use `#declare` or not; what really matters
> is whether there are actually rays shot at the isosurface during the render.
> 
> So a `#declare`d isosurface that is never actually inserted into the
> scene will never get a warning.
> 

@ clipka and Bill:

I am probably totally misunderstanding something, but I attach here a 
simple scene of the Kluchikov Ring with a on/off switch between a 
'declared' and a 'non-declared' isosurface. The 'non-declared' one shows 
a max_gradient warning at the end of the render; the 'declared' one does 
not.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'ak_my favourite isosurface test.7z.zip' (2 KB)