Hi!

Is there a way to assign a (photon) TARGET keyword to a certain 
material? I'd like to make everything that is made of glass a photon 
target and now I have to specify TARGET individually to every glass 
object. If it is not possible, it would certainly be a most welcome 
feature - if feature wishes for the next relase can be made :-)

Severi S.

Post a reply to this message

sev### [at] NOT_THISsibafi news:402818a4$1@news.povray.org

> Is there a way to assign a (photon) TARGET keyword to a certain 
> material? I'd like to make everything that is made of glass a photon 
> target and now I have to specify TARGET individually to every glass 
> object. If it is not possible, it would certainly be a most welcome 
> feature - if feature wishes for the next relase can be made :-)

Maybe use macro instead

#macro matGlass()
  material { _matGlass }
  photons { ... }
#end

object { xxx matGlass() }


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj <spa### [at] raf256com> wrote:
> #macro matGlass()
>   material { _matGlass }
>   photons { ... }
> #end

> object { xxx matGlass() }

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

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Rafal 'Raf256' Maj wrote:

>>Is there a way to assign a (photon) TARGET keyword to a certain 
>>material? I'd like to make everything that is made of glass a photon 
>>target and now I have to specify TARGET individually to every glass 
>>object. If it is not possible, it would certainly be a most welcome 
>>feature - if feature wishes for the next relase can be made :-)
> 
> 
> Maybe use macro instead
> 
> #macro matGlass()
>   material { _matGlass }
>   photons { ... }
> #end
> 
> object { xxx matGlass() }

That is indeed a good suggestion, but it is hard to implement if you 
want to change an allready existing material - lots of parentheses to add...

Ok, you can use the Replace tool in your favourite text editor, but 
still... Adding photons to material description would be the easiest and 
the most intuitive way.

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