 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just an idea for a possible feature.
I'm often stuck tunning some parameter in an include file. It'd be nice if
there were some way to "point" POV-Ray to the actual source to render
rather than the include. That way, I wouldn't have to modify, switch back
to main pov file, render, switch back to include, repeat.
So, in someinclude.inc I would put something like:
#render "myfile.pov"
If I tried to render the include file, it would render myfile.pov instead.
I know...I'm lazy.
-brandon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it brandon who wrote:
>Just an idea for a possible feature.
>
>I'm often stuck tunning some parameter in an include file. It'd be nice if
>there were some way to "point" POV-Ray to the actual source to render
>rather than the include. That way, I wouldn't have to modify, switch back
>to main pov file, render, switch back to include, repeat.
>
>So, in someinclude.inc I would put something like:
>#render "myfile.pov"
>If I tried to render the include file, it would render myfile.pov instead.
>
>I know...I'm lazy.
Such functionality is already available. The thing to notice is that POV
doesn't distinguish a .POV file from a .INC file, so you can just as
easily #include the POV from the INC.
If you #include in both directions, you get into a loop, unless you
#declare variables to manage the control flow.
It's possible to code things slightly simpler than this example if you
are willing to lose some flexibility in the order in which the code gets
executed, and whether you can call the include file more than once, but
the method used in this example gives you total flexibility.
// --- FOO.POV ------------------------------------------
#declare Foo_Pov_Temp = 1;
#version 3.6;
global_settings {assumed_gamma 1.0}
camera {location <0,0,-10> look_at <0,0,0> angle 30}
background {rgb 1}
light_source {<-30, 100, -30> color rgb 1}
#declare T = texture{pigment {rgb 1}}
#include "bar.inc"
object {Thing}
#declare T=texture{pigment {rgb x}}
#include "bar.inc"
object {Thing translate x}
//-------------------------------------------------------
// --- BAR.INC ------------------------------------------
#ifndef(Foo_Pov_Temp)
#include "foo.pov"
#else
// Replace this with your included code
#declare Thing = sphere {0,1 texture {T}}
#end
//-------------------------------------------------------
If you run FOO.POV, it sets the special variable. When BAR.INC gets
called it checks the special variable, and since it is defined, it
performs the included code.
If you run BAR.POV, it checks the special variable. In this case it is
defined, so it calls FOO.POV and skips the included code. Then FOO.POV
calls BAR.INC with the special variable defined and the included code
gets performed.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Mike Williams who wrote:
>
>If you run BAR.POV, it checks the special variable. In this case it is
>defined, so it calls FOO.POV and skips the included code.
Oops. I missed a "not" out of that sentence.
If you run BAR.POV, it checks the special variable. In this case it is
NOT defined, so it calls FOO.POV and skips the included code.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So, in someinclude.inc I would put something like:
> #render "myfile.pov"
> If I tried to render the include file, it would render myfile.pov instead.
Use the +I command line switch.
HTH,
Florian
--
camera{look_at-y*10location<8,-3,-8>*10}#local a=0;#while(a<999)sphere{
#local _=.01*a-4.99;#local p=a*.01-5;#local c=.01*a-4.995;<sin(p*pi)*5p
*10pow(p,5)*.01>sin(c*c*c*.1)+1pigment{rgb 3}}#local a=a+1;#end
/******** http://www.torfbold.com ******** http://www.imp.org ********/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
> Wasn't it brandon who wrote:
>
>>Just an idea for a possible feature.
>>
>>I'm often stuck tunning some parameter in an include file. It'd be nice if
>>there were some way to "point" POV-Ray to the actual source to render
>>rather than the include. That way, I wouldn't have to modify, switch back
>>to main pov file, render, switch back to include, repeat.
>>
>>So, in someinclude.inc I would put something like:
>>#render "myfile.pov"
>>If I tried to render the include file, it would render myfile.pov instead.
>>
>>I know...I'm lazy.
>
>
>
> Such functionality is already available. The thing to notice is that POV
> doesn't distinguish a .POV file from a .INC file, so you can just as
> easily #include the POV from the INC.
>
> If you #include in both directions, you get into a loop, unless you
> #declare variables to manage the control flow.
>
> It's possible to code things slightly simpler than this example if you
> are willing to lose some flexibility in the order in which the code gets
> executed, and whether you can call the include file more than once, but
> the method used in this example gives you total flexibility.
>
> // --- FOO.POV ------------------------------------------
> #declare Foo_Pov_Temp = 1;
>
> #version 3.6;
> global_settings {assumed_gamma 1.0}
> camera {location <0,0,-10> look_at <0,0,0> angle 30}
> background {rgb 1}
> light_source {<-30, 100, -30> color rgb 1}
>
> #declare T = texture{pigment {rgb 1}}
> #include "bar.inc"
> object {Thing}
>
> #declare T=texture{pigment {rgb x}}
> #include "bar.inc"
> object {Thing translate x}
> //-------------------------------------------------------
>
>
> // --- BAR.INC ------------------------------------------
> #ifndef(Foo_Pov_Temp)
> #include "foo.pov"
> #else
> // Replace this with your included code
> #declare Thing = sphere {0,1 texture {T}}
> #end
> //-------------------------------------------------------
>
> If you run FOO.POV, it sets the special variable. When BAR.INC gets
> called it checks the special variable, and since it is defined, it
> performs the included code.
>
> If you run BAR.POV, it checks the special variable. In this case it is
> defined, so it calls FOO.POV and skips the included code. Then FOO.POV
> calls BAR.INC with the special variable defined and the included code
> gets performed.
>
a couple of remarks
1) brandon's solution is more simple and more logical
2) both don't work in general. It only works for include files that
are unique to one POV file. I know this happens often and has been
the case whenever I had the same problem as brandon It is not a rule
(think about all those usefull packages) and from a developers point
of view I would say that it possibly should be discouraged.
For any include file shared by more than one povfile no system
that associates that include with a povfile can work.
3) What would work is if we had a method to select the previous
render to rerender. Guess what, that does already exist, only
it takes 3 clicks to do, so I seldom use it. Possibly the fastest
way to increase the useability of it would be to have one button or
shortcut to rerender the latest pov file. And perhaps even that exists
already.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmail com> wrote:
> Mike Williams wrote:
> > Wasn't it brandon who wrote:
> >
> >>Just an idea for a possible feature.
> >>
> >>I'm often stuck tunning some parameter in an include file. It'd be nice if
> >>there were some way to "point" POV-Ray to the actual source to render
> >>rather than the include. That way, I wouldn't have to modify, switch back
> >>to main pov file, render, switch back to include, repeat.
> >>
> >>So, in someinclude.inc I would put something like:
> >>#render "myfile.pov"
> >>If I tried to render the include file, it would render myfile.pov instead.
> >>
> >>I know...I'm lazy.
> >
> >
> >
> > Such functionality is already available. The thing to notice is that POV
> > doesn't distinguish a .POV file from a .INC file, so you can just as
> > easily #include the POV from the INC.
> >
> > If you #include in both directions, you get into a loop, unless you
> > #declare variables to manage the control flow.
> >
> > It's possible to code things slightly simpler than this example if you
> > are willing to lose some flexibility in the order in which the code gets
> > executed, and whether you can call the include file more than once, but
> > the method used in this example gives you total flexibility.
> >
> > // --- FOO.POV ------------------------------------------
> > #declare Foo_Pov_Temp = 1;
> >
> > #version 3.6;
> > global_settings {assumed_gamma 1.0}
> > camera {location <0,0,-10> look_at <0,0,0> angle 30}
> > background {rgb 1}
> > light_source {<-30, 100, -30> color rgb 1}
> >
> > #declare T = texture{pigment {rgb 1}}
> > #include "bar.inc"
> > object {Thing}
> >
> > #declare T=texture{pigment {rgb x}}
> > #include "bar.inc"
> > object {Thing translate x}
> > //-------------------------------------------------------
> >
> >
> > // --- BAR.INC ------------------------------------------
> > #ifndef(Foo_Pov_Temp)
> > #include "foo.pov"
> > #else
> > // Replace this with your included code
> > #declare Thing = sphere {0,1 texture {T}}
> > #end
> > //-------------------------------------------------------
> >
> > If you run FOO.POV, it sets the special variable. When BAR.INC gets
> > called it checks the special variable, and since it is defined, it
> > performs the included code.
> >
> > If you run BAR.POV, it checks the special variable. In this case it is
> > defined, so it calls FOO.POV and skips the included code. Then FOO.POV
> > calls BAR.INC with the special variable defined and the included code
> > gets performed.
> >
> a couple of remarks
> 1) brandon's solution is more simple and more logical
> 2) both don't work in general. It only works for include files that
> are unique to one POV file. I know this happens often and has been
> the case whenever I had the same problem as brandon It is not a rule
> (think about all those usefull packages) and from a developers point
> of view I would say that it possibly should be discouraged.
> For any include file shared by more than one povfile no system
> that associates that include with a povfile can work.
> 3) What would work is if we had a method to select the previous
> render to rerender. Guess what, that does already exist, only
> it takes 3 clicks to do, so I seldom use it. Possibly the fastest
> way to increase the useability of it would be to have one button or
> shortcut to rerender the latest pov file. And perhaps even that exists
> already.
Would it not be better just to get into the habit of using an ini file? This
would then be placed in the option box at the top. No matter what file you
are editting the ini file will control POVRay and what it should render.
This also provides control over render quality and size for test runs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
