I did it before and I'll do it again: suggest a new feature which will probably
be seen as silly and redundant. Anyway, I think it would be really "cool" if you
had the possibility to define by which lightsources an object is lit. So, for
instance, in a scene you have four light_sources lighting the scene, but one
"ghostly" object is only lit by one. This would mean you'd have to name the
lightsource (optional) and add an (optional) statement to an object like
"lit_by" or something.
I realize there are ways (especially with postprocessing) to do this already,
but I haven't found a convincing way yet. At this moment I could use such an
option, but seeing that I don't know how to get this effect I'll have to drop
it. Unless someone enlightens me... (tough luck ;-) )

Regards,

Remco

Post a reply to this message

Remco de Korte wrote:
> 
> I did it before and I'll do it again: suggest a new feature which will probably
> be seen as silly and redundant. Anyway, I think it would be really "cool" if you
> had the possibility to define by which lightsources an object is lit...

Not a silly feature.  RenderMan spec requires it.  3DS Max has it.

Xander

Post a reply to this message

Yeah, interesting.

light_source { ... }

object // Lit by the global light source
{ MyObject1
}

object // Lit by the global light source and an own light source
{ MyObject2
  lit_by { light_source { ... } }
}

object // Lit only by its own light source
{ MyObject3
  no_lights
  lit_by { light_source { ... } }
}

object // Lit by nothing
{ MyObject4
  no_lights
}

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

I was about to say it was supported by MAX.  In fact I see this feature as
totally invaluable now.  I don't think I could make a scene without using
it...

It's really useful for adding little highlights on certain objects or just
brightening a certain area.  Especially when used with spotlights.

I think it would be great if this was implimented into POV-Ray.

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind

Alexander Enzmann wrote in message <375CFECF.27615AF1@mitre.org>...
>
>
>Remco de Korte wrote:
>>
>> I did it before and I'll do it again: suggest a new feature which will
probably
>> be seen as silly and redundant. Anyway, I think it would be really "cool"
if you
>> had the possibility to define by which lightsources an object is lit...
>
>Not a silly feature.  RenderMan spec requires it.  3DS Max has it.
>
>Xander

Post a reply to this message

On Tue, 08 Jun 1999 13:29:22 +0200, Remco de Korte
<rem### [at] xs4allnl> wrote:

>I did it before and I'll do it again: suggest a new feature which will probably
>be seen as silly and redundant. Anyway, I think it would be really "cool" if you
>had the possibility to define by which lightsources an object is lit. So, for
>instance, in a scene you have four light_sources lighting the scene, but one
>"ghostly" object is only lit by one. This would mean you'd have to name the
>lightsource (optional) and add an (optional) statement to an object like
>"lit_by" or something.
>I realize there are ways (especially with postprocessing) to do this already,
>but I haven't found a convincing way yet. At this moment I could use such an
>option, but seeing that I don't know how to get this effect I'll have to drop
>it. Unless someone enlightens me... (tough luck ;-) )
>
>Regards,
>
>Remco

This would be really useful and there have been many occasions that I
wished there were such features in POV.
Implementation, anyone? For free, going once... for free, going
twice... sold!... for free :)


Peter Popov
ICQ: 15002700

Post a reply to this message

Doesn't sound "silly" to me either. Do you know about using negative color lights btw?
Not nearly the same thing but you can counter the positive color lights with one. It's
just that this would effect the whole unlit area, not a object alone. Closest you
could
get to your "feature" would be to point a narrow spotlight with color rgb -1 for
example
at the desired object from the exact same location as the positive lightsource.


Remco de Korte wrote:
> 
> I did it before and I'll do it again: suggest a new feature which will probably
> be seen as silly and redundant. Anyway, I think it would be really "cool" if you
> had the possibility to define by which lightsources an object is lit. So, for
> instance, in a scene you have four light_sources lighting the scene, but one
> "ghostly" object is only lit by one. This would mean you'd have to name the
> lightsource (optional) and add an (optional) statement to an object like
> "lit_by" or something.
> I realize there are ways (especially with postprocessing) to do this already,
> but I haven't found a convincing way yet. At this moment I could use such an
> option, but seeing that I don't know how to get this effect I'll have to drop
> it. Unless someone enlightens me... (tough luck ;-) )
> 
> Regards,
> 
> Remco

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

