http://www.daylongraphics.com/products/leveller/render/rwin_halfway.gif

As part of the scanline research, I've got
OpenGL wireframe previewing starting to
work in POV-Ray.

--
Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

On Fri, 6 Jun 2003 01:01:56 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> http://www.daylongraphics.com/products/leveller/render/rwin_halfway.gif
>
> As part of the scanline research, I've got
> OpenGL wireframe previewing starting to
> work in POV-Ray.

IIRC You can look at Moray for comparison.

ABX

Post a reply to this message

Ray Gardener wrote:
> http://www.daylongraphics.com/products/leveller/render/rwin_halfway.gif
> 
> As part of the scanline research, I've got
> OpenGL wireframe previewing starting to
> work in POV-Ray.
> 
> --
> Ray Gardener
> Daylon Graphics Ltd.
> "Heightfield modeling perfected"
> http://www.daylongraphics.com
> 
> 
I have not read the previous (long) thread but that looks very 
promising, and useful .... especially when you have to build a scene and 
place objects in it.


Is there any hope that we see a *nix version of your patch ?

Fabien

Post a reply to this message

Ray Gardener wrote:
> 
> http://www.daylongraphics.com/products/leveller/render/rwin_halfway.gif
> 
> As part of the scanline research, I've got
> OpenGL wireframe previewing starting to
> work in POV-Ray.

Looks promising but how does it show infinite objects (plane, poly),
special shapes (blob, julia_fractal, isosurface) and CSG?

And most important: how does it it invoke OpenGL - i hope in a portable
way so it also works on Mac and Unix.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 06 Jun 2003 13:51:57 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> > http://www.daylongraphics.com/products/leveller/render/rwin_halfway.gif
> > 
> > As part of the scanline research, I've got
> > OpenGL wireframe previewing starting to
> > work in POV-Ray.
>
> Looks promising but how does it show infinite objects (plane, poly),
> special shapes (blob, julia_fractal, isosurface) and CSG?
>
> And most important: how does it it invoke OpenGL - i hope in a portable
> way so it also works on Mac and Unix.

