Daniel Dawson wrote:
> 
> 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.

Sounds mostly like the camera_view pigment to me:

http://megapov.inetart.net/manual-1.2.1/patterns.html#camera_view

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

> Sounds mostly like the camera_view pigment to me:

Would it be possible to have such a portal (A patch of Chris Huff called 
it like this IIRC) working in both directions? Following example:

A scene with just a plane in it, and on the plane stands a door frame. 
Through the door you can see a room, but it's clear that the door must 
be a portal, because you can see that the room itself is not on the 
plane. Up to this it could be done with the camera_pigment. But imagine 
I want a light_source in the room to shine light on the plane, or an 
object in the room to reflect the plane - this would not work currently, 
right? One would need a surface which teleports incoming rays, depending 
on which side of the surface they hit.

Would this be possible? And would it be worth the effort?


Florian

Post a reply to this message

My apologies. I posted to this group because I'm intending to create a
patch. But then I realized that maybe this group is primarily for
discussion about *existing* patches, and that povray.programming was better
suited. So I reposted there and canceled my post here. But the cancellation
didn't work very well, I guess. But to answer your suggestion...

Christoph Hormann <chr### [at] gmxde> wrote:
> Sounds mostly like the camera_view pigment to me:
>
> http://megapov.inetart.net/manual-1.2.1/patterns.html#camera_view

Well, I looked through the MegaPOV docs before and I didn't see that. But I
can tell you pretty quickly that it is precisely *not* when I'm after. I
already thought about such a feature and ruled it out: it merely projects
an image onto a surface as a flat image map. I want surfaces that pass
light through the way reflection and refraction do, except that instead of
sending out a new ray from the same point on the surface, it sends out a
new ray from a corresponding point on a *different* surface (where
'corresponding' is defined by some mapping).

Anyway, if there's going to be some actual development on this, would you
agree that povray.programming is a better place to discuss it?

Post a reply to this message

You pick up and read article <43444e14$1@news.povray.org>, written by 
Florian Brucker  <tor### [at] torfboldcom>. It says:
>Would it be possible to have such a portal (A patch of Chris Huff called 
>it like this IIRC) working in both directions? Following example:

Well, a google search revealed just one post on here, in which Mr. Huff posts
an example image and a (now broken) link to a video. It looks exactly like what
I'm proposing. I see though he made it as a pigment. But to me, it acts more
like reflection and refraction, so it makes more sense to make it a finish
property.

I can't seem to locate the patch, though. None of the links I found are
working.

>A scene with just a plane in it, and on the plane stands a door frame. 

Very similar to my own vision of how this could be used. :-)

>Through the door you can see a room, but it's clear that the door must 
>be a portal, because you can see that the room itself is not on the 
>plane.

...which you could see by e.g. walking around the door frame...

>Up to this it could be done with the camera_pigment.

Not even this much. The image seen in the frame would be flat with camera_view,
so it wouldn't look right unless you were right in front of the door. The image
should have depth, so it looks as though what you see really is on the other
side of the door (aside from the fact there isn't really anything back there
when you look around it).

>But imagine 
>I want a light_source in the room to shine light on the plane, or an 
>object in the room to reflect the plane - this would not work currently, 
>right?

Certainly not with camera_view.

>One would need a surface which teleports incoming rays, depending 
>on which side of the surface they hit.
>
>Would this be possible? And would it be worth the effort?

