This is just a test scene for the portal pigment. The transparent blue 
thing on the left is an aid for moving the "other" end of the portal 
around.
The way things work currently is:
Step 1: Move the portal object to wherever you want the portal to view 
from.
Step 2: Apply the portal pigment.
Step 3: Move the portal object to wherever you want the actual portal to 
be.

Whenever a ray hits the portal object (which is in the position defined 
by step 3), it stops and reappears on the same position relative to the 
object, in the position it was in before step 2. The result: it appears 
that light goes into a hole in space, disappears, and reappears from 
somewhere else. It isn't two-way though, you would need two portals for 
that. I plan to add a way to transform the "other end" from the pigment 
itself so you don't have to mess around with moving the object to the 
exit point before adding the portal pigment. And though it may seem odd 
at first, it was the only useable method I could come up with...and it 
is actually very useable, though I made a simple macro to transform it 
to each position.

Anyway, this is the type 0 portal...the rays exit it going in the same 
direction relative to each other that they went in, though the direction 
of all of them can change, when the "other end" is rotated for example. 
If you move around the "viewing end", you can see into the portal at 
different angles.
Other types are type 1, where you specify a direction for the rays (kind 
of like an orthographic camera), type 2, where the direction of the rays 
is defined by the normal of the portal object, and type 3, the "security 
camera" type, which is used like an image_map but takes a camera as the 
source (and which isn't working yet).
The number of portals you see through is affected by max_trace_level, 
and you can have a portal that looks into itself, giving the "hall of 
mirrors" effect (you can see a little of that in this image). The 
rendering speed is about the same as ordinary transparence or 
reflection. Oh, and shadows don't work correctly yet...and I'm not 
really sure what "correct" is in this case. The portals are currently 
opaque as far as shadows are concerned.

There will be two kinds of transparency...one affecting things seen on 
the other end of the portal, and one affecting things seen through the 
portal object, so you can have a kind of "hologram" effect.
I have posted an animation to my web site:
http://homepage.mac.com/chrishuff/pov/portal_pigment.mov
It is a QuickTime Movie...I don't have any good way to generate MPEGs. 
(the one MPEG utility I have resulted in jerky, significantly lower 
quality results and a larger file size)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Attachments:
Download 'Portal pigment.jpeg.jpg' (19 KB)

Preview of image 'Portal pigment.jpeg.jpg'

Several minutes later I finally understand it.  Can't say that the mov
animation helped though, more like further confused me.  That's typical.
I just went back to thinking what it was about to begin with, that being a
magic mirror which is about like having more than one camera per scene, and it
made sense then.
I guess it's the way you call it a "pigment" instead of something else.  Still
wondering on that talk of transparency and shadows, maybe I'll eventually know
what you mean.

Bob H.

Post a reply to this message

In article <3a6b54e1@news.povray.org>, "Bob H." 
<per### [at] aolcom?subject=PoV-News:%20&body=Relating%20to%20POV-Ra
y:> wrote:

> Several minutes later I finally understand it.  Can't say that the mov
> animation helped though, more like further confused me.  That's typical.
> I just went back to thinking what it was about to begin with, that 
> being a magic mirror which is about like having more than one camera 
> per scene, and it made sense then.

This scene only has one camera, it's more like a one-way wormhole. I'm 
trying to get it to use cameras, though...in that case, the result will 
be the same as rendering with another camera and using that as an image 
map, except with essentially infinite resolution, much less memory, and 
much easier to use animations.


> I guess it's the way you call it a "pigment" instead of something else. 

Well, it *is* a pigment...if you don't use ambient 1, you see that it is 
really colors on the surface of an object that will get shaded like 
anything else.

 
> Still wondering on that talk of transparency and shadows, maybe I'll 
> eventually know what you mean.

Well, light going into the "far" end of the portal should pour out of 
the "near" one, but that won't happen. Well, it should be possible with 
photon mapping, but I don't know how it would be done...it would 
probably require it to be a new object type instead, and wouldn't be as 
flexible.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Would you also be able (for some nice fx) to apply it as a normal-map ???
or "something like" a slope-map ???
so that I can color the pigment in another way than in the original scene
???
to get some effects like the attached img ... (of course, this one was done
in PaintshopPro)..

... just an idea

--
Jan Walzer

Post a reply to this message

Attachments:
Download 'filter-test.jpg' (37 KB)

Preview of image 'filter-test.jpg'

On Sun, 21 Jan 2001 16:04:52 -0500 Chris Huff wrote:

>I have posted an animation to my web site:
>http://homepage.mac.com/chrishuff/pov/portal_pigment.mov
>It is a QuickTime Movie...I don't have any good way to generate MPEGs. 
>(the one MPEG utility I have resulted in jerky, significantly lower 
>quality results and a larger file size)

  Nice animation. I've always been impressed with the QuickTime port to
Windows and have found it offers very good (even excellent) quality for
downloadable movie trailers.

-- 
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

In article <3a6b6f16@news.povray.org>, "Jan Walzer" <jan### [at] lzernet> 
wrote:

> Would you also be able (for some nice fx) to apply it as a normal-map ???
> or "something like" a slope-map ???
> so that I can color the pigment in another way than in the original scene
> ???
> to get some effects like the attached img ... (of course, this one was 
> done in PaintshopPro)..

This really has nothing to do with normals, it is a pigment...are you 
asking about a pattern version of this that takes the grayscale value of 
the color as the value of the pattern? Or are you talking about filters 
for the output of the pigment, similar to some of the post_process 
filters?
You will be able to affect the general color of objects seen through the 
portal with transmit and filter keywords, but for more than that you 
might have to layer textures or even objects. Maybe what you want could 
be done as a generalized filter that will work on all pigments...but 
that would be a different patch.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

I get the idea much better having a fresh think on it.  Thanks for the
explanations.

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-06C755.19343121012001@news.povray.org...
> In article <3a6b6f16@news.povray.org>, "Jan Walzer" <jan### [at] lzernet>
> wrote:
>
> > Would you also be able (for some nice fx) to apply it as a normal-map ???
> > or "something like" a slope-map ???
> > so that I can color the pigment in another way than in the original scene
> > ???
>
> This really has nothing to do with normals, it is a pigment...

I see now what you meant before.  The portal gets applied in a way just as
pigments get applied so that even though it's a copied and pasted portion of
the original scene it's not exactly a re-raytraced portion.  That is, it's
essentially a 2D representation placed based on where the portal view is and
where it exists.
Guess I'm getting closer to the idea there.  Perhaps.

I'm supposing Jan's questions are moot points if the portal "pigment" is only
that, a pigment.  It would take storing a prerendering of just the portal and
reapplication of it in a different form to do those kinds of things.  Unless
I'm way off about the way it works as of now.

Bob H.

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote in message
news:chrishuff-484A65.16045221012001@news.povray.org...
> This is just a test scene for the portal pigment. The transparent blue
> thing on the left is an aid for moving the "other" end of the portal
> around.
> The way things work currently is:
> Step 1: Move the portal object to wherever you want the portal to view
> from.
> Step 2: Apply the portal pigment.
> Step 3: Move the portal object to wherever you want the actual portal to
> be.
>

Now that looks cool!!  Will the pigment be usable in pigment maps?
functions? How fast/slow is it?
Do you plan to remove the limitations re direct light coming through
a portal?

Gail
********************************************************************
* gsh### [at] monotixcoza              * System.dat not found.         *
* http://www.rucus.ru.ac.za/~gail/ * Reformat hard drive Y)es O)k  *
********************************************************************
* If at first you don't succeed, call it version 1.0               *
********************************************************************

Post a reply to this message

Chris Huff wrote:

> This really has nothing to do with normals, it is a pigment...

Wouldn't it be logical to use it as an image type in image_map ?

object {
       Stuff
       pigment {
               image_map {
                         portal {
                                camera {...}
                                }
                         map_type ...
                         once
                         }
               }

       }

The resulting pigment would be mapped onto 0,1 area, as usual, and
one could use image_maps keywords to control how the "image" (though
not a bitmap) is mapped onto the object.  If someone wants to make
a normal of it, there's the "pigment pattern" feature.

Just my 2 rays.

Fabien.

Post a reply to this message

In article <3a6bf3cf$1@news.povray.org>, "Bob H." 
<per### [at] aolcom?subject=PoV-News:%20&body=Relating%20to%20POV-Ra
y:> wrote:

> I see now what you meant before.  The portal gets applied in a way 
> just as pigments get applied so that even though it's a copied and 
> pasted portion of the original scene it's not exactly a re-raytraced 
> portion. 

Um, no...there is no copy/pasting of scene code. It just moves rays to 
another portion of the same scene.


> That is, it's essentially a 2D representation placed based on where 
> the portal view is and where it exists. Guess I'm getting closer to 
> the idea there.  Perhaps.

Rays hit the object, and new rays coming from the intersection points 
are transformed using the transformations that have been applied since 
the pigment was applied to the object. The color resulting from tracing 
those rays is used as the pigment color.
Think of it as a "ghost object" that is left behind at the position of 
the object when the portal pigment is applied...no matter where the 
portal object is moved, rays hitting it will emerge from that ghost 
object.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message