I know the GUI will always open with POV, but is there a way to keep it from
coming to the front when I do a render using the "/RENDER" command-line
switch.  I'd like to be able to do rendering in the background without
having to alt-tab back into what I was doing.

Thanks,

Andrew Wilcox

Post a reply to this message

"Andrew Wilcox" <awi### [at] unpuzzledcom> wrote in message
news:3d32df0a$1@news.povray.org...
> I know the GUI will always open with POV, but is there a way to keep it
from
> coming to the front when I do a render using the "/RENDER" command-line
> switch.  I'd like to be able to do rendering in the background without
> having to alt-tab back into what I was doing.

Not sure this would be the exact answer for you but if you use the Minimize
to Tray button (or Alt+W) then right-click its icon you can choose a file to
render and POV-Ray remains minimized. Sorry, but that's the best I can tell
you.

Post a reply to this message

On Mon, 15 Jul 2002 09:45:40 -0500, "Andrew Wilcox"
<awi### [at] unpuzzledcom> wrote:

>I know the GUI will always open with POV, but is there a way to keep it from
>coming to the front when I do a render using the "/RENDER" command-line
>switch.  I'd like to be able to do rendering in the background without
>having to alt-tab back into what I was doing.

Try telling Windows to run POV-Ray minimized - from the properties of
pvengine.exe. You can do it for shortcuts, I think you can do it on
.exe's as well.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Tue, 16 Jul 2002 00:31:44 +0300, Peter Popov <pet### [at] vipbg> wrote:
> Try telling Windows to run POV-Ray minimized - from the properties of
> pvengine.exe. You can do it for shortcuts, I think you can do it on
> .exe's as well.

BTW. I tried to start pvengine via console START command and seems povray
forces its window to be always maximized. I have tried it also with /NR
option. Here is quote from my batch:

SET PACK_POV_RAY=pvengine.exe
START /LOW /WAIT /MIN %PACK_POV_RAY% /NR /RENDER %PACK_SETTINGS%   
  Output_File_Name="%PACK_DIR%\%PACK_OUTPUT%" All_File="%PACK_OUTPUT%" /EXIT

ABX

Post a reply to this message

> BTW. I tried to start pvengine via console START command and seems povray
> forces its window to be always maximized. I have tried it also with /NR
> option. Here is quote from my batch:
>
> SET PACK_POV_RAY=pvengine.exe
> START /LOW /WAIT /MIN %PACK_POV_RAY% /NR /RENDER %PACK_SETTINGS%
>   Output_File_Name="%PACK_DIR%\%PACK_OUTPUT%" All_File="%PACK_OUTPUT%"
/EXIT
>
> ABX

Thanks, this works.

I'm running it from a Java program so I had do to...

cmd /c start /low /wait /min pvengine.exe /nr /render etc...

Now if there were only a way to keep the splash screen from showing each
time.

I'm very close to having a system where I can send render jobs home from
work, so they'll be ready when I get home, but I don't want to annoy any
users that might be on my home machine at the time (i.e. my wife or
daughter). Assuming I don't kill the processor...

Thanks.

Andrew

Post a reply to this message

In article <3d343d2e@news.povray.org> , "Andrew Wilcox" 
<awi### [at] unpuzzledcom> wrote:

> Now if there were only a way to keep the splash screen from showing each
> time.

That is required such that nobody may obscure the fact that the user is
running POV-Ray.

    Thorsten

Post a reply to this message

I agree that POV-Ray shouldn't be used in the background of some other
application without people knowing that POV-Ray is actually doing the real
work.  I bet the Unix/Linux version doesn't have a splash screen though.
And if someone was unscrupluous enough to try and pass POV-Ray off as their
own work, they could always recompile the sources without those things, but
people would eventually find out what they had done.

Actually, I wouldn't mind the splash screen on startup, if POV would stay in
the backround after that, and not hop to the front for each render, but with
the "start /min /low... /exit" solution, a splash screen comes up for each
and every frame of an animation.  Very annoying, IMHO.

Andrew


> > Now if there were only a way to keep the splash screen from showing each
> > time.
>
> That is required such that nobody may obscure the fact that the user is
> running POV-Ray.
>
>     Thorsten

