 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
http://www.studenter.hb.se/~arch
E-mail: sa9### [at] ida utbhbse
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
|
|
| |
| |
|
|
|
|
| |
|
|