My question is about storing data necessary for OpenGL preview. How memory
consumption increased (let's say for single tree in gilles macro)? Is memory
allocated only during previewing? Some measurements could be interesting.

ABX

Post a reply to this message

I really hope that you made it with system-independent OpenGL code
(eg. by using the GLUT library or whatever).
  Since this kind of thing can be done system-independently, it would be
a shame if you made Windows-only code.

-- 
#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

in news:3ee0cf26@news.povray.org Warp wrote:

>   I really hope that you made it with system-independent OpenGL code
> 

To be honest, I realy wonder why this question, in different forms, has 
come up a few times now as a reaction to a first try / initial test. As 
Ray has stated in several other postings, you all have read, he is fully 
aware of the fact that POV-Ray is / should be / stay a platform 
independent piece of software. And if, for some reason, it is not platform 
independent, I'll hope someone will jump in and help him in making it so.

Ingo

Post a reply to this message

> >   I really hope that you made it with system-independent OpenGL code
> >

I'm not using any Win32-specific OpenGL extensions
(I don't even know what they are or if they
even exist, actually).

Considering OpenGL's portability and hardware support,
it's the best choice all around.

Oh, look... DirectX... hmm... (insert evil laugh)


Ray

Post a reply to this message

Ray Gardener <ray### [at] daylongraphicscom> wrote:
> I'm not using any Win32-specific OpenGL extensions
> (I don't even know what they are or if they
> even exist, actually).

  How do you open the window and give the OpenGL library a handle to it?
Certainly the OpenGL library itself has no function to open windows.

-- 
#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

>   How do you open the window and give the OpenGL library a handle to it?
> Certainly the OpenGL library itself has no function to open windows.


Didn't I already mention that the rendercontext
setup/teardown calls are the platform-specific ones that
(unfortunately) did have to be used?

WinPOV has a bunch of Win32-specific modules
to implement the user interface. That's
where the window and its handle comes from.
So this is not just a POV patch, but
a WinPOV patch too.

But by using the existing render window,
I'm minimizing the amount of Win-specific
code added to WinPOV. Otherwise I'd have
to create an HWND, give it a wndproc routine,
destroy it, etc. etc.

Ray

Post a reply to this message

ingo wrote:
> 
> [...]
> 
> To be honest, I realy wonder why this question, in different forms, has
> come up a few times now as a reaction to a first try / initial test. As
> Ray has stated in several other postings, you all have read, he is fully
> aware of the fact that POV-Ray is / should be / stay a platform
> independent piece of software. And if, for some reason, it is not platform
> independent, I'll hope someone will jump in and help him in making it so.

I am pretty sure everyone who stated concerns about the portability in
this thread is aware that it is possible to program platform independently
with OpenGL but this does not mean any OpenGL code is portable per
definition.

I would suggest to test the portability soon while developing the patch
because otherwise what you describe as 'jumping in' could be a pretty lot
of work.  The fact that quite some people mentioned their concerns seems
an indication that there is quite some interest in such a patch but it is
pretty unlikely that when not being suited for all platforms it would make
it into official POV-Ray or MegaPOV.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Ray Gardener <ray### [at] daylongraphicscom> wrote:
> Didn't I already mention that the rendercontext
> setup/teardown calls are the platform-specific ones that
> (unfortunately) did have to be used?

  My point was that it can be done with no Windows-specific code (for
example using the GLUT library).

-- 
#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

In article <3ee20245@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Ray Gardener <ray### [at] daylongraphicscom> wrote:
> > Didn't I already mention that the rendercontext
> > setup/teardown calls are the platform-specific ones that
> > (unfortunately) did have to be used?
> 
>   My point was that it can be done with no Windows-specific code (for
> example using the GLUT library).

Except that as far as I am aware, the GLUT library can't be used to make 
windows in an otherwise non-GLUT application. It's an application 
framework, with its own event handling, etc. You could easily make a 
cross-platform version, but platforms like Windows and Mac would still 
need their own display setup stuff to incorporate into their GUIs. It 
should be fairly simple to set things up so that it is easy to swap out 
GLUT for platform-specific code.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Except that as far as I am aware, the GLUT library can't be used to make 
> windows in an otherwise non-GLUT application.

  You mean that it's not possible to make POV-Ray use its Windows code for
the editor and other stuff at the same time as opening the preview window
with GLUT code?

  OTOH, this might not even be necessary as long as the program is designed
so that it's easy (eg. with a compiler constant) to use GLUT to open the
preview window in the command-line version of POV-Ray. (In fact, using
GLUT to open a window in the otherwise command-line version is extremely
simple, requiring only a couple of lines of code.)

-- 
#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

Since I'm getting a more and more questions about the
OpenGL stuff, and in the interests of helping make sure
the code is as portable as possible, I will be making
the patch's source code available later today (Not that anyone
couldn't have had it just for the asking, but I want
to get a nice documented .zip file up on my website).

Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com


"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3EE### [at] gmxde...
>
>
> ingo wrote:
> >
> > [...]
> >
> > To be honest, I realy wonder why this question, in different forms, has
> > come up a few times now as a reaction to a first try / initial test. As
> > Ray has stated in several other postings, you all have read, he is fully
> > aware of the fact that POV-Ray is / should be / stay a platform
> > independent piece of software. And if, for some reason, it is not
platform
> > independent, I'll hope someone will jump in and help him in making it
so.
>
> I am pretty sure everyone who stated concerns about the portability in
> this thread is aware that it is possible to program platform independently
> with OpenGL but this does not mean any OpenGL code is portable per
> definition.
>
> I would suggest to test the portability soon while developing the patch
> because otherwise what you describe as 'jumping in' could be a pretty lot
> of work.  The fact that quite some people mentioned their concerns seems
> an indication that there is quite some interest in such a patch but it is
> pretty unlikely that when not being suited for all platforms it would make
> it into official POV-Ray or MegaPOV.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Please visit
http://www.daylongraphics.com/other/povgl/index.htm

for information and source code regarding the OpenGL
wireframing patch for POV-Ray.


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

In article <3ee20a47@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   You mean that it's not possible to make POV-Ray use its Windows code for
> the editor and other stuff at the same time as opening the preview window
> with GLUT code?