Post a reply to this message

I just read through the POV-Ray license agreement again, and I understand
completely how the POV team doesn't want people using their hard work for
commercial gain.  POV has been my ray-tracer of choice for nearly 10 years,
and I want you guys to have all the credit you deserve for such a great
piece of software.

I could even understand an argument for wanting the POV-Ray window to come
to the front for each /RENDER so that it's obvious who is doing the work,
but how about a compromise?  The POV-Ray window could open, but not force
itself on top.  Then if POV is running in the background it's still obvious
at some point that it is being used, but it's not hampering what's currently
being done by the user?

Ideas?

Andrew

Post a reply to this message

> Actually, I wouldn't mind the splash screen on startup, if POV would stay in
> the backround after that, and not hop to the front for each render, but with

How many other windows applications can you count that don't get the focus when
they start ? I can't think of any, the exceptions being services or other non-
user-oriented things such as tray applets.

> the "start /min /low... /exit" solution, a splash screen comes up for each
> and every frame of an animation.  Very annoying, IMHO.

Why are you running a separate instance of the program for each frame of the
animation ?

-- Chris

Post a reply to this message

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
> BTW. I tried to start pvengine via console START command and seems povray
> forces its window to be always maximized. I have tried it also with /NR
> option. Here is quote from my batch:

Are you sure you mean maximized ? That means it fills the entire screen.
I don't see how or why that should happen (unless of course you last ran
it maximized ... it will of course remember that fact, which is what it
is supposed to do).

It also used to remember if it was minimized, but that feature was taken
out due to user complaints.

> I have tried it also with /NR option

As the docs say, /NR simply tells the editor to not restore edit sessions.
It has nothing to do with the other settings (such as windows size).

-- Chris

Post a reply to this message

Perhaps, I should better explain what I'm trying to do.

> How many other windows applications can you count that don't get the focus
when
> they start ? I can't think of any, the exceptions being services or other
non-
> user-oriented things such as tray applets.

You're right, most applications when they start do get focus, but in my case
I am using POV-Ray like a service.  I'm building a framework for
distributing renders to my home computers from a remote computer.  The
problem I run into is annoying users that may or may not be on those
computers when the remote render starts, which I plan on being at a very low
priority.

For the most part all of this works right now.  I'm still working on
cleaning it up, but I can submit any number of renders, and have the remote
machine render them one at a time.

Here's the problem I'm facing and the choices I have.

1) If I start a single instance of POV-Ray on startup using ABX's "start"
method, this being my preferred way, then the splash screen shows, and POV
runs minimized, which is great.  If however I then invoke POV again with a
/RENDER it maximizes and comes to the front, thus annoying whoever is on
that remote computer, each and everytime a /RENDER is submitted.

2) I can invoke POV seperately for each render using /RENDER and /EXIT still
using the "start" method, but the splash screen shows each and every time,
which is as annoying as the coming to the front problem.  I have no desire
to supress the splash screen for the very reasons it's there, so...

What I'd really like is for the currently running instance of POV to remain
minimized when a subsequent /RENDER is sent to it, thus behaving like a
background task.  But on startup it would still show it's splash screen,
thus the user would know it was there.

> Why are you running a separate instance of the program for each frame of
the
> animation ?

I have a program that is generating POV SDL files, some of which are frames
of an animation.  Then I spawn the remote renders on all these files.
Particle systems in general have to write a new SDL file for each frame, and
can't use POV's internal clock animation.

Andrew

Post a reply to this message

On Mon, 15 Jul 2002 09:45:40 -0500, "Andrew Wilcox"
<awi### [at] unpuzzledcom> wrote:

>I know the GUI will always open with POV, but is there a way to keep it from
>coming to the front when I do a render using the "/RENDER" command-line
>switch.  I'd like to be able to do rendering in the background without
>having to alt-tab back into what I was doing.

How about waiting for the source and compiling a win32 console
version? Or waiting a couple more hours after the source release when
someone will have compiled it already :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov <pet### [at] vipbg> wrote:
> How about waiting for the source and compiling a win32 console
> version? Or waiting a couple more hours after the source release when
> someone will have compiled it already :)

  Be very careful with the usage license of POV-Ray if you do this and
