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

In article <3a6bf8c3@news.povray.org>, "Gail Shaw" 
<gsh### [at] monotixcoza> wrote:

> Now that looks cool!! 

Thanks.


> Will the pigment be usable in pigment maps?

It should be.


> functions?

No...it requires ray and intersection information, so you can't use it 
in functions or media density. I don't think it would be very useful 
function anyway...and I think the media sampling would leave 
unacceptable artifacts, though it might be possible to do something in 
that case.


> How fast/slow is it?

About as fast as transparent or reflective textures.


> Do you plan to remove the limitations re direct light coming through
> a portal?

Not currently...the only way I can think of to do that would be to 
create a duplicate version of all light sources that is transformed to a 
position that would make it appear on the far side of the portal, and 
only accept direct rays that hit the portal object...and this would only 
work for type 0 portals, and wouldn't be easy to implement. Of course, 
maybe it only makes sense for type 0 portals...

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

In article <3A6C066E.16B33891@skynet.be>, Fabien Mosen 
<fab### [at] skynetbe> wrote:


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

No more than it would be to make all the other pigments 
image_maps...except for camera portals, it isn't very similar at all. 
The only thing they have in common is that they produce colors, which 
*all* pigments do.


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

But you can't map the portals to a 0, 1 area...they cover a 3D surface 
defined by the object the portal pigment is applied to.

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

Chris Huff wrote:
> 
> > How fast/slow is it?
> 
> About as fast as transparent or reflective textures.
> 

Can you have more than one portal in a scene?

If yes, how do you handle a portal which see another
portable which see the first... (i.e. Do you limit
the recursion level ?)

Post a reply to this message

In article <3A6C1D7F.D7CEEEBE@atosorigin.com>, Jerome Grimbert 
<jer### [at] atosorigincom> wrote:

> Can you have more than one portal in a scene?

The number is limited only by the number of objects you can have...it's 
just a pigment.


> If yes, how do you handle a portal which see another
> portable which see the first...

No special handling is required for this, it will just behave similarly 
to a portal that looks directly into itself.


> (i.e. Do you limit the recursion level ?)

The recursion level is limited by max_trace_level, just like 
transparence and reflection.

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

Fabien Mosen wrote:

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

This is a really cool feature you've developed, Chris. But perhaps it's
a limitation of my understanding in that I cannot grasp its use beyond
type of application proposed by Fabien.  While I'd love to do anims
where say there are TV monitors showing 2-3 extra views of the same
action,  I still don't comprehend the concept of "portal object."

Post a reply to this message

Chris Huff wrote:
> 
> > Do you plan to remove the limitations re direct light coming through
> > a portal?
> 
> Not currently...the only way I can think of to do that would be to
> create a duplicate version of all light sources that is transformed to a
> position that would make it appear on the far side of the portal, and
> only accept direct rays that hit the portal object...and this would only
> work for type 0 portals, and wouldn't be easy to implement. Of course,
> maybe it only makes sense for type 0 portals...
> 

How about photons? does it work with them like reflection?

Nice idea BTW, not only for the 'picture in a picture' scene but also for
abstract stuff just like reflection, but with probably a lot less
geometric limitations.  

When are you planning to publish it? 

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Okay, the more I read the more I know  :-)
I just meant copy&paste in the sense that the "portal" is extracting a copy of
the rendered scene from a certain viewpoint and then pasting that in the way of
a pigment applied to any other object.

Bob H.

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-3DE84C.06021022012001@news.povray.org...
>
> 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.
>
> 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.

Post a reply to this message