I think it should be fairly simple to implement and should work this way:
it would control the trace level at which the object becomes visible.
Eg: visibility_level 0: this should do nothing.
visibility_level 1: the object wouldn't be directly visible but it would be
reflected and refracted and it would be taken into account for radiosity
calculations.
visibility_level n: the object wouldn't be directly visible but it would
become visible starting from the n_th level of recursion.

Of course if n> max_trace_level-1 the object wouldn't be visible at all.

I think this would be a much more powerful flag than no_image.

Any takers?
I saw this somewhere, but can't remember where.


--
Jonathan.

Home: http://digilander.iol.it/jrgpov

Post a reply to this message

In article <3c24e9f2@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:

> I think this would be a much more powerful flag than no_image.

Great idea! It would make the usage so unintuitive that nobody could use it
and it would have the great feature of breaking old scenes.

What is wrong with the current no_image and no_reflection flags other than
that they are easier to use?

    Thorsten

Post a reply to this message

Who talked about removing no_image and no_reflection?

The problem with the current implementation is that radiosity calculations
don't take into account no_image objects.

Imagine this situation: you have a very small room. If you put the camera
into it you have to use a wide angle to catch all the scene, but everything
gets distorted. Now you can use the no_image flag to *delete* one wall so
that you can put the camera outside the room. Every reflective object will
reflect the wall so everything should look right. The problem arises if
you're using radiosity, since the *no_image* wall won't *participate* to the
radiosity calculations, which is not what I want.

Thus, my request could be turned into "add a radiosity flag", to turn on and
off radiosity calculations for specific objects (but no_image should not
imply no_radiosity) or, at least, allow radiosity calculations for no_image
objects.

That being said, I would still like a visibility_level flag as described in
my previous post.

--
Jonathan.

"Thorsten Froehlich" <tho### [at] trfde> ha scritto nel messaggio
news:3c250fcc$1@news.povray.org...
> In article <3c24e9f2@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:
>
> > I think this would be a much more powerful flag than no_image.
>
> Great idea! It would make the usage so unintuitive that nobody could use
it
> and it would have the great feature of breaking old scenes.
>
> What is wrong with the current no_image and no_reflection flags other than
> that they are easier to use?
>
>     Thorsten

Post a reply to this message

JRG wrote:
> 

1. Learn to quote, put your answer after the text you are responding to.
Thanks; it make it easier to build the dialogue.

> Who talked about removing no_image and no_reflection?
> 

2. Nobody, but from your description, no_image and no_reflection would have been 
possible weaker forms, hence removing them might have helped to simplify the SDL. 

> The problem with the current implementation is that radiosity calculations
> don't take into account no_image objects.

2. This aspect was not in your initial query. You did not even mention radiosity.
   It's look like you're asking something while wanting something else.
   (asking for new feature, while wanting radiosity evolution/debugging)

[Example deleted/skipped]

> That being said, I would still like a visibility_level flag as described in
> my previous post.

3. As I had done the debugging of no_reflection and no_image, it would not cost you
too much. You would probably increase each object with another unsigned integer 
(short ?) and might have to surcharge the NO_IMAGE and NO_REFLECTION flags.

BUT:
 - I do not see the interest of it (as exposed in your initial request)
 - I'm personaly against it
 - it is too late for 3.5, but too soon for doing your own patch 
    because 3.5 source is not yet available.
 - if you want it in 3.1g, you will have to reintegrate some patches first.
   (the no_image and no_reflection, at least).
 - I think you did not consider enough the potential of your request:
    what if I want some object to appear ONLY for trace_level 2,3,4,7,8,9 and 
    from 12 to 31 ? You might be opening a can of worms...
 - Last, you came to that solution because you had a problem with radiosity...
   Fixing the wheels won't put gazoline in the tank!

-- 
Non Sine Numine
http://grimbert.cjb.net/

Post a reply to this message

JRG wrote:
>
> no_radiosity

I would use it for realistic light sources.
If pure ambient sources are used this is not a problem.
When light sources are used the ambient object still has
to be there for reflections and in direct view but not
emit light.


_____________
Kari Kivisalo

Post a reply to this message

L'Harmonieux Forgeron wrote:
> 1. Learn to quote, put your answer after the text you are responding to.
> Thanks; it make it easier to build the dialogue.

That's what I usually do.

> 2. Nobody, but from your description, no_image and no_reflection would
have been
> possible weaker forms, hence removing them might have helped to simplify
the SDL.

They could be useful shortcuts.

> 2. This aspect was not in your initial query. You did not even mention
radiosity.

Which means you didn't pay attention to my first post (radiosity is
mentioned there).

>    It's look like you're asking something while wanting something else.
>    (asking for new feature, while wanting radiosity evolution/debugging)

That was just an example. I thought of the most general feature which might
include what I was looking for.

> 3. As I had done the debugging of no_reflection and no_image, it would not
cost you
> too much. You would probably increase each object with another unsigned
integer
> (short ?) and might have to surcharge the NO_IMAGE and NO_REFLECTION
flags.