That's what I'm saying. GLUT handles everything in its own event loop: 
mouse, keyboard, window updates, menus, etc. I am fairly certain it is 
not designed to coexist with "manual" API calls. You might be able to do 
some things, but I don't think you could use GLUT only to open one 
window in an existing complete application.


>   OTOH, this might not even be necessary as long as the program is designed
> so that it's easy (eg. with a compiler constant) to use GLUT to open the
> preview window in the command-line version of POV-Ray. (In fact, using
> GLUT to open a window in the otherwise command-line version is extremely
> simple, requiring only a couple of lines of code.)

Yes, it could be contained in a small, simple interface to allow 
external code to override the cross-platform stuff.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Ray Gardener <ray### [at] daylongraphicscom> wrote:
> Please visit
> http://www.daylongraphics.com/other/povgl/index.htm

> for information and source code regarding the OpenGL
> wireframing patch for POV-Ray.

  How about providing a binary for those (like me) who don't have any
compiler in Windows (which is pretty common)?

-- 
#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

>   How about providing a binary for those (like me) who don't have any
> compiler in Windows (which is pretty common)?

Okay; should be up later today.

Ray

Post a reply to this message

On Fri, 6 Jun 2003 01:01:56 -0700, "Ray Gardener"
<ray### [at] daylongraphicscom> wrote:

>As part of the scanline research, I've got
>OpenGL wireframe previewing starting to
>work in POV-Ray.

Great work! To be honest, though I've never doubted your programming
skills (I used to play with Leveller when it was around 0.998314b :)
), I thought it would take quite more time to come up with anything
positive. I'm impressed.


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

Post a reply to this message

> Great work! To be honest, though I've never doubted your programming
> skills (I used to play with Leveller when it was around 0.998314b :)
> ), I thought it would take quite more time to come up with anything
> positive. I'm impressed.

Thanks.  I guess all that experience paid off. :)

I was also thinking that previews could be quickly raytraced,
if the parser had an option to ignore all object texture/pigment/finish
attributes and make them all flat diffuse.

Ray

Post a reply to this message

In article <3ee6285d$1@news.povray.org>,
 "Ray Gardener" <ray### [at] daylongraphicscom> wrote:

> I was also thinking that previews could be quickly raytraced,
> if the parser had an option to ignore all object texture/pigment/finish
> attributes and make them all flat diffuse.

You mean like the quality option?
http://povray.org/documentation/view/132/#s05_02_06_01

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Ah, so that's where that's been hiding.
I was using 'preview' as a search term
but 'quality' would have been better.
Maybe someone could add 'preview' as
a search keyword to that topic.

--
Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cja### [at] netplexaussieorg...
> In article <3ee6285d$1@news.povray.org>,
>  "Ray Gardener" <ray### [at] daylongraphicscom> wrote:
>
> > I was also thinking that previews could be quickly raytraced,
> > if the parser had an option to ignore all object texture/pigment/finish
> > attributes and make them all flat diffuse.
>
> You mean like the quality option?
> http://povray.org/documentation/view/132/#s05_02_06_01
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message

> You mean like the quality option?
> http://povray.org/documentation/view/132/#s05_02_06_01

I just noticed that setting the quality lower
doesn't speed up scenes using camera blur.
Is there an INI option to disable a scene's
use of blur?

Ray

Post a reply to this message

On Wed, 11 Jun 2003 01:18:54 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> > You mean like the quality option?
> > http://povray.org/documentation/view/132/#s05_02_06_01
>
> I just noticed that setting the quality lower
> doesn't speed up scenes using camera blur.
> Is there an INI option to disable a scene's
> use of blur?

camera{
  // statement
  #if(USE_BLUR)
    // blur related statement
  #end
}

and in ini settings follow description of "5.2.3.1 Constant"
http://www.povray.org/documentation/view/129/

ABX

Post a reply to this message

"Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
3ee6e5ce@news.povray.org...
> I just noticed that setting the quality lower
> doesn't speed up scenes using camera blur.
> Is there an INI option to disable a scene's
> use of blur?

