Warp wrote:

> That's a good idea, but I wonder if the 'photons' block should
> be a part of the 'material' block...
> 
>   How would this look like?
> 
> material
> { texture { ... }
>   interior { ... }
>   photons { ... }
> }
> 
>   OTOH this would introduce the problem of a material which always is
> a target for photons even when you don't want to. There should perhaps
> be a way of turning it off for specific objects...

An overriding "target off" keyword would solve that.

Severi

Post a reply to this message

Warp wrote:
> 
>   That's a good idea, but I wonder if the 'photons' block should
> be a part of the 'material' block...
> 
>   How would this look like?
> 
> material
> { texture { ... }
>   interior { ... }
>   photons { ... }
> }

I don't think this would be a good idea, the way it is right now people 
recognize that photons are shot at objects and not at materials.  In 
fact photon shooting does not care about the material at all.

For example you could get the idea that assigning a material like:

material {
   texture {
     boxed
     texture_map {
       [0.5 Tex_Diffuse]
       [0.5 Tex_Reflective]
     }
   }
   photons { target reflection on }
}

to the whole scene could be reasonable.  This will lead to serious 
trouble though when your scene contains large or infinite objects.

Christoph

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

Post a reply to this message

Christoph Hormann wrote:

> Warp wrote:
> 
>>
>>   That's a good idea, but I wonder if the 'photons' block should
>> be a part of the 'material' block...
 >
> I don't think this would be a good idea, the way it is right now people 
> recognize that photons are shot at objects and not at materials.  In 
> fact photon shooting does not care about the material at all.
> 
> For example you could get the idea that assigning a material like:
> 
> material {
>   texture {
>     boxed
>     texture_map {
>       [0.5 Tex_Diffuse]
>       [0.5 Tex_Reflective]
>     }
>   }
>   photons { target reflection on }
> }
> 
> to the whole scene could be reasonable.  This will lead to serious 
> trouble though when your scene contains large or infinite objects.

Of course, but I don't see the difference. You'll get equally big 
troubles if you assign target keyword straight to an infinite object or 
if you assign photon enabled material to the same object - no 
difference. I don't think making materials capable of being targets 
would make things any worse in that respect - you allways have to take 
care of what you are doing.

The point is just to make it easier to link certain things together with 
more freedom than now. Usually if someone has glass objects in a scene 
it is most likely he wants them all to show photon caustics. Material 
specific definition would be a nice way to do it. And, for example, if 
there was an infinite glass plane, specifying (say) "target off" would 
override the material photon definition.

Severi S.

Post a reply to this message

Severi Salminen wrote:
> [...]
> 
> Of course, but I don't see the difference. You'll get equally big 
> troubles if you assign target keyword straight to an infinite object or 
> if you assign photon enabled material to the same object - no 
> difference. I don't think making materials capable of being targets 
> would make things any worse in that respect

But materials can't be targets, only objects can.  The only way you can 
implement this is to make every object somehow 'inherit' the photon 
settings of its material.  But this would not be obvious to the user so 
it will just cause confusion in most cases.

> The point is just to make it easier to link certain things together with 
> more freedom than now. Usually if someone has glass objects in a scene 
> it is most likely he wants them all to show photon caustics. 

Most likely not.  For efficiency you will only use photons on those 
objects where the caustics are visible in the scene.  Glass objects out 
of direct view that are only visible as reflections in other shapes for 
example will probably not use photons.

Christoph

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

Post a reply to this message

Christoph Hormann wrote:

> Severi Salminen wrote:
> 
>> [...]
> But materials can't be targets, only objects can.  The only way you can 
> implement this is to make every object somehow 'inherit' the photon 
> settings of its material.  But this would not be obvious to the user so 
> it will just cause confusion in most cases.

Materials can't be targets, true, but materials are allways assigned to 
certain objects, so yes, objects should inherit the photon settings. I 
thought this is obvious as there simply can't be an occurence of 
material without an object it is assigned to. And the whole point was to 
let material specify if an object needs photons. That is logical - same 
way as you might assign CAUSTICS keyword to certain material.

>> The point is just to make it easier to link certain things together 
>> with more freedom than now. Usually if someone has glass objects in a 
>> scene it is most likely he wants them all to show photon caustics. 
> 
> Most likely not.  For efficiency you will only use photons on those 
> objects where the caustics are visible in the scene.  Glass objects out 
> of direct view that are only visible as reflections in other shapes for 
> example will probably not use photons.

Why not? If the object itself is visible via reflection, then the 
caustics might also be. And if the object is not visible at all, then, 
why it exists at all? And actually this doesn't even matter: there are 
scenes that would benefit from material specific photons and there are 
scenes that would not. I don't see why implementing it would make things 
worse as you don't _have to_ use it allways - except that it needs to be 
implemented ;) It would simply make POV-SDL more versatile. But maybe 
POV-SDL will someday evolve to a form where this can be done easily.

PS. When the computers get faster, the caustics keyword will definitely 
be replaced by photon mapping (or some other technique) and it can be 
used in all objects. "Efficiency" is a very subjective word...

SeveriS

Post a reply to this message

SNIP
> I don't see why implementing it would make things
> worse as you don't _have to_ use it allways - except that it needs to be
> implemented ;) It would simply make POV-SDL more versatile. But maybe
> POV-SDL will someday evolve to a form where this can be done easily.
SNIP

