Text archives Help

---

That all sounds good to me and I'd be willing to try getting general frustums working in the grid.

Thiago

Solomon Boulos wrote:

Why not add a computeCornerRays method to RayPacket similar to the way normalized directions works? This would encapsulate the code, allow it to be computed only when used, and allow for easier upgrades in the future (for example, adding non-constant origin corner rays).

Admittedly, the pinhole camera case is going to be faster than a more "black-box" ray packet function, but having both wouldn't be a problem (there are many spots in Manta where some code says "I know that this property will hold" and sets the appropriate flags). I would probably vote for having this as an additional option as well though (so that if you ask for normalizeRays you don't always get corner rays).

I'd be willing to help port my general frustum and corner ray building code if there's an interest in that as well (as long as someone from the grid camp will get it to work inside the grid code).

On Aug 11, 2007, at 6:21 PM, thiago@sci.utah.edu wrote:

Author: thiago
Date: Sat Aug 11 18:21:07 2007
New Revision: 1626

Modified:
   trunk/Model/Cameras/PinholeCamera.cc
Log:
Added the computation of corner rays to the creation of normalized
camera rays. This makes things that use SSE WaldTriangles (and square
ray packets) faster. For example, the conference scene rendered with
DynBVH becomes about 5% faster. All other primitives could also use
the corner rays to do frustum culling and get similar performance
improvements. I (or someone else) still need to add this to the
non-normalized camera ray generation. If someone thinks this code
should go somewhere else (cleaner without being slower to generate the
corner rays), let me know.

---

• [MANTA] r1626 - trunk/Model/Cameras, thiago, 08/11/2007
  • Re: [MANTA] r1626 - trunk/Model/Cameras, Solomon Boulos, 08/11/2007
    • Re: [MANTA] r1626 - trunk/Model/Cameras, Thiago Ize, 08/11/2007

---

Archive powered by MHonArc 2.6.16.