Am 2016-04-02 10:40, also sprach clipka:
> Am 02.04.2016 um 15:04 schrieb whenuwishupon:

What clipka said.

I have been using the console version pretty heavy for about 6 months.
I add
-L/Users/dick/Documents/POV-Ray/v3.7/include -wt8
to the command line. My quad core i7 has 8 threads (-wt8) and -L 
obviously points to the povray include files.

I, too, run heavily automated povconsole64.exe .  The only downer I've 
seen is once in a blue moon, povconsole will exit immediately without 
generating any output whatsoever. (out of 26,532 renders this has 
happened maybe 30 times). Other than that, it runs great.

I don't do shellout commands, so I can't comment on that. I can't really 
see the need for them.
I do animation, and I prefer -SF100 -EF100 on the command line and keep 
the .ini file constant. One frame per povconsole call.
-- 
dik

Post a reply to this message

Thank you for the positive responses and your time. Your experience gives me
confidence to not wasting time on this problem. Next week my university will
provide me with a Visual Basic Standard Licence. Therefore I can't test it now.
Report follows.

Post a reply to this message

Am 02.04.2016 um 22:14 schrieb whenuwishupon:
> Thank you for the positive responses and your time. Your experience gives me
> confidence to not wasting time on this problem. Next week my university will
> provide me with a Visual Basic Standard Licence. Therefore I can't test it now.
> Report follows.

You surely mean Visual Studio, right?

POV-Ray is written in C++, so Visual Basic will get you nowhere; you'll
need Visual C++. Microsoft Visual Studio includes both.

As far as licenses are concerned, as a student you most likely qualify
for the free Community edition of Visual Studio 2015, which is known to
work "out of the box" with the current master branch of POV-Ray (unlike
the Express editions of older Visual Studio versions).

Post a reply to this message

On 03.04.2016 15:01, clipka wrote:

> You surely mean Visual Studio, right?

I think he just wants to create a program that writes pov files
based on parameters and then renders via command line. No need to
build own version of pov or use c++ for that.

Post a reply to this message

Am 2016-04-05 09:38, also sprach Christian Froeschlin:
> On 03.04.2016 15:01, clipka wrote:
>
>> You surely mean Visual Studio, right?
>
> I think he just wants to create a program that writes pov files
> based on parameters and then renders via command line. No need to
> build own version of pov or use c++ for that.

You need to build your own version of povconsole(64).exe. There are no 
published executables for that.


-- 
dik

Post a reply to this message

Le 05/04/2016 17:47, dick balaska a écrit :
> Am 2016-04-05 09:38, also sprach Christian Froeschlin:
>> On 03.04.2016 15:01, clipka wrote:
>>
>>> You surely mean Visual Studio, right?
>>
>> I think he just wants to create a program that writes pov files
>> based on parameters and then renders via command line. No need to
>> build own version of pov or use c++ for that.
> 
> You need to build your own version of povconsole(64).exe. There are no published
executables for that.
> 
> 
cannot he used the official binary with the right option ?

such as /NR /EXIT /RENDER and may be /THREADS

 http://wiki.povray.org/content/Documentation:Windows_Section_3#Special_Command-Line_Options

Post a reply to this message

Am 2016-04-05 13:20, also sprach Le_Forgeron:
> Le 05/04/2016 17:47, dick balaska a écrit :
>> Am 2016-04-05 09:38, also sprach Christian Froeschlin:
>>> On 03.04.2016 15:01, clipka wrote:
>>>
>>>> You surely mean Visual Studio, right?
>>>
>>> I think he just wants to create a program that writes pov files
>>> based on parameters and then renders via command line. No need to
>>> build own version of pov or use c++ for that.
>>
>> You need to build your own version of povconsole(64).exe. There are no published
executables for that.
>>
>>
> cannot he used the official binary with the right option ?
>
> such as /NR /EXIT /RENDER and may be /THREADS
>
>  
http://wiki.povray.org/content/Documentation:Windows_Section_3#Special_Command-Line_Options