Just to comment on this lone part of the discussion: I don't think that
making assumptions for the User is versatile. It often leads to places where
the User has to guess/assume what the Programm is assuming and
counter-effect that. POV-Ray, to me, was always about scripting what you
need and want. If I want a special effect, like photons, I have to put it
there, especially since photons can cause a load of data which would slow
down rendering even if not in sight. I was always glad that POV-Ray "ships"
with the most basic default settings, and assumes nothing, so that I know
*exactly* what's happening, when I view the code.

Oh, and "efficiency" has nothing to do with speed of PC's. If you don't need
calculations for effect, don't do them. That's efficiency: save where
possible.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:

> SNIP
> 
>>I don't see why implementing it would make things
>>worse as you don't _have to_ use it allways - except that it needs to be
>>implemented ;) It would simply make POV-SDL more versatile. But maybe
>>POV-SDL will someday evolve to a form where this can be done easily.
> 
> SNIP
> 
> Just to comment on this lone part of the discussion: I don't think that
> making assumptions for the User is versatile. It often leads to places where
> the User has to guess/assume what the Programm is assuming and
> counter-effect that. POV-Ray, to me, was always about scripting what you
> need and want. If I want a special effect, like photons, I have to put it
> there, especially since photons can cause a load of data which would slow
> down rendering even if not in sight. I was always glad that POV-Ray "ships"
> with the most basic default settings, and assumes nothing, so that I know
> *exactly* what's happening, when I view the code.

You are totally correct and I agree that the user should allways have 
the control. BUT:

Basically photon mapping is an effect in the same way as caustics, 
specular reflection, reflection etc. It uses different method and might 
cause considerable slowdown even when not visible, but it is still an 
effect and it can replace caustics, for example. And if caustics can be 
included in material definition, then why not photons as well? I simply 
don't understand why photons should be treated differently than the rest 
of the "effects".

And: if you assign photons to a material, why wouldn't you know what is 
happening? Why would you need to assume anything? If you assign that 
material to an object, that object will be used as photon target. Simple.

There are worse examples of guessing/assuming: using radiosity you are 
making every object emit light unless you alter the default ambient 
value. So not all default values are intuitive :)

> Oh, and "efficiency" has nothing to do with speed of PC's. If you don't need
> calculations for effect, don't do them. That's efficiency: save where
> possible.

Yes, but photons, for example might contribute to the visible part of 
the scene even when the object itself is not visible. So efficiency 
would be to test if the object affects to visible part and save the 
calculations if not. I have to admit I don't know exactly how photon 
mapping in POV-Ray works so it might be doing this kind of checking 
allready.

PS. I'm not trying to complain, I just proposed a feature that might be 
of some use to some people. To me, atleast ;-)

Severi S.

Post a reply to this message

>>
>> But materials can't be targets, only objects can.  The only way you 
>> can implement this is to make every object somehow 'inherit' the 
>> photon settings of its material.  But this would not be obvious to the 
>> user so it will just cause confusion in most cases.
> 
> 
> Materials can't be targets, true, but materials are allways assigned to 
> certain objects, so yes, objects should inherit the photon settings. I 
> thought this is obvious as there simply can't be an occurence of 
> material without an object it is assigned to. And the whole point was to 
> let material specify if an object needs photons. That is logical - same 
> way as you might assign CAUSTICS keyword to certain material.
> 
Just my thoughts on this. I think inheritance in this case is
a bad idea, especially if you combine it with 'target off'.
The properties of an object can then change with
the order in which the parts are added together.
Photons as a material property makes sense, but that would
probably mean a large rewrite of the code (if even possible).
Also it may break existing code.

    Andrel

Post a reply to this message

> Just my thoughts on this. I think inheritance in this case is
> a bad idea, especially if you combine it with 'target off'.
> The properties of an object can then change with
> the order in which the parts are added together.

I didn't quite follow you. Can you give an example?

> Photons as a material property makes sense, but that would
> probably mean a large rewrite of the code (if even possible).
> Also it may break existing code.

You can be 99.99% sure that it will never be implemented in present POV-Ray.
I believe it will be rewritten sooner or later anyway.

Severi

Post a reply to this message

Severi Salminen wrote:

>>Just my thoughts on this. I think inheritance in this case is
>>a bad idea, especially if you combine it with 'target off'.
>>The properties of an object can then change with
>>the order in which the parts are added together.
> 
> 
> I didn't quite follow you. Can you give an example?
Well, if you have an object which is partly glass
and partly some opaque material and you add 'target off'
to the latter part. Will the resulting object collect photons
(because of the glass part that switches it on, and
it is inherited by the total object) or not because
of the 'target of' in the other part. Will always the
first declaration take precedence or the last (or
even a middle one).

> 
>>Photons as a material property makes sense, but that would
>>probably mean a large rewrite of the code (if even possible).
>>Also it may break existing code.
> 
> 
> You can be 99.99% sure that it will never be implemented in present POV-Ray.
> I believe it will be rewritten sooner or later anyway.
> 
may I add 0.01% percent to that? Without looking into the
code I do not want to bet if it ever will. As I said, I
feel that a material property may make more sense but
it would require a exhaustive search through and deep into
all the  objects to see whether there is any photon active
material in it. If that is feasible depends on the
datastructures (I guess).

    Andrel

Post a reply to this message