This thread, the recent thread for a new pattern by Peter Popov, another
new feature suggested in the programming group, plus the large list a while
back just reinforces my feeling that a new group should be formed expressly
for the purpose of discussing new features or modifications to existing
features. There is no way the Pov team could be expected to comb through
all of the messages here when it comes time to start looking for new ideas
for the program and there are suggestions made that may help them decide
which way to best implement something they are already thinking about adding.
  I can't help thinking that many of these wonderful are never added to
the Pov teams list of possible things to do simply because they never hear
about them. A single repository for the digesting of these ideas would
certainly help in this regard.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Tue, 08 Jun 1999 13:29:22 +0200, Remco de Korte
<rem### [at] xs4allnl> wrote:

>Anyway, I think it would be really "cool" if you
>had the possibility to define by which lightsources an object is lit. So, for
>instance, in a scene you have four light_sources lighting the scene, but one
>"ghostly" object is only lit by one. This would mean you'd have to name the
>lightsource (optional) and add an (optional) statement to an object like
>"lit_by" or something.

See the "light groups" feature (by Mathew Corey Brown) in the upcoming
version of the Superpatch

Jerry Anning
clem "at" dhol "dot" com

Post a reply to this message

On Tue, 08 Jun 1999 13:56:45 GMT, Peter Popov wrote:
>This would be really useful and there have been many occasions that I
>wished there were such features in POV.
>Implementation, anyone? For free, going once... for free, going
>twice... sold!... for free :)

Already implemented in the next superpatch, thanks to Matthew Corey
Brown (xenoarch).  But don't ask me when you can have it. :)

Post a reply to this message

Ron Parker wrote:
> 
> Already implemented in the next superpatch, thanks to Matthew Corey
> Brown (xenoarch).  But don't ask me when you can have it. :)

When can I have it ?

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Tue, 08 Jun 1999 08:39:32 -0700, Ken wrote:
>Ron Parker wrote:
>> 
>> Already implemented in the next superpatch, thanks to Matthew Corey
>> Brown (xenoarch).  But don't ask me when you can have it. :)
>
>When can I have it ?

Relax, Ken, you're gonna get it.  Boy are you gonna get it.

Post a reply to this message

Ron Parker wrote in message <375d5379@news.povray.org>...
>On Tue, 08 Jun 1999 08:39:32 -0700, Ken wrote:
>>Ron Parker wrote:
>>>
>>> Already implemented in the next superpatch, thanks to Matthew Corey
>>> Brown (xenoarch).  But don't ask me when you can have it. :)
>>
>>When can I have it ?
>
>Relax, Ken, you're gonna get it.  Boy are you gonna get it.

So this'll be included the upcoming version of the Superpatch?
Cool :)  Any ideas how many more weekends it might take though?

(Yes.. I ~know~ it sounds like I'm being a right pain in the <fill in>,
particularly that I'm sure Ron has plenty of more important/pressing things
to do than work on a ~freeware~ patch, but it's jjuusssssttt that I'm keen
to use his excellent work :)  I understand how time consuming such a
thing can be though, being a programmer myself.  Sorry to Ron if the above
sounded rude or anything though - it was not intended.)


/\/\/\//

Post a reply to this message

>a new group should be formed expressly
>for the purpose of discussing new features or modifications to existing
>features. There is no way the Pov team could be expected to comb through
>all of the messages here 

povray.suggestion.box


-- 
...coffee?...yes please! extra sugar,extra cream...Thank you.

Post a reply to this message

I seem to remember that 3D Studio (the predecessor to MAX) implemented
this by way of an exclusion list on the light source. This would be
useful, however, it would also be nice to see your idea of a lit_by list
to allow more flexibility.

