-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- From p.programming...

Daniel Dawson wrote:
> You pick up and read article <4344f1d3$1@news.povray.org>, written by 
> Le Forgeron  <jgr### [at] freefr>. It says:
> 
>>This is an old idea. Already implemented by someone for povray.
>>Instead of a finish, it is a pigment, IIRC. (finish have no color)
>>You might search for "portal", i think.
> 
> 
> I found this out. (Not knowing which group is best, I made a slight mess
> between povray.programming and povray.unofficial.patches. But I've been told
> that p.u.p is the appropriate place, so I'll post there from now on.) Someone
> mentioned the portal patch. I was able to find a post on p.u.p about it, but
> that's it; all the links I could find are broken. If anyone knows what happened
> to the patch, you might let me know. Thanks.
> 
> As to pigment vs. finish: (specular) reflection is a finish property, right?
> Teleportation works somewhat like reflection, which is why I think it's a
> finish property.

I believe it is nearly an issue of finding out which code provide the
rays which are summed to provide the answer to the eternal
question:"what is the actual color of the incoming ray".

finishes are pretty much hard-coded in a formula using ambient, diffuse
and other linear coefficient. Same goes for the reflection and
refraction code, nearly no possible plugin as far as I know.
On the other hand, there is a great tradition of various patterns
evaluation. (moreover, you can combine patterns in layers and other,
whereas it is not possible to do so with finish so far).
That's why I nearly thing of it like a pattern.
What about combining your idea with a glassy finish to make a 3D TV,
or a grainy finish ? or whatever.

> 
> 
>>most of the time, a two step rendering of the splitted scene with an
>>image mapping of the first in the second is enough to simulate your
>>idea, at the cost of a finite definition but with the advantage of
>>reduced memory usage and less objects.
> 
> 
> You're the second person to suggest this, but it's exactly what I *don't* want,
> due to the flatness of the image map. The ray emitted from the remote surface
> must be at the same angle to normal as the incident ray on the portal, or must
> obey Snell's law if portal refraction is allowed.
> 

I think you might want to reconsider your idea before coding: it would
work fine in reality where only forward ray exist.
Now, please consider that most raytracing is done by going in the
reverse direction (excepted for photons, which go from light source to
object...), which will trigger a potential issue when calculating shadow
(without photons): if you have a light source in the teleported zone, it
won't work as you might expect on the teleporting zone.


- --
Eifersucht ist die Leidenschaft, die mit Eifer sucht, was Leiden schafft.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDRSVus/YJ43cSjHIRAuU5AJ4ggdXgawC/7VqPcV9Iwv/2sRSPwQCghrVl
omIyfpz/3uamrg1nLoU3PS0=
=k30R
-----END PGP SIGNATURE-----

Post a reply to this message