 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18 Jul 2000 05:30:53 -0400, Warp <war### [at] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