Just my $0.02

-- 
Chris Maryan
mailto:cma### [at] geocitiescom
***
Will work for cash.
***
Email me if you are interested in donating
to the Chris Maryan needs money fund.
We will also accept donations to the Chris
needs a Pentium III or SGI workstation 
fund and the Chris needs a car fund.

Post a reply to this message

The group povray.unofficial.patches would probably be a good place for such
discussions, IMHO.

-Nathan

Ken wrote:
> 
>   This thread, the recent thread for a new pattern by Peter Popov, another
> new feature suggested in the programming group, plus the large list a while
> back just reinforces my feeling that a new group should be formed expressly
> for the purpose of discussing new features or modifications to existing
> features. There is no way the Pov team could be expected to comb through
...

Post a reply to this message

Nathan Kopp wrote:
> 
> The group povray.unofficial.patches would probably be a good place for such
> discussions, IMHO.
> 
> -Nathan

  I won't argue the logic of what you say but will point out that a group
titled "Feature Requests" would be blatantly obvious to anyone thinking of
posting one while the unofficial patches group seems to imply other things
altogether.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ron Parker wrote:
> 
> Already implemented in the next superpatch, thanks to Matthew Corey
> Brown (xenoarch).  But don't ask me when you can have it. :)

Well, this is going to make things quite interesting when I merge photon
mapping with the SuperPatch, won't it.  But I'm still waiting because it
looks like changes are still being made to the SuperPatch (e.g. recent
bug found in parametric equation parser).

-Nathan

Post a reply to this message

On Wed, 09 Jun 1999 01:01:48 -0400, Nathan Kopp <Nat### [at] Koppcom>
wrote:

>
>
>Ron Parker wrote:
>> 
>> Already implemented in the next superpatch, thanks to Matthew Corey
>> Brown (xenoarch).  But don't ask me when you can have it. :)
>
>Well, this is going to make things quite interesting when I merge photon
>mapping with the SuperPatch, won't it.  But I'm still waiting because it
>looks like changes are still being made to the SuperPatch (e.g. recent
>bug found in parametric equation parser).

I would guess it would.  That code is in the source you have, though,
so take a few minutes to look at it.  One of the .txt files describes
it in some detail.

Post a reply to this message

Yes that's right.  The basic idea that 3D Studio had (and this has been
extended into MAX) is the following.

Each light has a name and so do all objects.  In the case of POV-Ray these
could just be optional keywords as was suggested (for the lights an ID
perhaps and the lit_by statement in the objects).

Then lights can either be excluded or included for each object (or vice
versa with the objects to the lights).  You also have the option for
lighting and/or casting shadows/receiving shadows.

There is also another option that could be implemented into the lights and
that is an option keyword set like the following:

affect_diffuse_only
affect_specular_only

So the light can be switched to affecting the diffuse or speculars of a
surface individually (very useful for ambient direction lighting).

Of course we'll wait and see what the new Superpatch has to offer first I
guess :)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
For a totally different experience, visit my Chroma Key Website:
Colorblind - http://listen.to/colorblind

Chris Maryan wrote in message <375D7650.2B68DE11@geocities.com>...
>I seem to remember that 3D Studio (the predecessor to MAX) implemented
>this by way of an exclusion list on the light source. This would be
>useful, however, it would also be nice to see your idea of a lit_by list
>to allow more flexibility.
>
>Just my $0.02
>
>--
>Chris Maryan
>mailto:cma### [at] geocitiescom
>***
>Will work for cash.
>***
>Email me if you are interested in donating
>to the Chris Maryan needs money fund.
>We will also accept donations to the Chris
>needs a Pentium III or SGI workstation
>fund and the Chris needs a car fund.

Post a reply to this message

On Tue, 08 Jun 1999 21:46:47 -0700, Ken <tyl### [at] pacbellnet> wrote:

>  I won't argue the logic of what you say but will point out that a group
>titled "Feature Requests" would be blatantly obvious to anyone thinking of
>posting one while the unofficial patches group seems to imply other things
>altogether.
>

  Point well made, Ken. Consider, however, that a group so named might