I'm confident it is possible, although to make the light go both ways, you'd
need to have a portal on each end (or find a convenient way to define both ends
in one declaration, but I don't know about that). With a one-way portal, rays
would be emitted from the remote end and come to the viewing end, but any light
shining toward the portal would have no effect on the other end.

Another thing this seems to affect: photon mapping. We'd need to add something
like a 'portals' property for photons and add code to handle portals. One-way
portals would have the opposite effect on photons as on regular raytracing:
photons go only through the viewing end, due to the forward tracing.

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

Daniel Dawson wrote:
> 
> Well, I looked through the MegaPOV docs before and I didn't see that. But I
> can tell you pretty quickly that it is precisely *not* when I'm after. I
> already thought about such a feature and ruled it out: it merely projects
> an image onto a surface as a flat image map.

Which is exactly what any POV-Ray render does.  In fact you can use the 
camera_view pigment to render a scene by placing it in front of the main 
camera and no one would notice the difference.

> I want surfaces that pass
> light through the way reflection and refraction do, except that instead of
> sending out a new ray from the same point on the surface, it sends out a
> new ray from a corresponding point on a *different* surface (where
> 'corresponding' is defined by some mapping).

I see your point but this is not as simple as it sounds.  Raytracing 
more or less relies on the rules of euclidian geometry (see 
http://en.wikipedia.org/wiki/Euclidian), esp. for shadows and by 
breaking this you won't get consistent result any more.

Everything that does not cause such trouble can already be done with 
camera_view.

> Anyway, if there's going to be some actual development on this, would you
> agree that povray.programming is a better place to discuss it?

Absolutely not.  povray.programming is for discussing aspects of the 
POV-Ray source code and right now this does not have to do anything with 
this.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

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

You pick up and read article <di2moi$37r$1@chho.imagico.de>, written by 
Christoph Hormann  <chr### [at] gmxde>. It says:
>I see your point but this is not as simple as it sounds.

I didn't think it would be that simple, as you can see by the original posting
(the one I rashly canceled). Actually the version I posted on
povray.programming is slightly better developed.

>Raytracing more or less relies on the rules of euclidian geometry (see 
>http://en.wikipedia.org/wiki/Euclidian), esp. for shadows and by 
>breaking this you won't get consistent result any more.

You have a point here. Shadow casting works simply by shooting a ray from a
surface point to a light source (depends on the first axiom), but it may be
difficult to find a light source through a portal. There may be a not-too-bad
solution for a surface like a polygon or a cube, but most curved surfaces would
present difficulty. Of course, differently-shaped surfaces make mapping from
one to the other difficult for any kind of tracing (just how do you map a cube
onto a torus, for instance?), so it might be necessary to restrict the object
type severely, which calls into question teleportation's relation to textures
(finish *or* pigment).

OTOH, perhaps photon mapping won't have the same problem as shadow casting, as
long as portals are two-way. But that probably has nothing to do with the
shadow problem.

I'm definitely getting the feeling that some technique would have to be
developed just to handle shadows for this feature (if it's even slightly
feasible). This will take a lot of thought.

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

Daniel Dawson wrote:
> 
> OTOH, perhaps photon mapping won't have the same problem as shadow casting, as
> long as portals are two-way. But that probably has nothing to do with the
> shadow problem.

It would indeed be good if photons were supported by camera_view but 
even that is quite a problem.  You can find a test image for a hackish 
implementation of this on:

http://www.tu-bs.de/~y0013390/files/portal_phot.png

which quite clearly shows various serious issues (partly related to the 
screwed geometry as well).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann wrote:
> Daniel Dawson wrote:
> 
>>
>> 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.
[snip]
> 
> Sounds mostly like the camera_view pigment to me:
> 
> http://megapov.inetart.net/manual-1.2.1/patterns.html#camera_view
> 
> Christoph
> 
Or if someone feels adventurous enough, then POVMan can be used for such 
purpose:
 >http://news.povray.org/povray.binaries.images/message/%3C3A6DB06D.7D620ADA%40aetec.ee%3E/#%3C3A6DB06D.7D620ADA%40aetec.ee%3E

Post a reply to this message

In article <9um### [at] ddawsonfoo>,
 dda### [at] nospam-icehousenet (Daniel Dawson) wrote:

> You pick up and read article <43444e14$1@news.povray.org>, written by 
> Florian Brucker  <tor### [at] torfboldcom>. It says:
> >Would it be possible to have such a portal (A patch of Chris Huff called 
> >it like this IIRC) working in both directions? Following example:
> 
> Well, a google search revealed just one post on here, in which Mr. Huff posts
> an example image and a (now broken) link to a video. It looks exactly like 
> what
> I'm proposing. I see though he made it as a pigment. But to me, it acts more
> like reflection and refraction, so it makes more sense to make it a finish
> property.

Well, that was a long time ago...
This would really best be implemented as neither a pigment nor a texture 
attribute, but rather a type of scene-level object. What I did was 
transform the rays by a linear transformation, using the transformed 
intersection locations as the origins, effectively mapping the rays to a 
"phantom" copy of the portal object with those transformations applied.

Correct lighting and two-way portals could be done by testing shadow 
rays against those phantom objects and transformed versions of light 
sources. It should even be possible to do nonlinear mappings, though 
correct shadows and lighting would require photon mapping. It would 
probably be a good idea to use light groups to tell POV which lights can 
shine through the portal, to limit the number of lights duplicated and 
transformed. The full implementation would be a fairly complex and 
special-purpose patch, which is why I never pursued it. The partial 
implementation as a pigment is really quite simple, though.

-- 
Christopher James Huff <cja### [at] gmailcom>
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message