[Bf-cycles] Future of the non-progressive renderer and Cycles strand rendering

[Brecht Van Lommel]

On Tue, Jan 8, 2013 at 12:35 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> Estimating only the root may not be precise enough though.
>> If you've got a field of grass, the difference between the near and
>> far grass width may be quite big, and a too conservative estimate
>> would be a big performance problem.
>
> My apologies, I think I wasn't as clear as I could have been.  If you
> look at my psuedo-code, you'll see that new radii are being estimated
> at each bounding box.  The trick is boot-strapping that process at the
> root.

Ah, I didn't read the pseudocode correctly :)

> If we're considering only a single bounding box, we have the following
> catch-22 problem:
> 1. To accurately estimate a maximum ray footprint within a bounding
> box, you need the near and far hit distances with that bounding box.
> 2. For the present issue, however, the size of the bounding box
> depends on the estimated ray footprint.
>
> It's a cyclic dependency, essentially, between ray footprint and
> bounding box size.

I don't think there needs to be a cycle dependency? It depends on the
implementation, but probably you would compute radius of a curve key
based on the curve key point only, not the location on the curve
surface (otherwise you get a cycle dependency in the curve
intersection code).

So then the far intersection point of a ray-box intersection is not
the "farthest point" we need. Instead that would be something like the
farthest of the 8 corners of the bounding box.

Brecht.