In my opinion, two VERY USEFUL features:

- no anti-alias against background
    -> to render sprites, buttons, etc.

- reflection-map
    -> the current reflections are to perfect. Current scenes seems much
to clean!
    A reflection-map can be used to simulate a dirty floors (marble,
wood), streets after rain, etc.

    Syntax (suggestion):

        finish {
                    reflection_map {
                                spotted
                                turbulence 0.2
                                [ 0.0 0.1 ]        -> 20 % reflection
                                [ 0.8 0.2 ]
                                [ 1.0 0.6 ]        -> 50 % reflection
                    }


Bye
 Paul

Post a reply to this message

In article <38A9E46C.15E808B6@alpharay.de>, Paul Blaszczyk 
<3d### [at] alpharayde> wrote:

> - no anti-alias against background
>     -> to render sprites, buttons, etc.

Maybe a good idea...


> - reflection-map
>     -> the current reflections are to perfect. Current scenes seems much
> to clean!
>     A reflection-map can be used to simulate a dirty floors (marble,
> wood), streets after rain, etc.

I think finish_map would be a more flexible and general solution to this 
problem. Or the other extreme: maybe have every texture attribute now 
controlled with a float controlleable by an isosurface-type function. :-)
And everything that accepts a color should accept a pigment too...yes, 
it is insane...

Although I have been thinking of adding the ability to use a pigment as 
a light_source color. It would have two different modes: the usual 
pigment calculation method, where the color of the light at a point is 
the same as the pigment at that point, and a depth based calculation 
method, which would use the length the ray has travelled as the z 
distance when evaluating the pigment(good for wave simulations?).
This would be pretty easy to do, I just haven't had the time...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Patterned and color-mapped light sources?  Fine with me :-)
I can already imagine translating a pigment pattern in a light source and
shifting colors that way or seeing the effect of near light speed travel or
something, etcetera.
But now I've understood what you were saying.  Too bad, oh well, no loss if it
doesn't yet exist anyway.

Bob

"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-206239.19540915022000@news.povray.org...
|
| Although I have been thinking of adding the ability to use a pigment as
| a light_source color. It would have two different modes: the usual
| pigment calculation method, where the color of the light at a point is
| the same as the pigment at that point, and a depth based calculation
| method, which would use the length the ray has travelled as the z
| distance when evaluating the pigment(good for wave simulations?).

Post a reply to this message

Paul Blaszczyk <3d### [at] alpharayde> wrote:
: - no anti-alias against background
:     -> to render sprites, buttons, etc.

  A more general approach:
  Add a new keyword, eg. 'no_antialiasing'. When applied to an object, then
a ray hitting this object will stop the supersampling immediately. Should
be easy to implement.

: - reflection-map
:     -> the current reflections are to perfect. Current scenes seems much
: to clean!

  Wouldn't blurred reflection just do it?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38aa7e1b@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

> : - reflection-map
> :     -> the current reflections are to perfect. Current scenes seems 
> :     much
> : to clean!
> 
>   Wouldn't blurred reflection just do it?

I believe what he wants is a way to vary the amount of reflection 
according to a pattern without having to use a texture_map. A finish_map 
should be sufficient for this, though...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nieminen Juha <war### [at] sarakerttunencstutfi> wrote...
>   A more general approach:
>   Add a new keyword, eg. 'no_antialiasing'. When applied to an object,
then
> a ray hitting this object will stop the supersampling immediately. Should
> be easy to implement.

This could end up more complicated than you might think.

First, radiosity sampling methods generally re-use points from one pixel
calculation to the next.  This would probably not be a problem, though (I
think POV implements something like a dirty-pixel buffer that determines if
it needs to trace the sample or not).

Second, what do you do if you can see an object _through_ another object.
What if the clear blocking object is a crystal?  What if it is, instead, a
media container object?  I have been wondering how to handle this and
similar questions when dealing with post-processing.  There will be ways to
tag objects for post processing, and then let the filter find out if a
tagged object was hit.  But how should those clear media containers be
handled???  And what about not-so-perfectly-clear, yet mostly clear,
objects, like a wine glass.  The other thing to worry about for me is depth.
Which depth should be returned: the first object hit, or the first object
that you'd actually _see_?

-Nathan

Post a reply to this message

On Wed, 16 Feb 2000 00:42:37 +0100, Paul Blaszczyk <3d### [at] alpharayde>
wrote:

>In my opinion, two VERY USEFUL features:
>
>- no anti-alias against background
>    -> to render sprites, buttons, etc.

Render your scene. Save the image.

Add these options to the command line:

+q0 +ua -d -a

Render and save again. Now use the alpha channel from the second image
with the first image and you have an anti-aliased sprite.


Peter Popov
pet### [at] tagpovrayorg
ICQ: 15002700

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: Second, what do you do if you can see an object _through_ another object.

  Well, I think that it could be implemented anyways. The documentation could
state that "this feature may not work well with transparent objects" or
something like that.
  After all, this feature will likely to be used in situations where the
non-antialiased object is directly seen from the camera (like sky spheres
with granite pigment simulating a starfield, etc).
  And if media is not antialiased (because there's a starry sky behind it),
does it matter? AFAIK media doesn't need antialiasing.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38abca64@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

> Nathan Kopp <Nat### [at] koppcom> wrote:
> : Second, what do you do if you can see an object _through_ another 
> : object.
> 
>   Well, I think that it could be implemented anyways. The documentation 
>   could
> state that "this feature may not work well with transparent objects" or
> something like that.
>   After all, this feature will likely to be used in situations where the
> non-antialiased object is directly seen from the camera (like sky spheres
> with granite pigment simulating a starfield, etc).
>   And if media is not antialiased (because there's a starry sky behind 
>   it),
> does it matter? AFAIK media doesn't need antialiasing.


One solution would be to trace one ray, if it hits an object, check that 
object for a flag that tells whether or not to supersample it, and fire 
additional samples based on that information. This would be done at each 
level. It should work correctly with transparency and media, although it 
should probably be turned off when "global" anti-aliasing is turned on.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Peter Popov schrieb:

> On Wed, 16 Feb 2000 00:42:37 +0100, Paul Blaszczyk <3d### [at] alpharayde>
> wrote:
>
> >In my opinion, two VERY USEFUL features:
> >
> >- no anti-alias against background
> >    -> to render sprites, buttons, etc.
>
> Render your scene. Save the image.
>
> Add these options to the command line:
>
> +q0 +ua -d -a
>
> Render and save again. Now use the alpha channel from the second image
> with the first image and you have an anti-aliased sprite.

Good idea...for one button or sprite. But what is with animated sprites
(with MUCH frames)? (e.g. for a game... 100 frames per figure and 10
figures in game).

Paul

Post a reply to this message