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

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

I think the most flexible way would be to have some kind of 
"interaction_group" that covers lights (including highlights), 
reflection, refraction, etc...basically "this object only reflects this 
group of objects, and only has highlights from this group of lights". I 
think radiosity would still have to be a separate flag.
However, this would probably be too complex to use...it would most 
likely be simpler to use a shader of some sort.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

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

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

I somehow do not believe the original Cornell box was designed this way...

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

I just think you are taking the wrong approach to the problem with your
scene.  Instead of thinking for hours how POV-Ry could be changed, try to go
with what you have and you will get amazing results and maybe find a
creative way without someone else adding a feature to POV-Ray for you.

Somehow what you suggest is like suggesting to add drills to cars so you can
drill for oil when you run out of fuel.  Sure you could do it, but it might
not be the most practical solution :-)

    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

Kari Kivisalo wrote:
> 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.

 I've found a half-workaround for this problem, if you are not going to use 
media interacting radiosity. You can put a very intense emission media 
inside your ambient object, with a clear pigment, and of course mantain 
media off on the radiosity block. This gives a nice solid luminous object 
for reflections/refraction withouth emitting any light. It works nicely for 
me, because I will surely never use "media on" with radiosity.

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

JRG wrote:
 
> > 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).

Ok, my fault.

> 
> >    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.
> 
> > BUT:
> >  - I do not see the interest of it (as exposed in your initial request)
> 
> YHO
Exactly, Even the no_* are still rarely used/needed.
And the scene you described did not convince me for the suggested solution.

> 
> >  - I'm personaly against it
> 
> Morally?
Sort of. 
Your suggestion needs to modify the very heart of the engine.
patches from safe/simple to unsafe/complex are in order (IMNSHO):
 - new pattern
 - new warp
 - new object
 - alternative behaviour/adding flags

So, when you asked directly for the most dangerous, it triggered a red flag ;-)

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

Well, I would said that you jumped to the conclusion :-)
Moreover, the problem of the "spy-mirror" (one side see the other, whereas
the other see only itself) was recently discussed (even if I cannot here find the 
reference to it) and is very similar to your exposed problem.
You may have wanted to discuss your problem in newsgroups, before requesting
your solution... there is usually more than one way to solve a problem.

BTW, have a look in p.b.i, I have a proposition for your problem.
It's bigger than the needed code change for your solution, because it needs a
new object, but I consider it to be safer because it won't touch any shared code.
-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Somehow what you suggest is like suggesting to add drills to cars so you
can
> drill for oil when you run out of fuel.  Sure you could do it, but it might
> not be the most practical solution :-)

*lol*
sigged ...


--
"Somehow what you suggest is like suggesting to add drills \ jan### [at] lzernet
to cars so you can drill for oil when you run out of fuel.  \
Sure you could do it, but it might not be the most practical >          Jan
solution." [Thorsten Froehlich in p.u.p]                    /        Walzer

Post a reply to this message