Let me have my C exam and I will give it a try.

> BUT:
>  - I do not see the interest of it (as exposed in your initial request)

YHO

>  - I'm personaly against it

Morally?

>  - it is too late for 3.5, but too soon for doing your own patch

There's no hurry. And nobody talked about 3.5. This is
povray.unofficial.patches, isn't it?

>  - Last, you came to that solution because you had a problem with
radiosity...
>    Fixing the wheels won't put gazoline in the tank!

As I said, I looked for the most general solution.

--
Jonathan.

Post a reply to this message

I personally use two copies of the light bulb: one with not too high ambient
and no_reflection. The other one with high ambient (10 or up) and the
no_image flag.
That's what I used for the Cornell box scenes posted in p.b-i.

--
Jonathan.

"Kari Kivisalo" <ray### [at] engineercom> ha scritto nel messaggio
news:3C2622C4.2B630268@engineer.com...
> JRG wrote:
> >
> > no_radiosity
>
> I would use it for realistic light sources.
> If pure ambient sources are used this is not a problem.
> When light sources are used the ambient object still has
> to be there for reflections and in direct view but not
> emit light.
>
>
> _____________
> Kari Kivisalo

Post a reply to this message

In article <3c2515a3@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:

> The problem arises if
> you're using radiosity, since the *no_image* wall won't *participate* to the
> radiosity calculations, which is not what I want.

Well, this is exactly like in the real world: If something is invisible you
can't see it.  (Of course, no_reflection isn't natural either.)

However, your idea of a "visibility_level flag" is fundamentally flawed.
First of all, you say it is a flag but what you say it should do has nothing
to do with a flag.  More important, what you want it to do is actually three
(or more?) things in one.  But how would you combine effects?  You soon have
to start assigning arbitrary numbers to effects, which makes it unusable
without a table that maps effect combinations to numbers.

And as for your "if n> max_trace_level-1 the object wouldn't be visible at
all" idea, well, how do you define the maximum level?  What intersections
would count and how would one define which intersections count?  Remember
that an object can have any from 0 to and infinite number of intersections.
So depending on the viewpoint you could have ten intersections with one
object while from another you only have two.

In no way would make the feature you suggest any sense.

A much more practical solution to your problem would be to design your scene
so that the camera fits properly "inside".  After all, the effect you want
is physically impossible a camera looking through a invisible wall that is
visible in indirect reflections.  Maybe you should simply consider a
different camera type and some creativity of what you have got rather than
thinking of the most complicated possible solution to such a simple problem
as perspective camera distortion effects...


    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

Aw, come on it was just an example.
Lightflow has got it for example:

string "visibility", int depth
Specify the tracing depth at which the objects made from this material start
to be visible.
This is useful to make objects appear only inside reflections, for example
to create rich environments though mantaining a black background.
The default value is 0.

To me it does make sense. Look at the Lightflow's cornell box posted to
p.b-i. You wouldn't say it's physically impossible, but the camera is just
two units outside the actual box. And I won't mention how many times I would
have wanted to render a nice radiosity scene with a black background (using
a no_image sky_sphere).

Really, I thought about this as a more general and simple way to resolve
many different problems. One single keyword which would include so many
different effects. I don't need it just now for an actual scene.

What I'd need is truly the _no_image_ objects to participate to radiosity
calculations. Of course this may be an undesirable effect in some
circumstances. Thus I think a no_radiosity flag would be more logical (as
long as no_image doesn't directly imply no_radiosity).

But you can forget what I asked for, because I somehow dislike the tone of
some responses here.

--
Jonathan.

Post a reply to this message

JRG <jrg### [at] hotmailcom> wrote in message news:3c267180@news.povray.org...
> Aw, come on it was just an example.
> Lightflow has got it for example:
>
> string "visibility", int depth
> Specify the tracing depth at which the objects made from this material
start
> to be visible.
> This is useful to make objects appear only inside reflections, for example
> to create rich environments though mantaining a black background.
> The default value is 0.
>
> To me it does make sense. Look at the Lightflow's cornell box posted to
> p.b-i. You wouldn't say it's physically impossible, but the camera is just
> two units outside the actual box. And I won't mention how many times I
would
> have wanted to render a nice radiosity scene with a black background
(using
> a no_image sky_sphere).
>
> Really, I thought about this as a more general and simple way to resolve
> many different problems. One single keyword which would include so many
> different effects. I don't need it just now for an actual scene.
>
> What I'd need is truly the _no_image_ objects to participate to radiosity
> calculations. Of course this may be an undesirable effect in some
> circumstances. Thus I think a no_radiosity flag would be more logical (as
> long as no_image doesn't directly imply no_radiosity).
>
> But you can forget what I asked for, because I somehow dislike the tone of
> some responses here.
>
> --
> Jonathan.
>
My  $0.02: It is a good idea, I could use it in a lot of scenes. the tones
of
 some responses were a little off, but thats life.

Gary

Post a reply to this message