want to distribute a program bundled with such compiled version of POV-Ray.
  This starts to be close to the part that talks about a program trying to
obfuscate the fact that it's actually using POV-Ray for the rendering.

  (But of course as long as you don't distribute anything, you can do whatever
you want with it.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On Wed, 17 Jul 2002 08:05:46 +1000, "Chris Cason"
<new### [at] deletethispovrayorg> wrote:
> "W?odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
> > BTW. I tried to start pvengine via console START command and seems povray
> > forces its window to be always maximized. I have tried it also with /NR
> > option. Here is quote from my batch:
>
> Are you sure you mean maximized ?

I have rechecked it and it is not maximized. I turned off 
Options -> Other Settings -> Save Settings On Exit
and minimized window before closing. Now with START /MIN it is not maximized
(full screened) but still not minimized.

> It also used to remember if it was minimized, but that feature was taken
> out due to user complaints.

I hope I will have enough time to check in sources if there is another
solution to those "dialogs on minimized starting" problem.

> > I have tried it also with /NR option
>
> As the docs say, /NR simply tells the editor to not restore edit sessions.

I just thought that settings saved with "Save Settings On Exit" is part of
edit session.

ABX

Post a reply to this message

That's why I'm pushing for a compromise.  When the first instance of POV
opens it should do what it does now.  Show the splash, open up, come to the
front etc.  But on subsequent /RENDER commands sent to the original instance
POV should stay minimized if it is minimized, or stay in the tray if it's in
the tray.  That way it's obvious that POV is doing the work, and those of us
that want to use in the background can work.

Am I way off base here?

Andrew

> > How about waiting for the source and compiling a win32 console
> > version? Or waiting a couple more hours after the source release when
> > someone will have compiled it already :)
>
>   Be very careful with the usage license of POV-Ray if you do this and
> want to distribute a program bundled with such compiled version of
POV-Ray.
>   This starts to be close to the part that talks about a program trying to
> obfuscate the fact that it's actually using POV-Ray for the rendering.
>
>   (But of course as long as you don't distribute anything, you can do
whatever
> you want with it.)
>
> --
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

Andrew Wilcox <awi### [at] unpuzzledcom> wrote:
> That's why I'm pushing for a compromise.  When the first instance of POV
> opens it should do what it does now.  Show the splash, open up, come to the
> front etc.  But on subsequent /RENDER commands sent to the original instance
> POV should stay minimized if it is minimized, or stay in the tray if it's in
> the tray.  That way it's obvious that POV is doing the work, and those of us
> that want to use in the background can work.

  Why do you want to restart povray every time you want to render a scene?
Moray renders a lot of scenes and only starts povray once.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Actually, I don't want to restart POV every time.  I only end up down that
route because of the "start" method mentioned earlier.  I'd rather start a
single instance and then send renders to it.  This would be faster because
POV would already be loaded into memory.  The annoyance is that each render
that is sent causes POV to come to the front.  Since I'm working on
distributing renders, I don't know who might be using the computer where the
render starts, and I really don't want to bother them while they're reading
the POV news groups. :-)

Is there some other mechanim to send renders to POV other than simply
"pvengine.exe /RENDER object.ini"?

Andrew


> > That's why I'm pushing for a compromise.  When the first instance of POV
> > opens it should do what it does now.  Show the splash, open up, come to
the
> > front etc.  But on subsequent /RENDER commands sent to the original
instance
> > POV should stay minimized if it is minimized, or stay in the tray if
it's in
> > the tray.  That way it's obvious that POV is doing the work, and those
of us
> > that want to use in the background can work.
>
>   Why do you want to restart povray every time you want to render a scene?
> Moray renders a lot of scenes and only starts povray once.
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -

Post a reply to this message