When I say you really should using POV for real, lol.
In addition to what ABX said, the usual way to deal with complex (or even
less complex) scenes is to add switches at the beginning of your scene that
can turn on and off objects and features (or replace objects by dummies). So
it's like :
#declare BlurOn=1;
#declare RadiosityOn=2; // 0=no rad ; 1=test ; 2=final
#declare MediaOn=1;
#declare MyBigMeshOn=1;
etc.
This makes previewing and testing subsets of the scene very fast.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Yeah, that'll work, but what if a person
receives a scene from someone else that
hasn't been set up that way and he doesn't
know how to edit scenes?

And who's to say that every scene writer
would choose the same constant names
for their quality options, anyway? There's
no guaranteed way to make a quickres.ini
entry that will turn off blur in every scene.

I'd say it's a bug: the quality INI setting
is intended to render scenes faster when
the quality is lower, but it doesn't
actually do that, because it lets some
high-quality features remain enabled.
Being able to work around the problem
isn't a solution, because expending the
effort for the workaround defeats the
very purpose of the Quality setting: to
provide an easy way to globally render
scenes faster without having to care
about the scene's content or code.

Ray


"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:3ee71132$1@news.povray.org...
> "Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
> 3ee6e5ce@news.povray.org...
> > I just noticed that setting the quality lower
> > doesn't speed up scenes using camera blur.
> > Is there an INI option to disable a scene's
> > use of blur?
>
> When I say you really should using POV for real, lol.
> In addition to what ABX said, the usual way to deal with complex (or even
> less complex) scenes is to add switches at the beginning of your scene
that
> can turn on and off objects and features (or replace objects by dummies).
So
> it's like :
> #declare BlurOn=1;
> #declare RadiosityOn=2; // 0=no rad ; 1=test ; 2=final
> #declare MediaOn=1;
> #declare MyBigMeshOn=1;
> etc.
> This makes previewing and testing subsets of the scene very fast.
>
> G.
>
> --
>
> **********************
> http://www.oyonale.com
> **********************
> - Graphic experiments
> - POV-Ray and Poser computer images
> - Posters
>
>

Post a reply to this message

"Ray Gardener" <ray### [at] daylongraphicscom> a écrit dans le message de news:
3ee79113@news.povray.org...
> Yeah, that'll work, but what if a person
> receives a scene from someone else that
> hasn't been set up that way and he doesn't
> know how to edit scenes?

I'm presently working on a project with someone who is a Pov-Ray newbie and
I've set up my scenes like this. It works quite well because the switches
are documented and their function is clear. A few scenes in the Pov-Ray demo
directories works that way too and the scenes many of us offer for download
contains this type of switches. It's really a proven technique and a very
efficient way to optimize scene development. I wouldn't call this a
workaround.

>Being able to work around the problem isn't a solution, because expending
the effort for the workaround defeats the  very >purpose of the Quality
setting: to provide an easy way to globally render scenes faster without
having to care about the >scene's content or code.

Do I want a command-line feature that would turn focal blur off or on ? No!
Radiosity was once partially controlled by a quality setting too, and it's
now 100% SDL because that was what actual use demanded. Existing quality
settings are mostly legacy IMHO. There was a time when simple things could
make POV-Ray crawl, so turning off shadows or using quick colors did make a
lot of sense. But today, machines are fast enough, so most of the
time-saving optimizations involve using more or less high settings for
radiosity, interior statements (media and refraction), photons, area lights,
dispersion, focal blur, reflection and the like, and using stand-ins for
"difficult" objects such as large meshes, isosurfaces or very complex CSG.
These features are complex to set up, so optimizing the development of
scenes including them can only be scene-dependent. Don't expect this to be
solved by OpenGL previewing or quality settings.

I really think you're making too much of a previewing problem that doesn't
really exist.
On the other hand, cylindrical lights not working properly with photons is
currently a problem (for me at least, to be solved before Saturday), if
you're interested by some fancy, hardcore coding ;)

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

On Wed, 11 Jun 2003 13:29:42 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> Yeah, that'll work, but what if a person
> receives a scene from someone else that
> hasn't been set up that way and he doesn't
> know how to edit scenes?