imply that the POV-Team is poised, ready, willing, and able to
implement a whole bunch of new and innovative ideas while the reality
of life is that they would like to hear of feature requests bundled
with the patch source and, ideally, a working unofficial executable.
JM2¢W (Just My Two Cents Worth)...

-- 
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------

Post a reply to this message

Point well made, Alan.
I personally am not for cluttering the server with many highly specialised
groups, especially if a suitable group already exists. I think
.unofficial-patches is such a suitable group, with .programming covering the
real-world application of the suggested features. One must simply get into
the habit of posting to the right place.

Margus

PS. "povray.dream.on" would probably probably best describe such a group :)

Alan Kong wrote in message <375f46de.7509647@news.povray.org>...
>
>  Point well made, Ken. Consider, however, that a group so named might
>imply that the POV-Team is poised, ready, willing, and able to
>implement a whole bunch of new and innovative ideas while the reality
>of life is that they would like to hear of feature requests bundled
>with the patch source and, ideally, a working unofficial executable.
>JM2¢W (Just My Two Cents Worth)...
>
>--
>Alan
>--------------------------------------------------------------------
>http://www.povray.org - Home of the Persistence of Vision Ray Tracer
>news.povray.org - where POV-Ray enthusiasts around the world can get
>together to exchange ideas, information, and experiences with others
>--------------------------------------------------------------------

Post a reply to this message

Ken wrote:

> Ron Parker wrote:
> >
> > Already implemented in the next superpatch, thanks to Matthew Corey
> > Brown (xenoarch).  But don't ask me when you can have it. :)
>
> When can I have it ?

*lol*  : D

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science
Högskolan i Borås, Sweden

http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

Nathan Kopp wrote:

> Well, this is going to make things quite interesting when I merge photon
> mapping with the SuperPatch, won't it.  But I'm still waiting because it
> looks like changes are still being made to the SuperPatch (e.g. recent
> bug found in parametric equation parser).
> 
> -Nathan

  You keep mentioning that you are going to merge the photon mapping
function with Super Patch. Question is if you are merging it rather
than Ron does this imply that there will be two versions of the Super
Patch or once done you will pass it back to Ron to maintain ? Is this
feature addition delaying the much anticipated release of the Super
Patch that Ron keeps promising will be available before the end of
this millennium ?

  And Lance not one word from you about when the end of the millennium
actually takes place because I already know your opinion on the subject.
Give it a rest.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Wed, 9 Jun 1999 15:52:23 +0300, "Margus Ramst" <mar### [at] peakeduee>
wrote:

>I personally am not for cluttering the server with many highly specialised
>groups, especially if a suitable group already exists. I think
>.unofficial-patches is such a suitable group, with .programming covering the
>real-world application of the suggested features. One must simply get into
>the habit of posting to the right place.

  Hi, Margus. I also saw Nathan's post regarding
povray.unofficial.patches but I can't honestly say where I think
feature request ideas and discussion should go. I know this is exactly
what Ken is talking about. Maybe povray.general is not such a bad
place until the discussion actually gets to the patch stage. There...
I've added more confusion to the mix :)

-- 
Alan
--------------------------------------------------------------------
http://www.povray.org - Home of the Persistence of Vision Ray Tracer
news.povray.org - where POV-Ray enthusiasts around the world can get
together to exchange ideas, information, and experiences with others
--------------------------------------------------------------------

Post a reply to this message

On Wed, 09 Jun 1999 08:35:01 -0700, Ken wrote:
>Nathan Kopp wrote:
>
>> Well, this is going to make things quite interesting when I merge photon
>> mapping with the SuperPatch, won't it.  But I'm still waiting because it
>> looks like changes are still being made to the SuperPatch (e.g. recent
>> bug found in parametric equation parser).
>> 
>> -Nathan
>
>  You keep mentioning that you are going to merge the photon mapping
>function with Super Patch. Question is if you are merging it rather
>than Ron does this imply that there will be two versions of the Super
>Patch or once done you will pass it back to Ron to maintain ? Is this
>feature addition delaying the much anticipated release of the Super
>Patch that Ron keeps promising will be available before the end of
>this millennium ?

