|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
playing around with some code, I get:
File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
Fatal error in parser: Cannot parse input.
the problem is, the file ends at line 39. :-) line 38 contains an
'#undef' which destroys a variable '#declare'd in same file.
archive with scene to same email?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.10.2018 um 16:16 schrieb jr:
> File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
> Fatal error in parser: Cannot parse input.
>
> the problem is, the file ends at line 39. :-) line 38 contains an
> '#undef' which destroys a variable '#declare'd in same file.
>
> archive with scene to same email?
>
> regards, jr.
The usual procedure, yes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |