>   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

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

> 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

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