No, what's delaying the next release is I'm too lazy to do the documentation,
which is required for a proper unofficial version.  I'm getting there, though.
By the way, if I have till the end of the millennium to get it finished, I'll
have plenty of time to add all kinds of new stuff.  A year and a half... 
that's a lot of time...

I don't know what Nathan's plans are wrt his merging photon mapping with the
superpatch.  I have a copy of the code he started with so I can merge his 
changes with mine whenever he's finished.  I'd obviously prefer that to two
divergent versions - that would defeat the whole purpose of the thing, after
all.

Post a reply to this message

Ron Parker wrote:
> 
> I don't know what Nathan's plans are wrt his merging photon mapping with the
> superpatch.  I have a copy of the code he started with so I can merge his
> changes with mine whenever he's finished.  I'd obviously prefer that to two
> divergent versions - that would defeat the whole purpose of the thing, after
> all.

That sounds good to me.  I'll get to work, then, and give you my results when
I'm done.  I've got the photon stuff pretty well set now, so I don't forsee
any major changes in the future (well, except the addition of diffuse
lighting and media interaction, but I need to learn more about the existing
POV code before I can dive into those areas).

-Nathan

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote in message
news:375CFE92.F4F027F2@xs4all.nl...
> I did it before and I'll do it again: suggest a new feature which will
probably
> be seen as silly and redundant. Anyway, I think it would be really "cool"
if you
> had the possibility to define by which lightsources an object is lit. So,
for
> instance, in a scene you have four light_sources lighting the scene, but
one
> "ghostly" object is only lit by one. This would mean you'd have to name
the
> lightsource (optional) and add an (optional) statement to an object like
> "lit_by" or something.
> I realize there are ways (especially with postprocessing) to do this
already,
> but I haven't found a convincing way yet. At this moment I could use such
an
> option, but seeing that I don't know how to get this effect I'll have to
drop
> it. Unless someone enlightens me... (tough luck ;-) )

    Here's how, for point light sources anyway.

    (1) Create a very small copy [say exactly 1/1000 scale] of your object.
If necessary change the texture to make it opaque and remove any no_shadows.

    (2) Translate it 999/1000 of the way towards the light-source that you
would like to block.

    You can do both of these at once, if the light source is at <X,Y,Z>, as
follows:

    object{WhereTheSunDontShine}
    object{WhereTheSunDontShine
                    translate<-X,-Y,-Z> /*light source to origin*/
                    scale 0.001         /*tiny & close to light */
                    translate<X,Y,Z>}    /*replace coordinates   */

    It will block exactly the cone of rays that would hit the object.

The same trick without the first object will cause a shadow to be cast
without anybody to cast it.

    -Robert Dawson

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote in message
news:375CFE92.F4F027F2@xs4all.nl...
> I did it before and I'll do it again: suggest a new feature which will
probably
> be seen as silly and redundant. Anyway, I think it would be really "cool"
if you
> had the possibility to define by which lightsources an object is lit.


Further to my last posting: try this.


torus{2,0.4 translate<2,2,0> pigment{color White} no_shadow}
torus{2,0.4 translate<-3,2,0> translate<-1,-5,1> scale 0.01 translate
<1,5,-1> sturm}


box{-0.5,0.5 translate<-3,2,0> pigment{color White} no_shadow}
box{-0.5,0.5 translate<2,2,0> translate<-1,-5,1> scale 0.01 translate
<1,5,-1> }


box{<-4,-2,5>,<3,8,6> pigment {color White}}

sphere{<0,0,-5>,1 translate<2,-15,1> scale 0.01 translate <-2,15,-1>}

 camera{location<-4,5,-15> look_at<0,0,3>}
 light_source{<1,5,-1> color White+Red/2}
 light_source{<-2,15,-1> color rgb<0.7,0.7,1.3>
    spotlight
    radius 25
    falloff 10
    tightness 10
    point_at <0, 0, -4>
}


