Hello, everyone. First of all, I have to say I'm new to POV-Ray development, so
I hope you forgive my boldness in posting my wild and somewhat ambitious idea
here. I realize this is a bit... esoteric? But that's sort of the way I am. :-)
Anyway, I would appreciate thoughts on this. I'm not requesting this as an
official feature; I just want input.

My idea is this: to add a lighting feature to make rays hitting one surface
'teleport' (for lack of a better term) to another surface somewhere else. This
would be a little like reflection and refraction, except for the position
offset. The teleported ray might (?) undergo refraction independent of the
normal (non-teleport) refraction. I think the best way to implement this is as
a finish property.

Why do I want this? Well, basically I just think it would be cool. It would be
perfect for that 'looking glass' effect, for instance, or maybe for things like
crystal balls. My impetus for this whole thing was this idea: Imagine some
space, with whatever geometry it has, and there's some sort of 'portal' that
leads to another space; anyone who goes through it finds apparently
incompatible geometry on the other side. Sorry, this is more like something you
might find in a video game than in the typical POV-Ray image. But I think the
proposed effect might have at least some limited value for the latter in some
cases.

I've already come up with a number of issues that need to be addressed:

1. Most significant: Each point on the receiving (R) surface must be mapped to
   its counterpart on the transmitting (T) surface. How should this mapping be
   accomplished? (Just so there's no confusion: I'm speaking in terms of
   reverse ray tracing.) Perhaps there should be some restrictions on what
   types of objects this works with?
2. Also, rather minor, but what should be the relationship between the normals
   of R and T? If the incident ray is pointing away from R's normal (the usual
   condition, I expect), should the teleported ray be pointed toward or away
   from T's normal? Or put another way, should the ray go from outside to
   inside (like refraction) or stay outside (like reflection)? Should this be
   configurable?
3. What about the ray's containers? These would be totally different on 'the
   other side'. Is it sufficient simply to reassess these? (Just one little
   issue I thought of while reading a tiny bit of the source.)
4. Come to think of it, how do we reference another individual object? That
   probably needs to be addressed.

I'm not done yet, though. To complement this effect, it would also be nice to
have multiple spaces, such that rays travelling in one space hit only things
in that space, with the exception of teleported rays, which could cross the
boundaries. These would be written in SDL with simple space{} blocks (better
ideas for the name of this?), or if none were present you'd get a default
single space.

Issue:

1. Given that POV-Ray is only designed for a single space, how would this
   interact with the rest of the code? Would it require significant changes?

A simple example of this latter feature:

space {
    camera {
        right x*4/3
        location -4*z
        look_at 0
        angle 47
    }
    box { -1, 1 pigment { color Red } }
}
space {
    sphere { 0, 1 pigment { color Green } }  // Not visible to above camera
}

Okay, that's all for now. Does any of this make sense? Comments, please.

-- 
| Email: Daniel Dawson <ddawson at icehouse.net>      ifMUD: DanDawson |
| Web: http://www.icehouse.net/ddawson/   PGP key: 'about' on web site |

Post a reply to this message

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

Daniel Dawson wrote:
> Hello, everyone. First of all, I have to say I'm new to POV-Ray development, so
> I hope you forgive my boldness in posting my wild and somewhat ambitious idea
> here. I realize this is a bit... esoteric? But that's sort of the way I am. :-)
> Anyway, I would appreciate thoughts on this. I'm not requesting this as an
> official feature; I just want input.
> 
> 
> Okay, that's all for now. Does any of this make sense? Comments, please.
> 
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.

the notion of "space" is not part of the initial proposal, but is
usually not needed if you can separate enough the non-mixing space
(hiding one behind the camera if you have no reflection, or far far
away, or behind the floor...)

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.



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

iD8DBQFDRPHSs/YJ43cSjHIRAmH4AJ9RZ0R5lzIzAKz9YvtmJL4MT+WmNACeKp7U
Cqzg7XjCLh6u1V9+laqsXlk=
=Z0lx
-----END PGP SIGNATURE-----

Post a reply to this message

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.

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

Anyway, as I said I'll be posting on p.u.p from now on.

-- 
| Email: Daniel Dawson <ddawson at icehouse.net>      ifMUD: DanDawson |
| Web: http://www.icehouse.net/ddawson/   PGP key: 'about' on web site |

Post a reply to this message