 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
looking at the docs, i see that a cylindrical camera makes an image of
the outside of the cylinder, which presumably has no radius. what i
would like to do is specify a radius (in order to envelope objects) and
then create the image based on the inside of the cylinder. this (i
think) would have the effect of "unrolling" the object into two
dimensions, ready to be used as a template for image maps, bumpmaps, or
image pattern maps and could be rolled back onto the object using
cylindical mapping. this would eliminate the need to divide a model
into two halves and then use planar image mapping as was done, for
example, in h.e. day's raptor model. a spherical cam that could also do
this would be similarly useful. would this be difficult to implement?
do others think this would be useful?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Two suggestions:
First, try using the sphere_camera (spherical_camera) in MegaPOV. To quote
from the docs, '...If you render an image with a 2:1 aspect ratio and map it to
a sphere using spherical mapping, it will recreate the scene!'
Secondly, if you're working with meshes, try using Steve Cox's UV Mapper:
http://home.pb.net/~stevecox/uvmapper.htm
Gilles Tran has a very helpful tutorial for working with it here:
http://www.mediaport.net/Artichaud/Tran/sources/tutuve.htm
Hope this helps...
ryan constantine <rco### [at] yahoo com> wrote in message
news:39721EB9.554BD97C@yahoo.com...
| looking at the docs, i see that a cylindrical camera makes an image of
| the outside of the cylinder, which presumably has no radius. what i
| would like to do is specify a radius (in order to envelope objects) and
| then create the image based on the inside of the cylinder. this (i
| think) would have the effect of "unrolling" the object into two
| dimensions, ready to be used as a template for image maps, bumpmaps, or
| image pattern maps and could be rolled back onto the object using
| cylindical mapping. this would eliminate the need to divide a model
| into two halves and then use planar image mapping as was done, for
| example, in h.e. day's raptor model. a spherical cam that could also do
| this would be similarly useful. would this be difficult to implement?
| do others think this would be useful?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
no offense, but i think you missed my point altogether. i have a model
constructed. i want to see the front and the back of the model all at
the same time. i want to use the image and bring it into a paint
program. there i will color code areas for use as image pattern maps.
currently, the only method one can use is to do an orthographic
projection to make the image. then, after making the textures, use
planar mapping on the object. using this method, however, requires two
halves of the original object and an image map for the top and one for
the bottom.
Alan wrote:
>
> Two suggestions:
>
> First, try using the sphere_camera (spherical_camera) in MegaPOV. To quote
> from the docs, '...If you render an image with a 2:1 aspect ratio and map it to
> a sphere using spherical mapping, it will recreate the scene!'
>
> Secondly, if you're working with meshes, try using Steve Cox's UV Mapper:
> http://home.pb.net/~stevecox/uvmapper.htm
>
> Gilles Tran has a very helpful tutorial for working with it here:
> http://www.mediaport.net/Artichaud/Tran/sources/tutuve.htm
>
> Hope this helps...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39721EB9.554BD97C@yahoo.com>, ryan constantine
<rco### [at] yahoocom> wrote:
> looking at the docs, i see that a cylindrical camera makes an image of
> the outside of the cylinder, which presumably has no radius. what i
> would like to do is specify a radius (in order to envelope objects) and
> then create the image based on the inside of the cylinder. this (i
> think) would have the effect of "unrolling" the object into two
> dimensions, ready to be used as a template for image maps, bumpmaps, or
> image pattern maps and could be rolled back onto the object using
> cylindical mapping. this would eliminate the need to divide a model
> into two halves and then use planar image mapping as was done, for
> example, in h.e. day's raptor model. a spherical cam that could also do
> this would be similarly useful. would this be difficult to implement?
> do others think this would be useful?
This sort of "inside-out" camera should be fairly easy to do...though I
have never really looked at that portion of the code. I think an
"inverse_spherical" camera would be more useful than the cylinderical
version, since you could map the top and bottom at the same time as the
front and sides.
It wouldn't work with all objects, for example, objects with holes
running through them or parts overlapping each other, but it could be
useful for many cases.
--
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> This sort of "inside-out" camera should be fairly easy to do...though I
> have never really looked at that portion of the code. I think an
> "inverse_spherical" camera would be more useful than the cylinderical
> version, since you could map the top and bottom at the same time as the
> front and sides.
> It wouldn't work with all objects, for example, objects with holes
> running through them or parts overlapping each other, but it could be
> useful for many cases.
How 'bout this: adding "inverse" to the camera would make it the corresponding
inverse type & if there is no corresponding type the POV would show a warning
- <camtype> cannot be inverted, using non-inverted camera.
I wonder how the images would look for these weird cams.
Also what about an object_cam - to find the initial ray points you might trace
from a point like the spherical cam and where those traces hit the object you
start tracing and the ray directions would be the surface normals at those
points.
--
Bye
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think that someone suggested something like this a long time ago. The
idea was the same, ie. adding an 'inverse' keyword to the camera. It would
make povray to take the farthest intersection of the camera ray with the
scene instead of the nearest. That is, instead of shooting the ray from
the camera to the infinity, the ray is kind of shot from infinity to the
camera, and the scene is thus seen from "outside".
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ryan constantine wrote:
>this (i
>think) would have the effect of "unrolling" the object into two
>dimensions,
Newsgroups: povray.binaries.images
Subject: Flat Cat [~50 kB]
From: ing### [at] homenl (ingo)
Message-ID: <8EC9F6D80seed7@204.213.191.228>
Date: 28 Jan 2000 17:50:25 -0500
Is this the kind of picture you're looking for?
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
but my idea included a radius, so the ray wouldn't come from infinity.
the ray would be shot from one side of the cylinder and if it hit an
object, fine, but if not, it would stop when it hit the other side of
the cylinder, as if what was contained in the cylinder was all that
existed in the universe.
Warp wrote:
>
> I think that someone suggested something like this a long time ago. The
> idea was the same, ie. adding an 'inverse' keyword to the camera. It would
> make povray to take the farthest intersection of the camera ray with the
> scene instead of the nearest. That is, instead of shooting the ray from
> the camera to the infinity, the ray is kind of shot from infinity to the
> camera, and the scene is thus seen from "outside".
>
> --
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17 Jul 2000 09:26:02 -0400, Warp <war### [at] tagpovrayorg> wrote:
> I think that someone suggested something like this a long time ago. The
>idea was the same, ie. adding an 'inverse' keyword to the camera. It would
>make povray to take the farthest intersection of the camera ray with the
>scene instead of the nearest. That is, instead of shooting the ray from
>the camera to the infinity, the ray is kind of shot from infinity to the
>camera, and the scene is thus seen from "outside".
But that would be slooow, especially with isosurfaces, text, CSG,
julias, polys etc. Shooting from 'infinity' to the camera is a better
idea, or even better, as already suggested, from a specified distance
to the camera (which would also eliminate precision problems)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] usanet> wrote:
: But that would be slooow, especially with isosurfaces, text, CSG,
: julias, polys etc.
Why should it be any slower than the usual way?
Don't tell me you think that it takes time for the ray to travel from
infinity to the scene? :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Jul 2000 05:30:53 -0400, Warp <war### [at] tagpovrayorg> wrote:
>: But that would be slooow, especially with isosurfaces, text, CSG,
>: julias, polys etc.
> Why should it be any slower than the usual way?
Because the rendered would have to find all intersections for every
object. It would be almost as slow as if all objects in the scene had
some transparency. If rays were shot backwards to the camera then only
the first intersection would have to be found (unless there's
transparency etc. you know how it goes)
> Don't tell me you think that it takes time for the ray to travel from
>infinity to the scene? :)
It doesn't? :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] usanet> wrote:
: Because the rendered would have to find all intersections for every
: object.
But that's what it currently does.
How can it know which one of the intersections is the closest one if it
didn't?
And by the way, that's what bounding shapes are for: To speed up this
process.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Jul 2000 05:56:22 -0400, Warp wrote:
>Peter Popov <pet### [at] usanet> wrote:
>: Because the rendered would have to find all intersections for every
>: object.
>
> But that's what it currently does.
> How can it know which one of the intersections is the closest one if it
>didn't?
Actually, it doesn't. Meshes and isosurfaces, at least, can and do find the
closest intersection without finding all the others.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: Actually, it doesn't. Meshes and isosurfaces, at least, can and do find the
: closest intersection without finding all the others.
I was actually thinking about all the objects as a whole. If you have several
objects, I think povray has to test the ray with all of them to see which
surface is closest?
And btw, wouldn't it be equally easy for meshes and isosurfaces to find
the farthest intersection?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Jul 2000 10:14:49 -0400, Warp wrote:
> I was actually thinking about all the objects as a whole. If you have several
>objects, I think povray has to test the ray with all of them to see which
>surface is closest?
Yes, though the various bounding strategies try to minimize that.
> And btw, wouldn't it be equally easy for meshes and isosurfaces to find
>the farthest intersection?
Probably. If nothing else, you could project the ray to the other side of the
object's bounding volume and trace it backwards.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
so does all the activity in this thread mean that someone is interested
in trying to program the new camera?
ryan constantine wrote:
>
> looking at the docs, i see that a cylindrical camera makes an image of
> the outside of the cylinder, which presumably has no radius. what i
> would like to do is specify a radius (in order to envelope objects) and
> then create the image based on the inside of the cylinder. this (i
> think) would have the effect of "unrolling" the object into two
> dimensions, ready to be used as a template for image maps, bumpmaps, or
> image pattern maps and could be rolled back onto the object using
> cylindical mapping. this would eliminate the need to divide a model
> into two halves and then use planar image mapping as was done, for
> example, in h.e. day's raptor model. a spherical cam that could also do
> this would be similarly useful. would this be difficult to implement?
> do others think this would be useful?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Jul 2000 05:56:22 -0400, Warp <war### [at] tagpovrayorg> wrote:
>Peter Popov <pet### [at] usanet> wrote:
>: Because the rendered would have to find all intersections for every
>: object.
> But that's what it currently does.
Are you sure? I thought it only did so for CSG.
> How can it know which one of the intersections is the closest one if it
>didn't?
Dunno... I think I recall Pascal Massimino explaining how he finds the
first intersection with a julia and stops there. I think I also recall
seeing something like this for other objects in the source code. This
was over a year ago though, so I might be wrong here.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote...
> Peter Popov <pet### [at] usanet> wrote:
> : Because the rendered would have to find all intersections for every
> : object.
>
> But that's what it currently does.
> How can it know which one of the intersections is the closest one if it
> didn't?
Actually, it usually (the feature can be disabled) uses a bounding-box tree
to determine which bounding boxes are closer than others, and if it finds an
intersection in a nearby bounding box, it doesn't test anything that it
knows is farther away. Also, as Ron and others mentioned, many objects only
return the closest intersection for speed reasons.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
: Actually, it usually (the feature can be disabled) uses a bounding-box tree
: to determine which bounding boxes are closer than others, and if it finds an
: intersection in a nearby bounding box, it doesn't test anything that it
: knows is farther away. Also, as Ron and others mentioned, many objects only
: return the closest intersection for speed reasons.
My point was that it doesn't matter what is the direction of the ray
(from the camera, from infinity or wherever), it will always take the same
amount of work to test the intersections.
And besides, I myself mentioned the bounding boxes somewhere :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21 Jul 2000 08:54:10 -0400, Warp <war### [at] tagpovrayorg> wrote:
> My point was that it doesn't matter what is the direction of the ray
>(from the camera, from infinity or wherever), it will always take the same
>amount of work to test the intersections.
Not so. If you look for the intersection furthest from the camera and
shoot the rays from the camera, the renderer will have to find all
intersections (slow). If you shoot them towards the camera, then the
first intersection found is the one you need (fast).
> And besides, I myself mentioned the bounding boxes somewhere :)
We know you know :)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
zzzz... snik! huh? (60 hours weeks... must... retain...
consciousness...long enough to express concept...)
Unroll the object in 2D? An inverted cylindrical camera? Ok, try
this. It needs fiddling, but maybe it can be developed into
close to what you need. If not, blame it on lack of sleep making
it impossible to be coherant and ignore me...
------------------------------------------------------------------
//kids, don't try this in standard POV (yet)
#version unofficial MegaPov 0.5;
camera { //camera to invert, h-w ratio probably needs
//adjustment, but you get the idea...
cylinder 1 up<0,1,0> right<4,0,0>
location<0,1,0>
look_at<0,1,1>
angle 360
}
cylinder { //inversion surface...adjust radius as needed.
<0,-10,0>,<0,10,0>,20
open
no_shadow //don't go blocking my light...
pigment { rgb 0 }
finish { reflection 1 }
}
sphere { //target object...center on origin.
<0,1,0>,3
no_image //reflect in cylinder but otherwise invisible
no_shadow //shadows in the way? not a good thing...
texture { //just a happy l'il texture...whatever.
pigment { rgb<0,0,1> }
finish { phong 1 }
}
}
light_source { //oh yeah, be nice if we could see, huh?
<1000,1000,-1000> color rgb<1,1,1>
}
-----------------------------------------------------------------
<C></C>
--
The Silver Tome :: http://www.silvertome.com
"Hyperbole is without a doubt the highest form
of art mankind has ever developed."
ryan constantine wrote:
>
> looking at the docs, i see that a cylindrical camera makes an image of
> the outside of the cylinder, which presumably has no radius. what i
> would like to do is specify a radius (in order to envelope objects) and
> then create the image based on the inside of the cylinder. this (i
> think) would have the effect of "unrolling" the object into two
> dimensions, ready to be used as a template for image maps, bumpmaps, or
> image pattern maps and could be rolled back onto the object using
> cylindical mapping. this would eliminate the need to divide a model
> into two halves and then use planar image mapping as was done, for
> example, in h.e. day's raptor model. a spherical cam that could also do
> this would be similarly useful. would this be difficult to implement?
> do others think this would be useful?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