plane{<0,1,0>,-2 pigment{marble pigment_map{[0.5 color rgb 0.6][0.9 color
rgb 0.9]} turbulence 1.5}}


    -Robert Dawson

Post a reply to this message

On Thu, 10 Jun 1999 13:50:46 -0300, Robert Dawson wrote:
>    (1) Create a very small copy [say exactly 1/1000 scale] of your object.
>If necessary change the texture to make it opaque and remove any no_shadows.
>
>    (2) Translate it 999/1000 of the way towards the light-source that you
>would like to block.

What if my object has something else between it and the light source?  
For example, say I want to make a ripoff of the SW:TPM poster that shows 
Anakin casting Vader's shadow, but I want Anakin illuminated
in blue and the cliff face in red.  Then I'd put an "invisible
Vader with shadow" (see below) and an "Anakin" model at the same place, 
then add two light sources: A blue one that interacts only with Anakin, 
and a red one that interacts only with Vader and the cliff face.

>The same trick without the first object will cause a shadow to be cast
>without anybody to cast it.

It won't always work.  If part of the first object would usually penetrate 
or go behind the surface on which the shadow is being cast, you might get 
the wrong shadow.  Let's say my client makes network security that's 
supposed to be omnipresent but invisible to trusted users, so I'm coming 
up with a fancy animation sequence to get the idea across.  I have a cool 
artifact in the center to represent your network, surrounded by castle 
walls with fancy turrets and battlements.  A huge gold key flies into the 
scene, unlocks the walls, and they dissolve (invisible) while still casting 
a shadow on the central artifact (omnipresent).  The turret that was behind 
the artifact shouldn't cast a shadow on the artifact, right?  It will.

Anyway, there's an easier way to get that effect:

  #declare LightPos=<...>;
  #declare ShadowOnlyObject=...

  light_source { LightPos rgb 1}
  object { ShadowOnlyObject bounded_by {sphere { LightPos .001 }}}

This might not work exactly right if the light source is between the camera
and the object, but you usually wouldn't do that anyway.

Post a reply to this message

Robert Dawson wrote:
> 
> Remco de Korte <rem### [at] xs4allnl> wrote in message
> news:375CFE92.F4F027F2@xs4all.nl...
> > I did it before and I'll do it again: suggest a new feature which will
> probably
> > be seen as silly and redundant. Anyway, I think it would be really "cool"
> if you
> > had the possibility to define by which lightsources an object is lit.
> 
> Further to my last posting: try this.
> 

Thanks!
Would you believe I really understand this?

It's amazing what people here come up with.

Unfortunately, with the scene I'm working on I have multiple lightsources and
one arealight and it is the last I'd like to block for a certain object. 
That shouldn't be a real problem though.

There's one drawback to your suggestion: an object wouldn't be lit be a
lightsource but it would cast a shadow, wouldn't it? What would happen if it is
a shadowless light_source (I tend to use lots of those).

Regards,

Remco

Post a reply to this message

Ron Parker wrote in message <375ecdf8@news.povray.org>...
>By the way, if I have till the end of the millennium to get it finished,
I'll
>have plenty of time to add all kinds of new stuff.  A year and a half...
>that's a lot of time...


No, you have approximately 996.5 years to finish the patch.  According to
the best estimates, the millenium ended in 1996 or so :-)

Mark

Post a reply to this message

OT:  Please note the correct spelling of millennium.

;)

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote
> There's one drawback to your suggestion: an object wouldn't be lit be a
> lightsource but it would cast a shadow, wouldn't it? What would happen if
it is
> a shadowless light_source (I tend to use lots of those).


    *Then* you would need a selective lighting patch. However, if you want
*no* shadows on something, you could make it luminous by using ambient.

    -Robert

Post a reply to this message

Ron Parker <par### [at] fwicom> wrote

