"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