I suppose, yes.  It still opens the povwin window though, which is 
annoying if you want to do background renders. (focus stealing monster)


-- 
dik

Post a reply to this message

Hey, thank you for your answers.

> >>>> You surely mean Visual Studio, right?

Yes I meant Visual Studio. Not Visual Basic. Sry

> >>> I think he just wants to create a program that writes pov files
> >>> based on parameters and then renders via command line. No need to
> >>> build own version of pov or use c++ for that.

No. I want a standalone console build without GUI, if possible.

> I suppose, yes.  It still opens the povwin window though, which is
> annoying if you want to do background renders. (focus stealing monster)

That's what I want to avoid. The extern program would have to open the hole GUI
for every frame. Just like you said. My wish is to have background rendering.


Now I have Visual Studio 2015 Community. I downloaded the MASTER open source 3.7
and followed the instruction. I activated _CONSOLE in
\povray-master\povray-master\windows\povconfig\syspovconfig.h(it's in
\povray-3.7-stable\povray-3.7-stable\vfe\win in the stable version)


I also activated "console" and deactivated "GUI" in the build-configuration of
Visual Studio. I built x64 release with local debugger. No Errors, few warnings.
But Visual Studio couldn't start and find povengine.exe.

So I did the same process with "GUI" activated. I received 1 error "#error:  You
are building the GUI platform with _CONSOLE defined (check
vfe\win\syspovconfig.h)." and Visual Studio also couldn't start and find
povengine.exe .

What did I do wrong?

The stable Version works very badly for me. Same result. But with 140 errors.

Post a reply to this message

I solved the problem for master source code. I forgot to select Windows Targets
-> console as start-up Project. 92 warnings, but povconsole64.exe is there.
Now I will test it.

what's the difference between stable and master source code?

Post a reply to this message

Am 06.04.2016 um 16:10 schrieb whenuwishupon:
> I solved the problem for master source code. I forgot to select Windows Targets
> -> console as start-up Project. 92 warnings, but povconsole64.exe is there.
> Now I will test it.
> 
> what's the difference between stable and master source code?


The stable branch holds the latest official release, currently 3.7.0.

Any behaviour -- whether intentional or otherwise -- of a "stable"
release becomes "canonical" in the sense that you can reasonably expect
future versions to behave in the same manner, provided you make proper
use of the "#version" statement. (Behaviour resulting from bugs that a
user cannot possibly mistake for being intentional is routinely exempt
from this protection, and features explicitly reported as "experimental"
also have some risk of being intentionally changed as well.)

Also, "stable" versions have undergone a phase of pure bugfixing, so
presumably they contain comparatively few bugs.


The master branch, on the other hand, is where development happens,
currently in preparation for what will become 3.7.1.

On the upside, this means that the version will contain the latest and
greatest new features.

On the downside, any behaviour of a development version that differs
from the previous stable release may be subject to change without notice.

Also, development versions are more prone to bugs.


At present however, the value of the "stable" branch happens to be
greatly diminished by the following factors:

- C++11: The new standard has become widely adopted /after/ the latest
stable version; as it turns out, POV-Ray contained various
incompatibilities with the new standard, so contemporary build
environments like Visual Studio 2015 or modern versions of GCC gag on
the latest stable version. Even in the master branch the C++11-related
problems have only recently been ironed out completely.

- Boost and Automake: Both boost 1.50 and a comparatively recent
Automake incarnation introduced some breaking changes that interfered
with our Unix build process, and which we found time to work around only
after the latest stable release (mainly because the primary developers
are notorious Windows jockeys).

- Sub-optimal software lifecycle management: Ideally, when bugs or
issues are discovered that were already present in the latest stable
version, they should be fixed in the stable branch and then ported to
the development branch. However, in the past, both feature and bugfixing
development has been made on the master branch, and to this day nobody
has made the endeavour to isolate and port those fixes to the stable branch.

Post a reply to this message