Andrew Wilcox <awi### [at] unpuzzledcom> wrote:
> Actually, I don't want to restart POV every time.  I only end up down that
> route because of the "start" method mentioned earlier.  I'd rather start a
> single instance and then send renders to it.  This would be faster because
> POV would already be loaded into memory.  The annoyance is that each render
> that is sent causes POV to come to the front.

  AFAIR, it does not do this with Moray. What's the difference?
  (OTOH, I haven't used Moray with pov3.5.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Ok, I just downloaded and installed Moray, and this is the type of behavior
I'm looking for.
Moray has some type of communications DLL.  Perhaps this is no longer the
right group for this thread, but who would I ask about communicating with
POV-Ray directly, rather than simply using Java exec() calls so send
Render's to POV?

I plan on releasing this Java based POV distrubuted render code once I get
it in a user friendly state, the only detail I have left is how to get the
finished renders back to the client that requested them.

Andrew


> > Actually, I don't want to restart POV every time.  I only end up down
that
> > route because of the "start" method mentioned earlier.  I'd rather start
a
> > single instance and then send renders to it.  This would be faster
because
> > POV would already be loaded into memory.  The annoyance is that each
render
> > that is sent causes POV to come to the front.
>
>   AFAIR, it does not do this with Moray. What's the difference?
>   (OTOH, I haven't used Moray with pov3.5.)
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -

Post a reply to this message

"Andrew Wilcox" <awi### [at] unpuzzledcom> wrote in message
news:3d34a172$1@news.povray.org...
> I have a program that is generating POV SDL files, some of which are frames
> of an animation.  Then I spawn the remote renders on all these files.
> Particle systems in general have to write a new SDL file for each frame, and
> can't use POV's internal clock animation.

You could write a GUIEXT and use that to fire up renders.

-- Chris

Post a reply to this message

"Andrew Wilcox" <awi### [at] unpuzzledcom> wrote in message
news:3d35817d$1@news.povray.org...
> That's why I'm pushing for a compromise.  When the first instance of POV
> opens it should do what it does now.  Show the splash, open up, come to the
> front etc.  But on subsequent /RENDER commands sent to the original instance
> POV should stay minimized if it is minimized, or stay in the tray if it's in
> the tray.  That way it's obvious that POV is doing the work, and those of us
> that want to use in the background can work.

The coming to the front is intentional; it's the way that people expect it to
work if you have keep single instance set. This is normal behaviour for those
classes of windows programs that allow a single instance option. If we did
not do what we are currently doing people would complain and this wastes my
time.

The 'coming to the front' behaviour is not, as you seem to think, a means of
forcing people to know what program is in use.

-- Chris

Post a reply to this message

I by no means want to waste your time otherwise we wouldn't have the great
POV-Ray windows version we do now.  It would be nice though if there was a
way to tell POV-Ray to /RENDER but stay in the /BACKGROUND.  It's probably
to tough to add at this point and that's ok.  I'll let it drop.  I'll just
have to endure until I can figure out how to write a GUIEXT that can be
called from Java to fire off renders.

Thanks Chris, everyone for your input,

Andrew

> > That's why I'm pushing for a compromise.  When the first instance of POV
> > opens it should do what it does now.  Show the splash, open up, come to
the
> > front etc.  But on subsequent /RENDER commands sent to the original
instance
> > POV should stay minimized if it is minimized, or stay in the tray if
it's in
> > the tray.  That way it's obvious that POV is doing the work, and those
of us
> > that want to use in the background can work.
>
> The coming to the front is intentional; it's the way that people expect it
to
> work if you have keep single instance set. This is normal behaviour for
those
> classes of windows programs that allow a single instance option. If we did
> not do what we are currently doing people would complain and this wastes
my
> time.
>
> The 'coming to the front' behaviour is not, as you seem to think, a means
of
> forcing people to know what program is in use.
>
> -- Chris
>
>

Post a reply to this message

Andrew Wilcox <awi### [at] unpuzzledcom> wrote:
> Moray has some type of communications DLL.  Perhaps this is no longer the
> right group for this thread, but who would I ask about communicating with
> POV-Ray directly, rather than simply using Java exec() calls so send
> Render's to POV?

  The author of Moray (sorry, can't remember your name from memory :/ )
should be able to help.

  For some reason, the GUI extension thingie is one of the biggest secrets
in POV-Ray. I have been using POV-Ray for a lot of years (at least 5 or 6)
and frequented this news server from almost the very beginning, and yet
I have never seen a description about how it is done, so I haven't the
slightest idea.

  (It's a bit the same kind of secret as for example the ADPCM format. I once
spent several days trying to find the exact specs for the ADPCM WAV format,
but for no avail.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On 17 Jul 2002 16:27:21 -0400, Warp wrote:
> I have never seen a description about how it is done, so I haven't the
> slightest idea.

There is actually some pretty good documentation with the source distribution.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On 17 Jul 2002 16:27:21 -0400, Warp wrote:
> > I have never seen a description about how it is done, so I haven't the
> > slightest idea.
>
> There is actually some pretty good documentation with the source
distribution.
>

Do you mean the 3.5 source?

Post a reply to this message

On Sat, 20 Jul 2002 17:42:12 -0400, Tom Galvin wrote:
> 
> "Ron Parker" <ron### [at] povrayorg> wrote in message
> news:slr### [at] fwicom...
>> On 17 Jul 2002 16:27:21 -0400, Warp wrote:
>> > I have never seen a description about how it is done, so I haven't the
>> > slightest idea.
>>
>> There is actually some pretty good documentation with the source
> distribution.
>>
> 
> Do you mean the 3.5 source?

No, the 3.1 source.  The 3.5 source isn't available yet.

-- 
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}

Post a reply to this message

Would writing a GUIEXT for the 3.1 source work for the 3.5 source, or at
least be a simple conversoin?


> >> On 17 Jul 2002 16:27:21 -0400, Warp wrote:
> >> > I have never seen a description about how it is done, so I haven't
the
> >> > slightest idea.
> >>
> >> There is actually some pretty good documentation with the source
> > distribution.
> >>
> >
> > Do you mean the 3.5 source?
>
> No, the 3.1 source.  The 3.5 source isn't available yet.
>
> --
> #macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_
z)R(-z _-z)
> R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro
S(_)9-(_1-
> _)*(_1-_)#end#macro Z(_1 _
__)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
> rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate
x*90}

