Hey folks :)

i'm an aerospace engineer student working on my thesis. One objective is to
write a program for light curves simulation. for this purpose i'm gratefully
using povray because of its realism. The problem is that i want to adjust
parameters in POVRay (like reflection) without always rewriting the povray
skript and without running it seperately.

My idea is to let my main program write an .pov and .ini file after confirming
the parameters. The next step for the main program is to open the console
version of POVRay and initialise rendering with these files.(Starting .ini for
Animation)
The ouput pictures do not need to be shown. Now my main program takes the lead
again and makes use of the pictures.

So for implementing povray in my main programm, I need the console version.  In
the source I found the windows/readme.txt. It describes how to build up a
primitive console version. "..., please modify the configuration as needed, edit
vfe\win\syspovconfig.h to enable the definition of _CONSOLE as noted
therein, and build." Ok, easy step.
But it says also that this console version is only a "simple example" and "If
you wish to make a more comprehensive console that runs on windows, please use
the unix version as a guide,..."

My questions: Is the primitive console version of POVRay for my purpose/idea
sufficing? --> Loading .pov , .ini , start .ini Animation , resolution input,
adjust ouput direction.

Or need I built up the unix version to a win executive with MinGW or Cygwin?
(is it complicated?)

Is there a list of commands to use for the console? in the documentation?

Whats the easiest way to achieve my purpose?


Thank you very much in advance. Sry for my bad english. I hope you understand
most of my text:)

Have a nice weekend!

Daniel

Post a reply to this message

Am 02.04.2016 um 15:04 schrieb whenuwishupon:

> So for implementing povray in my main programm, I need the console version.  In
> the source I found the windows/readme.txt. It describes how to build up a
> primitive console version. "..., please modify the configuration as needed, edit
> vfe\win\syspovconfig.h to enable the definition of _CONSOLE as noted
> therein, and build." Ok, easy step.
> But it says also that this console version is only a "simple example" and "If
> you wish to make a more comprehensive console that runs on windows, please use
> the unix version as a guide,..."
> 
> My questions: Is the primitive console version of POVRay for my purpose/idea
> sufficing? --> Loading .pov , .ini , start .ini Animation , resolution input,
> adjust ouput direction.

I'm not sure what exactly the limitations of the console version are,
but it should be perfectly fine for your purposes.

You might need to specify the number of render threads manually, or
might not get to limit file output to whitelisted directories, or stuff
like that, and of course you won't get a preview display. But the
processing of .ini and .pov files is fully functional (except maybe
shellout commands).

> Is there a list of commands to use for the console? in the documentation?

There isn't any magic to it. Just pass the name of the .ini file as a
command line parameter.

Post a reply to this message

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