Sorry, but imo editing text files is a basic skill nowadays.

> I'd say it's a bug: the quality INI setting
> is intended to render scenes faster when
> the quality is lower, but it doesn't
> actually do that, because it lets some
> high-quality features remain enabled.

And what if I want raw colors (quality=1) with focal blur to test focal blur ?
And what if I want media without focal blur to test media ?
How could I combine highier Quality setting with lower one ?

> Being able to work around the problem
> isn't a solution, because expending the
> effort for the workaround

It is not workaround. That's the purpose of conditional preprocesor directives:
make parts of scene optionally parsed. Are you writing C++ programs. Can't you
give compiler preprocesor definition? Is this workaround to defining constants
in some kind of config.h or widely used alternative? Every programmer writer
would choose the same preprocesor name for their preprocessor switch? SDL is a
langugage, not GUI interface.

> defeats the
> very purpose of the Quality setting: to
> provide an easy way to globally render
> scenes faster without having to care
> about the scene's content or code.

And it works that way. Blur is not global property of scene but it is feature of
camera. I consider it consistent.

ABX

Post a reply to this message

In article <3ee79113@news.povray.org> , "Ray Gardener" 
<ray### [at] daylongraphicscom> wrote:

> I'd say it's a bug: the quality INI setting
> is intended to render scenes faster when
> the quality is lower, but it doesn't
> actually do that, because it lets some
> high-quality features remain enabled.
> Being able to work around the problem
> isn't a solution, because expending the
> effort for the workaround defeats the
> very purpose of the Quality setting: to
> provide an easy way to globally render
> scenes faster without having to care
> about the scene's content or code.

It is more like a limitation that got in over time.  A few features don't
honor the quality settings the way that one would expect.  I agree that it
is annoying in some cases, but that doesn't mean it won't be changed if
there is sufficient interest.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <fq5gev4mgtjfim61hht3j2aqmc7drejnj7@4ax.com>, abx### [at] abxartpl 
says...
> On Wed, 11 Jun 2003 13:29:42 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
> wrote:
> > Yeah, that'll work, but what if a person
> > receives a scene from someone else that
> > hasn't been set up that way and he doesn't
> > know how to edit scenes?
> 
> Sorry, but imo editing text files is a basic skill nowadays.
> 
> > I'd say it's a bug: the quality INI setting
> > is intended to render scenes faster when
> > the quality is lower, but it doesn't
> > actually do that, because it lets some
> > high-quality features remain enabled.
> 
> And what if I want raw colors (quality=1) with focal blur to test focal blur ?
> And what if I want media without focal blur to test media ?
> How could I combine highier Quality setting with lower one ?
> 
> > Being able to work around the problem
> > isn't a solution, because expending the
> > effort for the workaround
> 
> It is not workaround. That's the purpose of conditional preprocesor directives:
> make parts of scene optionally parsed. Are you writing C++ programs. Can't you
> give compiler preprocesor definition? Is this workaround to defining constants
> in some kind of config.h or widely used alternative? Every programmer writer
> would choose the same preprocesor name for their preprocessor switch? SDL is a
> langugage, not GUI interface.
> 
> > defeats the
> > very purpose of the Quality setting: to
> > provide an easy way to globally render
> > scenes faster without having to care
> > about the scene's content or code.
> 
> And it works that way. Blur is not global property of scene but it is feature of
> camera. I consider it consistent.
> 

Heres an idea.. How about a simple way to have the SDL find out what the 
quality setting you are using is? Then you can use 'that' to 
automatically turn on/off things that you don't want used. I can see 
cases like the focal blur one you mention where it makes sense to leave 
things as they are, but at the same time it makes no sense to me to have 
to edit both the INI and the scene files to get it to turn everything off 
you want turned off for a particular test. However, as far as I can tell 
from a brief search, none of the INI settings can be checked inside the 
SDL. It makes sense to not allow changing them, but not even finding out 
their current values?!

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

> Heres an idea.. How about a simple way to have the SDL find out what the
> quality setting you are using is? ... However, as far as I can tell
> from a brief search, none of the INI settings can be checked inside the
> SDL. It makes sense to not allow changing them, but not even finding out
> their current values?!