Post a reply to this message

"Andrew Wilcox" <awi### [at] unpuzzledcom> wrote in message
news:3d3c17b4@news.povray.org...
> Would writing a GUIEXT for the 3.1 source work for the 3.5 source, or at
> least be a simple conversoin?

It will work without any changes at all.

- Chris

Post a reply to this message

"Chris Cason" <new### [at] deletethispovrayorg> wrote:
> > Actually, I wouldn't mind the splash screen on startup, if POV would stay in
> > the backround after that, and not hop to the front for each render, but with
>
> How many other windows applications can you count that don't get the focus when
> they start ? I can't think of any, the exceptions being services or other non-
> user-oriented things such as tray applets.
>
> > the "start /min /low... /exit" solution, a splash screen comes up for each
> > and every frame of an animation.  Very annoying, IMHO.
>
> Why are you running a separate instance of the program for each frame of the
> animation ?
>
> -- Chris


There is a need for separate instances, for example in a distributed script
based rendering which I am working on at the moment. (to solve my rendering
needs for my fyp submission on semi locked down machines.)

pvengine /exit Z:3kinMain126.in

works but then

pvengine /render Z:3kinMain126.in
Preset source file is 'Z:3kinMain126.in'.
POV-Ray for Windows doesn't recognize this file type ; assuming POV source.
Parse Error: Expected 'object or directive', undeclared identifier 'Width'
found instead
Possible Parse Error: Expected 'object or directive', undeclared identifier
'Width' found instead
File 'Z:3kinMain126.in' line 1: Parse Error: Expected 'object or directive',
undeclared identifier 'Width' found instead
File 'Z:3kinMain126.in' line 1: Possible Parse Error: Expected 'object or
directive', undeclared identifier 'Width' found instead
Render failed


the file name ext is .in as my program scans for ini, and then split out a
...in for each frame to render.




another question I have is that for rendering animations, is it possible to
do some caching, for the precomputed stuff? is there any precompute
computations which can be reuse for each animations frame?


thanks thanks 8)

Post a reply to this message