On Sun, Sep 5, 2010 at 17:08, Christopher Sean Morrison <brlcad@...> wrote:
> On Sep 5, 2010, at 1:08 PM, Tom Browder wrote:
>> I've been wondering if we could save rays in a database (persistent
> We probably could, but it would only be useful if a given ray and
> geometry model were exactly the same. Rays have extremely very low
Some user responsibility needed here: read-only tgm, md5 or similar
hash of db for check, same key in ray db.
> That said, a related idea that has been discussed before is raytrace
> cache objects where an object's prep state gets saved. Especially
> with NURBS and BoT geometry, prep times can be substantial (more than
> half the time). Prep objects are view-agnostic, so they could be
> reused for any ray that is getting evaluated.
Sounds good, too. Same as above, we don't do any of this stuff with a
db that has been modified.
> You'd need something like an MD5 sum of the entire root object to
> make sure there hasn't been any geometric change through the
> hierarchy. Doable, but I do think that it'd be hard to make it
> faster than just recomputing the ray intersection calculations.
The situation, as in AJEM, is to run, say, the same 42 views, and the
same grid of rays each for umpteen times on a db with umpteen objects.
All can be done with one db read--seems like there may possibly be a
> Any new persistence model is going to require a fair bit of
> performance testing, though, as one of the major performance benefits
> of v5 is data persistence. Lookups are linear time, but then so are
But of course, as Professor Donald Knuth advises, check for the real
bottlenecks before optimizing hastily or on gut feelings (or something
Thomas M. Browder, Jr.