 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Okay I have a patch designed and am about ready to implement. But
I haven't clue what to call the keyword. I have come up with two
but rejected for various reasons.
What it does:
Its a new pigment (non pattern) that Transforms
the ray and traces that to determine the color of the pigment.
you would be able to make holograms, security monitors
recursive images , surreal images etc.
the syntax would be
PIGMENT_TYPE
[transmit float]
[filter float]
[depth float]
transforms
the two names i've comeup with are
warp (rejected to parsing confusion}
displace (rejected as not to confuse
non exsistant displacement mapping)
any ideas?
--
Matthew Corey Brown XenoArch
mcb### [at] xenoarch com http://www.xenoarch.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>What it does:
>Its a new pigment (non pattern) that Transforms
>the ray and traces that to determine the color of the pigment.
>you would be able to make holograms, security monitors
>recursive images , surreal images etc.
I'm afraid I don't understand your explanation. Could you perhaps rephrase
this? After I get it, then I'll suggest a name. Perhaps "hologram" wouldn't
be a bad idea, if you say it does that. Could you post an example image?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3878D443.E7B1EE2B@xenoarch.com>, Matthew Corey Brown -
XenoArch <mcb### [at] xenoarchcom> wrote:
> Okay I have a patch designed and am about ready to implement. But
> I haven't clue what to call the keyword. I have come up with two
> but rejected for various reasons.
>
> What it does:
> Its a new pigment (non pattern) that Transforms
> the ray and traces that to determine the color of the pigment.
> you would be able to make holograms, security monitors
> recursive images , surreal images etc.
Unless I completely misunderstand you, this sounds like something I have
been thinking about for some time now, but never got around to
implementing. I would call it "portal", because it would make the object
act like a link to another position in space.
And what I was thinking of would be less flexible than what you are
doing.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TonyB wrote:
>
> >What it does:
> >Its a new pigment (non pattern) that Transforms
> >the ray and traces that to determine the color of the pigment.
> >you would be able to make holograms, security monitors
> >recursive images , surreal images etc.
>
> I'm afraid I don't understand your explanation. Could you perhaps rephrase
> this? After I get it, then I'll suggest a name. Perhaps "hologram" wouldn't
> be a bad idea, if you say it does that. Could you post an example image?
Heh can't post an image till i implent it and i don't like
to implement till i have everything fleshed out (that includes
keywords, its the software developer in me)
.. also forgot to add following keywords (for security/tv monitor
functions)
[flatten [angle float]]
I'll try to explain better
okay instead of having a pattern and color map to determin the color
of the object, it takes the incoming ray.. transforms it with the
pigments transformations and warps then traces a new ray in the
scene using the transformed ray. Applys the resulting color
as the pigment...
Hologram is too limiting though... hmm maybe transmission
(from TV or Hologram transmissions) but would that be
confused with transmit?
another possiblity is to call it portal (ie Unreal's Portals for
those that play and it works along the same idea as that game's
portals)
well at least you got me to think of a couple more possibilties
to call it.
--
Matthew Corey Brown XenoArch
mcb### [at] xenoarchcom http://www.xenoarch.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <3878D443.E7B1EE2B@xenoarch.com>, Matthew Corey Brown -
>
> Unless I completely misunderstand you, this sounds like something I have
> been thinking about for some time now, but never got around to
> implementing. I would call it "portal", because it would make the object
> act like a link to another position in space.
> And what I was thinking of would be less flexible than what you are
> doing.
>
Thats 3 votes for portal heh (posted same time heheh.. and chris counts
as two cause he posted as i was writing my last one =} )
anyone else have any ideas?
BTW this would require you to have superpatch or megapov to work.
(uses the intersection that was added to compute_pigment)
--
Matthew Corey Brown XenoArch
mcb### [at] xenoarchcom http://www.xenoarch.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matthew Corey Brown - XenoArch wrote:
>
> Okay I have a patch designed and am about ready to implement. But
> I haven't clue what to call the keyword. I have come up with two
> but rejected for various reasons.
Portal sound more like an object identifier than a pattern modifier or
type.
How about "Transwarp" ?
It has a catchy ring to it and is moderately descriptive of the process.
--
Ken Tyler - 1300+ Povray, 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 <3878EA1A.7B5E34A7@pacbell.net>, lin### [at] povrayorg
wrote:
> Portal sound more like an object identifier than a pattern modifier or
> type.
>
> How about "Transwarp" ?
>
> It has a catchy ring to it and is moderately descriptive of the process.
I still prefer "portal", it is more descriptive of what the pigment does
than "transwarp". An object with this pigment will act like a portal to
another part of space.
A couple other possibilties:
wormhole
mirage
gateway
space_time_bending_thingammajiggy_pigment :-)
One thing that might be even more interesting would be a pigment that
takes a scene file as a parameter. Both scene files would be parsed, and
a ray could travel from one scene into the other through objects with
the portal pigment. Of course, this would require extensive
modifications to the code, and wouldn't be much more useful(if at all)
than just one scene.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Not useful? Might be an understatement there. Imagine the one scene (call it
an included scene) doing things while the main scene is rendering it in as a
sphere or box or what have you and being dynamically linked, most useful in
animation.
This type of thing reminds me of the old window viewport "world coordinates" and
such stuff somehow.
http://hpsalo.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/classes/
TGrafPort.html while not exactly the same thing I suppose it mentions "Port"
anyway and that sounds about right for this so 'portal' or at least 'port' might
be good. If the idea is to have a window on another scene part (if I follow
this at all) then I can't see a more fitting term.
Not really pigment or texture anyway is this? I mean, could be a objectless
entity right?
Bob
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-88B257.15443709012000@news.povray.org...
> In article <3878EA1A.7B5E34A7@pacbell.net>, lin### [at] povrayorg
> wrote:
>
> > Portal sound more like an object identifier than a pattern modifier or
> > type.
> >
> > How about "Transwarp" ?
> >
> > It has a catchy ring to it and is moderately descriptive of the process.
>
> I still prefer "portal", it is more descriptive of what the pigment does
> than "transwarp". An object with this pigment will act like a portal to
> another part of space.
>
> A couple other possibilties:
> wormhole
> mirage
> gateway
> space_time_bending_thingammajiggy_pigment :-)
>
> One thing that might be even more interesting would be a pigment that
> takes a scene file as a parameter. Both scene files would be parsed, and
> a ray could travel from one scene into the other through objects with
> the portal pigment. Of course, this would require extensive
> modifications to the code, and wouldn't be much more useful(if at all)
> than just one scene.
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38791738@news.povray.org>, "omniVERSE" <inv### [at] aolcom>
wrote:
> Not useful? Might be an understatement there. Imagine the one scene
> (call it
> an included scene) doing things while the main scene is rendering it in
> as a
> sphere or box or what have you and being dynamically linked, most useful
> in animation.
I meant that having it be a portal to a separate scene file wouldn't be
any more useful than being a portal to another part of the main scene.
You could make it "link" to a portion of the scene that is out of sight
instead.
> Not really pigment or texture anyway is this? I mean, could be a
> objectless entity right?
Well, it requires an object to define the area the portal occupies, and
making it a pigment type like image_map makes it a lot more
versatile(you can use it in texture_maps to make the portal irregularly
transparent, and turbulence might be interesting.
For my version I had been thinking of an "is_portal" attribute for
objects. This would have been a lot more limiting.
A couple more possibilities for the name:
ray_transform (This one is very precisely descriptive of the process,
but doesn't give a good idea of what it actually does. I don't care for
it much.)
magic_mirror
looking_glass
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matthew Corey Brown - XenoArch <mcb### [at] xenoarchcom> wrote...
> Its a new pigment (non pattern) that Transforms
> the ray and traces that to determine the color of the pigment.
> you would be able to make holograms, security monitors
> recursive images , surreal images etc.
>
There are two concepts here. One is the portal (hologram), the other is the
camera. They would have to work differently, I think.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38791f53@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:
> There are two concepts here. One is the portal (hologram), the other is
> the camera. They would have to work differently, I think.
Good point, if you made a security camera monitor using the portal
pigment, the areas visible through it would change as you moved around
the monitor.
One possible solution would be a pigment which would take the same
information the camera takes. This would probably have to render the
scene from the point of view of the target position and use that as an
image map(internally). While this would be very useful, it might be
quite difficult to code.
I would be satasfied with the portal pigment. Image maps could be used
for security monitors.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
'looking_glass', I kinda like that one, even if it is a bit off the beaten path.
I get what you mean and 'magic_mirror' kind of fits that too.
Bob
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-2BCC4E.18352709012000@news.povray.org...
> I meant that having it be a portal to a separate scene file wouldn't be
> any more useful than being a portal to another part of the main scene.
> You could make it "link" to a portion of the scene that is out of sight
> instead.
>
> looking_glass
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I just realized this is the multi-camera concept brought up more than once
before.
Bob
"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-63B0A7.19194709012000@news.povray.org...
> In article <38791f53@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom>
> wrote:
>
> > There are two concepts here. One is the portal (hologram), the other is
> > the camera. They would have to work differently, I think.
>
> Good point, if you made a security camera monitor using the portal
> pigment, the areas visible through it would change as you moved around
> the monitor.
> One possible solution would be a pigment which would take the same
> information the camera takes. This would probably have to render the
> scene from the point of view of the target position and use that as an
> image map(internally). While this would be very useful, it might be
> quite difficult to code.
>
> I would be satasfied with the portal pigment. Image maps could be used
> for security monitors.
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh! Now I get it! (Please don't talk about rays that go somewhere, just say
"camera"). OK. In that case, "portal" sounds good enough to me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <38791f53@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom>
> wrote:
>
> > There are two concepts here. One is the portal (hologram), the other is
> > the camera. They would have to work differently, I think.
>
> Good point, if you made a security camera monitor using the portal
> pigment, the areas visible through it would change as you moved around
> the monitor.
Hence flaten Key word with extra angle. which i forgot to mention
in the first post. However it does require an addition to both
Trace(.., MaxDepth) and Compute_Pigment(..., Ray)
They would work differntly.. but only by calculation of
the ray to trace other wise the other configurations
can be applied to each type.
--
Matthew Corey Brown XenoArch
mcb### [at] xenoarchcom http://www.xenoarch.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoocom> wrote...
> One possible solution would be a pigment which would take the same
> information the camera takes. This would probably have to render the
> scene from the point of view of the target position and use that as an
> image map(internally). While this would be very useful, it might be
> quite difficult to code.
Actually, there is a very nice function called create_ray() in render.c that
would make this relatively easy, with no need to use an internal image map.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38794ffc@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:
> Chris Huff <chr### [at] yahoocom> wrote...
> > One possible solution would be a pigment which would take the same
> > information the camera takes. This would probably have to render the
> > scene from the point of view of the target position and use that as an
> > image map(internally). While this would be very useful, it might be
> > quite difficult to code.
>
> Actually, there is a very nice function called create_ray() in render.c
> that
> would make this relatively easy, with no need to use an internal image
> map.
How would it handle the projection? Since it is being projected onto an
arbitrary object, not necessarily a flat screen plane.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoocom> wrote...
> How would it handle the projection? Since it is being projected onto an
> arbitrary object, not necessarily a flat screen plane.
I would use a syntax as a mix between image_map and camera. You'd specify a
bunch of camera options, and then image_map options. The image_map options
would determine the mapping (which determines the x and y values that), and
the camera options would determine how the new ray that was created (by
calling create_ray with those x and y values). Then, you'd just have to
trace the ray that create_ray created.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
From: Nieminen Juha
Subject: Re: Help on comming up with keyword name
Date: 10 Jan 2000 08:48:08
Message: <3879e318@news.povray.org>
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoocom> wrote:
: Good point, if you made a security camera monitor using the portal
: pigment, the areas visible through it would change as you moved around
: the monitor.
Not if you make the ray to go always in the same direction, independently
of the direction of the incoming ray.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am thinking mirage would be fairly descriptive. This does pretty much
what they do. Bends the view to see something that you can't see
from where you are.
Chris Huff wrote:
>
> In article <3878EA1A.7B5E34A7@pacbell.net>, lin### [at] povrayorg
> wrote:
>
> > Portal sound more like an object identifier than a pattern modifier or
> > type.
> >
> > How about "Transwarp" ?
> >
> > It has a catchy ring to it and is moderately descriptive of the process.
>
> I still prefer "portal", it is more descriptive of what the pigment does
> than "transwarp". An object with this pigment will act like a portal to
> another part of space.
>
> A couple other possibilties:
> wormhole
> mirage
> gateway
> space_time_bending_thingammajiggy_pigment :-)
>
> One thing that might be even more interesting would be a pigment that
> takes a scene file as a parameter. Both scene files would be parsed, and
> a ray could travel from one scene into the other through objects with
> the portal pigment. Of course, this would require extensive
> modifications to the code, and wouldn't be much more useful(if at all)
> than just one scene.
>
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/
--
Mr. Art
"Often the appearance of reality is more important
than the reality of the appearance."
Bill DeWitt 2000
Post a reply to this message
|
|
| |
| |
|
|
From: Nathan Kopp
Subject: Re: Help on comming up with keyword name
Date: 10 Jan 2000 10:08:54
Message: <3879f606@news.povray.org>
|
|
|
| |
| |
|
|
Nieminen Juha <war### [at] punarastascstutfi> wrote...
> Chris Huff <chr### [at] yahoocom> wrote:
> : Good point, if you made a security camera monitor using the portal
> : pigment, the areas visible through it would change as you moved around
> : the monitor.
>
> Not if you make the ray to go always in the same direction,
independently
> of the direction of the incoming ray.
>
But that wouldn't do exactly what you want. That would only produce an
orthographic camera, not a perspective camera. And what if you wanted your
camera security camera to do ultra_wide_angle.
Even better, if you could specify an entire camera for the pigment, it would
make it really easy to set up those cross-eye 3D images, since you could
create one main camera which points at two boxes, each with a pigment
created from another camera.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <387958f4@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:
> I would use a syntax as a mix between image_map and camera. You'd
> specify a
> bunch of camera options, and then image_map options. The image_map
> options
> would determine the mapping (which determines the x and y values that),
> and
> the camera options would determine how the new ray that was created (by
> calling create_ray with those x and y values). Then, you'd just have to
> trace the ray that create_ray created.
I think I see what you are saying, sort of UV-map a camera onto the
object?
Hmm, and two additional types would be a pseudo-orthographic(where the
rays are always shot in the same direction, no matter what their
position), and one where the rays are always shot through a point in
space. This might be similar to perspective.
This could be a very fun tool, especially with warps and pigment_maps.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
From: Philippe Debar
Subject: Re: Help on comming up with keyword name
Date: 11 Jan 2000 03:22:17
Message: <387ae839@news.povray.org>
|
|
|
| |
| |
|
|
mirage ?
Post a reply to this message
|
|
| |
| |
|
|
From: Nieminen Juha
Subject: Re: Help on comming up with keyword name
Date: 11 Jan 2000 05:15:38
Message: <387b02ca@news.povray.org>
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
:> Not if you make the ray to go always in the same direction,
: independently
:> of the direction of the incoming ray.
: But that wouldn't do exactly what you want. That would only produce an
: orthographic camera, not a perspective camera. And what if you wanted your
: camera security camera to do ultra_wide_angle.
Ok, my statement was incomplete.
What I meant was that for a _specific point_ the ray could go always to
the same direction. The direction could then depend on the point calculated
(but not on the direction of the incoming ray), thus allowing perspective or
whatever.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
