"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > And then, as I discovered, after hunting down a curious line of code in Ingo's
> > vrand on sphere macro, that there's the matter of not just randomly
> > placed - but EVENLY placed.   The distributions can be quite tricky.
> >
> > Lets say we take a landscape heightfield and try to place objects onto
> > it.   If we just trace() straight down from an imaginary rectangle of
> > ray starting coordinates, then the regions of rapidly changing elevation
> > don't get as much arc-length coverage as the flat parts.
> >
>
> Yeah, that little problem has always been a thorny one to try and solve. But I
> just had a wild idea (possibly a naive one):
> It seems to me that the pixel positions of a *u-v map* of a HF might somehow be
> used to generate the trace-from points. Since the u-v map is by nature a
> 'stretched-out' representation of the HF itself-- covering all of the HF's area,
> and with more points or pixel positions than a typical
> 'trace-down-from-rectangular-area' scheme -- the uv-map's points or pixels could
> then be correlated (somehow) with the corresponding points on the HF... the
> result being to 'evenly' cover the HF with trace rays, even on steep elevations.
> That's what I see in my minds eye, anyway.

The rectangle's x,z coordinates are the exact same thing as the u,v coordinates
of the heightfield, in terms of the fact that you can't subdivide the u,v's any
differently than the x,z's.   Aside from scale and absolute location, they're
exactly the same.
What needs to be done is to calculate the arc length of the curve in the u or v
direction, and then compensate for that additional distance by clustering more
random samples in those areas.

https://www.mathwords.com/a/arc_length_of_a_curve.htm

This seems to be closely related to the "importance sampling" clipka was looking
for.... 5 years ago. :O
http://news.povray.org/povray.advanced-users/thread/%3C57bf8a2f%241%40news.povray.org%3E/?ttop=433049&toff=150&mtop=410
480

It's NOT trivial, but if it were simply a matter of investing the time to
one-time algorithmically process the hf for a scene and save the data to a file,
then it probably would be worth doing...

http://news.povray.org/web.60330f52d0c3b58b1f9dae300%40news.povray.org

Post a reply to this message