That's a good point. Other systems let programs
query their environmental settings (e.g., getenv())

That could also be used to thwart global settings,
however, e.g., "if(setting is on) { do the opposite }"
Sometimes you want a master override switch
that there's nothing the scene can do about.
I would categorize overrides as being different from
environmental variables. You could do a quality
setting at either level for those times:

- When you want to "tell" the scene what you'd like, and

- When you want to force it to do what you like,
  no questions asked.


Here's a (possibly contrived) example: you're setting
up a web gallery and asked to render a hundred third-party
POV scenes into thumbnails. So you configure the quality
settings to omit intensive effects like radiosity/blur/etc.
because you must get all the thumbnails done in 24 hours,
and set up your system to batch render overnight.
You come back the next morning to discover that it's
still halfway through the third picture, becase it
has something that thwarthed the overrides.

Ray

Post a reply to this message

In article <MPG.1952784c48072a12989820@news.povray.org>,
 Patrick Elliott <sha### [at] hotmailcom> wrote:

> Heres an idea.. How about a simple way to have the SDL find out what the 
> quality setting you are using is? Then you can use 'that' to 
> automatically turn on/off things that you don't want used. I can see 
> cases like the focal blur one you mention where it makes sense to leave 
> things as they are, but at the same time it makes no sense to me to have 
> to edit both the INI and the scene files to get it to turn everything off 
> you want turned off for a particular test. However, as far as I can tell 
> from a brief search, none of the INI settings can be checked inside the 
> SDL. It makes sense to not allow changing them, but not even finding out 
> their current values?!

This sounds like a great idea, and is extremely easy to implement...I 
sometimes use a "quality level" indicator, allowing this to adapt to the 
level specified with the quality option makes perfect sense.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Thu, 12 Jun 2003 20:59:51 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> However, as far as I can tell 
> from a brief search, none of the INI settings can be checked inside the 
> SDL.

Wrong searching. You can get values for all clock and frame related ini settings
as well as image dimensions. Additionally next MegaPOV will have reading of
output filename so you can pair it with own text outputs for each frame. Quality
reading could be also interesting.

ABX

Post a reply to this message

On Thu, 12 Jun 2003 14:10:16 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> you're setting
> up a web gallery and asked to render a hundred third-party
> POV scenes into thumbnails.

I hardly see somebody use rendering to make thumbnails. This is wasting of
computation power when rendered full image is available. AA should be high to
get valuable representation of the same content. Almost every 2D image
manipulation app has batch mode to create thumbnails in customized way.

ABX

Post a reply to this message

In article <lfoievs4aokpmd1lgbaji06ejkh6vh39v2@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> On Thu, 12 Jun 2003 20:59:51 -0500, Christopher James Huff
> <cja### [at] earthlinknet> wrote:
> > However, as far as I can tell 
> > from a brief search, none of the INI settings can be checked inside the 
> > SDL.

Uh, no I didn't...Patrick Elliott wrote that.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Fri, 13 Jun 2003 01:47:45 -0500, Christopher James Huff <cja### [at] earthlinknet>
wrote:
> Uh, no I didn't...Patrick Elliott wrote that.

Sorry, answered in a hurry before daily company tasks :-(

ABX

Post a reply to this message

In article <lfoievs4aokpmd1lgbaji06ejkh6vh39v2@4ax.com>, abx### [at] abxartpl 
says...
> On Thu, 12 Jun 2003 20:59:51 -0500, Christopher James Huff
> <cja### [at] earthlinknet> wrote:
> > However, as far as I can tell 
> > from a brief search, none of the INI settings can be checked inside the 
> > SDL.
> 
> Wrong searching. You can get values for all clock and frame related ini settings
> as well as image dimensions. Additionally next MegaPOV will have reading of
> output filename so you can pair it with own text outputs for each frame. Quality
> reading could be also interesting.
> 

Yes the clock, frame and image dimensions are available to the SDL, but I 
was referring to stuff that would not have been considered strictly 
useful to know, like the current quality settings or other options that 
you "can't" retrieve in any direct fashion. So maybe 'none' was 
inaccurate, but I am still right about the rest.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message