> Anyway, there's an easier way to get that effect:
>
>   #declare LightPos=<...>;
>   #declare ShadowOnlyObject=...
>
>   light_source { LightPos rgb 1}
>   object { ShadowOnlyObject bounded_by {sphere { LightPos .001 }}}

    Cool. This doesn't look as if it *ought* to work, because POV-Ray has an
absolute concept of "inside" - but it does. Clearly the shadow test uses ray
intersections to determine whether a "legal" part of the object is blocking
light, so is fooled if the lightsource is inside the bounding object.

    -Robert Dawson

Post a reply to this message

On Fri, 11 Jun 1999 10:30:18 -0300, Robert Dawson wrote:
>
>Ron Parker <par### [at] fwicom> wrote
>
>> Anyway, there's an easier way to get that effect:
>>
>>   #declare LightPos=<...>;
>>   #declare ShadowOnlyObject=...
>>
>>   light_source { LightPos rgb 1}
>>   object { ShadowOnlyObject bounded_by {sphere { LightPos .001 }}}
>
>    Cool. This doesn't look as if it *ought* to work, because POV-Ray has an
>absolute concept of "inside" - but it does. Clearly the shadow test uses ray
>intersections to determine whether a "legal" part of the object is blocking
>light, so is fooled if the lightsource is inside the bounding object.

The reason this works is that POV first checks for an intersection with 
the bounding object before looking for intersections with the real object.
The only rays that intersect the bounding object are shadow rays, so they
are the only rays that are tested against the real object.  Camera rays 
and reflected rays don't hit the bounding object (usually) so POV assumes
that they also don't hit the real object.

You can also use this trick to make a vampire object (no reflection and 
no shadow) by bounding with a small sphere around the camera.

Post a reply to this message

Lance Birch wrote in message <3760cf08@news.povray.org>...
>OT:  Please note the correct spelling of millennium.
>
>;)


As I am from the USA, I can spell millinium however I want :-)

Mark

Post a reply to this message

he he he™

Post a reply to this message

Nieminen Mika wrote:

>   Yeah, interesting.
> 
> light_source { ... }
> 
> object // Lit by the global light source
> { MyObject1
> }
> 
> object // Lit by the global light source and an own light source
> { MyObject2
>   lit_by { light_source { ... } }
> }
[snip]

VRML has a class of lights, DirectionalLights, which are scoped so
as to light all and only the geometry nodes under their own parent,
while all the other lights are global in scope.

I had pushed the "reply" button to say that I thought that this was
an easier syntax than you'd sketched above, but by the time I got
to this sentence, I thought maybe that might be a mistake.  I'm
guessing that nobody's really exercised the hierarchical scene
graph features in POVRay, and that while VRML scenes with 10 levels
of nesting are far from unusual, I've never seen even one that deep
in POVRay.  Putting in something that would motivate people to make
deeply nested scenes could turn out to be a huge opportunity to
generate bug reports.
+-------------------------------+--------------------------------------+
| Rev. Bob "Bob" Crispen        |            "IT FOUND ME!"            |
| cri### [at] hiwaaynet            |      Campus Crusade for Cthulhu      |
+-------------------------------+--------------------------------------+

Post a reply to this message

Got to about 15 levels in one project. Debugging was a veritable pain, and
ultimately failed. No, thanks!
I could post an unindented version just for Ken's enjoyment... Nah.

Margus

Bob Crispen wrote in message <376231DD.494F3821@hiwaay.net>...
>
>I'm
>guessing that nobody's really exercised the hierarchical scene
>graph features in POVRay, and that while VRML scenes with 10 levels
>of nesting are far from unusual, I've never seen even one that deep
>in POVRay.  Putting in something that would motivate people to make
>deeply nested scenes could turn out to be a huge opportunity to
>generate bug reports.

Post a reply to this message

Will the next superpatch support 3.1e?

Post a reply to this message

Steven Jones wrote:
> 
> Will the next superpatch support 3.1e?

It now does. Get the 3.1e version at:

http://www2.fwi.com/~parkerr/superpatch/

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message