 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> I'm currently working on a "portal" pigment. (Basically,
> rays hit the pigment and stop, and reappear from somewhere
> else going in a different direction...at least that's what
> the user sees. Like a portal from one area to another.)
That so cool Chris! I've been thinking about such a feature lots of times.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] iname com> wrote in message
news:3a6868e3$1@news.povray.org...
> "Chris Huff" wrote:
> > I'm currently working on a "portal" pigment. (Basically,
> > rays hit the pigment and stop, and reappear from somewhere
> > else going in a different direction...at least that's what
> > the user sees. Like a portal from one area to another.)
>
> That so cool Chris! I've been thinking about such a feature lots of times.
>
I seem to remember that this concept came up about 2 yrs ago... Was that you
or Chris?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a686948@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk>
wrote:
> I seem to remember that this concept came up about 2 yrs ago... Was that
> you or Chris?
Someone else (Xenoarch?) wrote a similar patch, I think he called it
"hologram" though. (other names that got tossed around ranged from
"magic_mirror" to "mirage"...)
I just got impatient waiting for it to show up, so I started writing my
own. It currently works, but isn't very functional yet...I've been
trying to implement the ability to use a camera as a portal (the effect
would be similar to rendering the image from a different camera and
using that image as an image_map, but would be done on the fly), and one
of the problems is that the camera code assumes it is rendering pixels
of the output image and that there is only one camera in the scene. (I
had to make an almost identical copy of create_ray() which doesn't use
the precalculated information for the main camera, duplicating a lot of
code...and focal blur won't work for a while)
Followups to povray.unofficial.patches...
--
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:
> I've been trying to implement the ability to use a camera
> as a portal (the effect would be similar to rendering the
> image from a different camera and using that image as an
> image_map, but would be done on the fly),
If that's how it would be I don't think "portal" would be a good name.
What I was thinking of was merely a "ray transform". When a ray hits the
portal pigment, the ray is transformed by a user-specified transform, and
continues from a new point. That way, when the camera moves around, the view
of the portal changes, and it would truly look like a portal, and not just
an image.
Both types would be very useful. I hope you'll implement both! :)
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a68ccef@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> If that's how it would be I don't think "portal" would be a good name.
The camera feature is just part of the portal patch, there are several
others. For example, ray direction defined by the normal of the surface
hit, pseudo-perspective, orthographic, "teleportation" portals where the
rays simply reappear somewhere else with the same origin and direction
relative to each other (though not to the original rays)...the camera
feature will be just one type.
> What I was thinking of was merely a "ray transform". When a ray hits
> the portal pigment, the ray is transformed by a user-specified
> transform, and continues from a new point. That way, when the camera
> moves around, the view of the portal changes, and it would truly look
> like a portal, and not just an image.
That is what the "teleportation" portal will be, it is the only one
where direction of the ray on exit depends on the direction on entrance,
though I will probably add other effects like this later.
--
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:
> The camera feature is just part of the portal patch,
> there are several others.
Great!
Here's a thing I've been thinking about. A "world" feature.
It would allow to split up a scene into different co-existing worlds. Each
world would have its own objects, light_sources, camera, sky_sphere,
background color and so on. One world would be completely unaffected by
things from the other worlds. That is, objets in world 1 would only be
affected by light_sources in world 1, the camera in world 1 would only see
the objects in world 1, and so on.
The different worlds would be connected by the portal features. So in world
1 you could have a TV showing things from world 2, and the scene in the TV
would be completely independent on the main scene and vice versa.
You could also make a portal from world 1 to world 2, and the two worlds
could be completely different.
But the feature could be used not only for special effects, but also for
useful everyday things:
Imagine having 3 worlds. World 1 and world 2 are the actual scenes. You want
to make an animation clip from scene 1 to scene 2, but it should be one of
those a smooth clips which gradually fades from one scene to the other. So
in world 3 you simply make a portal to world 1 and one to world 2 on top of
each other. Then you change the transparency of the upper portal texture
from 100% to 0%. And, see, you have a smooth gradient clip!
You could also use it to place a rendered object in front of your scene
*without* the object being affected by the perspective of the scene! So far
this has only been possible by using image_maps. It would also be easier
than ever to add signatures to your image from inside POV-Ray.
Do you understand what I mean? I think it would be *very* useful for *many*
things, but it would probably also be difficult to implement.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a697e3d@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> Here's a thing I've been thinking about. A "world" feature.
>
> It would allow to split up a scene into different co-existing worlds.
> Each world would have its own objects, light_sources, camera,
> sky_sphere, background color and so on. One world would be completely
> unaffected by things from the other worlds. That is, objets in world
> 1 would only be affected by light_sources in world 1, the camera in
> world 1 would only see the objects in world 1, and so on.
I briefly considered this exact feature, but there is no way I could do
it. Maybe when POV 4.0 is available, and the source code is fully
object-oriented, it could be modified to handle multiple universes, but
for now you will just have to settle for putting them in unions with
their own spheres for skies, and translating them apart so they don't
interfere with each other. The current code is just too much of a mess,
and was never designed for more than one virtual universe...
> Imagine having 3 worlds. World 1 and world 2 are the actual scenes.
> You want to make an animation clip from scene 1 to scene 2, but it
> should be one of those a smooth clips which gradually fades from one
> scene to the other. So in world 3 you simply make a portal to world 1
> and one to world 2 on top of each other. Then you change the
> transparency of the upper portal texture from 100% to 0%. And, see,
> you have a smooth gradient clip!
Or a pigment map of several portal_pigments, and use the function
pattern to change portals...(just use a single value as the function, it
would act like the "solid" pattern)
> You could also use it to place a rendered object in front of your
> scene *without* the object being affected by the perspective of the
> scene! So far this has only been possible by using image_maps. It
> would also be easier than ever to add signatures to your image from
> inside POV-Ray.
>
> Do you understand what I mean? I think it would be *very* useful for
> *many* things, but it would probably also be difficult to implement.
In the current code, it would require rewriting a lot of stuff...there
are lots of globals that would need to be wrapped together into a
separate data structure for each universe, or at least saved separately
while another universe is being used. The C++ rewrite for version 4.0
should fix most of these problems.
The syntax would be pretty easy though...just something like the camera:
the last world defined is the one that gets used, and you would be able
to #declare them to allow you to refer to them from other worlds.
--
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:
> and the source code is fully object-oriented ...
If the source code is fully object-oriented...
--
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A69BA2F.5FB74425@pacbell.net>, lin### [at] povrayorg
wrote:
> > and the source code is fully object-oriented ...
>
> If the source code is fully object-oriented...
The main reason to choose C++ as the language to rewrite POV 4.0 in,
would be to make using OOP concepts a lot easier to use. The current
source code has to mess around with function pointers in order to mimic
objects. You *could* do the same thing in C++, but there would be no
reason to do so...it just makes things unnecesarily difficult to modify.
For example, to add a proximity function in the current source, I would
have to modify the code for every shape...in C++ I would only have to
modify a small amount of code in the base shape and it would be
inherited by all of the other shapes.
I think it's safe to say that most of the reason for choosing C++ is to
allow making the source code fully object-oriented.
--
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:
>
> I think it's safe to say that most of the reason for choosing C++ is to
> allow making the source code fully object-oriented.
Is there any other?
Other than being allowed to use // comments.
--
Francois Labreque | In the future, performance will be measured
flabreque | by the size of your pipe.
@ | - Dogbert, on networking
videotron.ca
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
