Thanks to Thorsten and Ryan, your comments help me a lot!
Another question on ray-tracing, why does parallel ray tracing use screen
space task subdivision? For example, share the scene in all the machines,
and distribute small tiles to different machines. In my knowledge, it seems
that it is to both balance the work and to co-operatte with anti-alias
part, are there any other considerations?
  Thanks.
--
  Chen

Ryan Lamansky <Spa### [at] kardaxcom> wrote:
> Chen Yang wrote:
> > hi, all:
> >   I'm a novice in ray tracing. I'm currently parallelizing povray using
> > threads, but I have problem in making it generate the same result as the
> > sequential version, I have spent some time in finding the problem
>
> There's more than one problem :)
>
> > What's the random number usage in povray? I found it is used in supersample/sample
distribution.
>
> It's used all over the place.  I solved the threaded-randomness problem
> by making the "random" functionality instanced, rather than global.
>
> Using instances rather than globals is the key to making POV-Ray
> thread-safe.  However, as Thorsten indicated, this is no small
> undertaking.  Many algorithms in POV-Ray need adjustments to be made
> thread-safe.
>
> To your specific question, the anti-aliasing system in POV-Ray is very
> anti-threads.  I ended up rewriting it.
>
> The technique I'm using is to make two passes on the image.  The first
> pass is one ray through the middle of the every pixel, storing the raw
> result in memory.  The second pass compares the in-memory pixels to
> their 8 surrounding neighbors and then throws a user-defined amount of
> additional rays in an even pattern within the pixel, averaging the results.
>
> The first-to-second-pass transition is the only time the threads have to
> synchronize.  During the rendering, they each work on their own pixel
> and use thread-safe incrementing on a global counter to divide the
> workload.  It works flawlessly--I've tested it on 4-way Xeon systems
> with no artifacts or glitches at all (not to mention that it was very
> fast :)
>
> The main drawback to this technique is that it takes 20 bytes of memory
> per pixel to hold the buffer for the first pass.  10 years ago, that
> problem would have made it unfeasable, but on modern hardware it's not bad.
>
> If one was willing to give up the precision of floating point color
> channels, that could be reduced to 4 bytes per pixel by using RGBA
> values stored in 8-bit integers.
>
> The result is not quite as good as either of the original algorithms,
> but it's not bad at all--most people wouldn't notice.  Some further work
> could resolve the remaining quality differences, if I had time to spend
> on it.
>
> >      Also, I have one question, how do you graphic guys consider whether the
> > generated result is correct or not? Do you permit certain difference in
> > pixels?
>
> Mapping infinitely-precise objects onto square pixels is automatically
> "incorrect".  In the graphics world, we strive for the best possible
> approximation.
>
> -Ryan

Post a reply to this message