On Tue, 05 Dec 2000 05:41:52 -0500, Chris Huff wrote:
>In article <slr### [at] tealhhjpat>, 
>hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
>
>> I don't think you can have only one hair in memory at a time with
>> povray. At the very least you must have all hairs which might
>> intersect the current ray.
>
>Of course you can...just generate each hair and then check for
>"intersection" instead of reading it from memory and testing it. Or
>generate each hair and add it's contribution into the total.

Hmm, that gives me an idea (together with "media-like"). You could
indeed just convert all those hairs into a density field. But I think
that such a density field would need really humongous amounts of memory
- many gigabytes even for moderate resolutions. Using an octree
representation might bring it back into the "feasible" range, though.

>> that's 24*n+8+4+48 bytes per hair, if the spline has n control
>> points. Assuming 5 CP's to be enough for curvy hair, that's 180
>> bytes/hair or 180 MB for 1 million hairs.
>
>That would be 32*n+...each control point has a vector(3 doubles) as
>well as a t value(another double). 1000000 hairs: 171.6MB

The t value isn't necessary for all types of splines (e.g. Bezier
splines don't need it), but that's just hair splitting :-)

>> A lot - but not unfeasible if you want to render a single animal (or
>> even a small number of them).
>
>Um, >170MB per animal for several animals as well as (possibly more
>hundreds of megabytes of) scenery? What computer are you using?!?

A PIII/500 MHz with 256 MB of RAM. Which is probably better than
average, but not in the "have to win the lottery to afford that" range.

I have had scenes which required about 700 MB of virtual memory. After
the parsing, the slowdown isn't that bad.

So 2 or 3 animals would probably be feasible on that machine.

>Not many people are going to render empty shells of hair...though that
>might be interesting, especially with an explode include file and a
>poodle model. :-)
>
>
>> Maybe. But if a media-like rendering algorithm builds on the same
>> idea, I fail to see how it can possibly be much faster or less
>> memory-hungry.
>
>Faster...because it can skip calculating many hairs,

Only those not contributing to the image, which shouldn't be that many
(about half of them).

>and avoid certain calculations that must be done for objects such as
>normals and perturbed normals,

I would skip these for a hair object, too (a hair is too thin to have an
interesting normal).

>calculating the effect of many hairs that are too small to be seen
>individually because they would only cover a small fraction of a pixel.

Note that I wrote "building on the same idea". The idea seems to be to
model indiviual hairs. If you find an efficient way to calculate the
effect of many hairs, it probably isn't the same idea any more.


>Less memory hungry, since it can keep only the needed hairs in memory,
>maybe cacheing them for later access if there is enough memory.

True.

>Also, an object based hair will require anti-aliasing and could lose a
>lot of detail in that process,

Anti-aliasing doesn't lose detail, it gains additional detail (or at
least accuracy).

	hp

-- 
   _  | Peter J. Holzer    | Es war nicht Gegenstand der Abstimmung zu

| |   | hjp### [at] wsracat      | Zahlen neu festzulegen.
__/   | http://www.hjp.at/ |	-- Johannes Schwenke <jby### [at] ginkode>

Post a reply to this message