Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have been making a short animation of a rock crystal. An irregular mulifaceted polyhedron with a refractive material setting and a transparent texture. I have placed a point light inside the polyhedron and rendered the scene using global photon mapping (no other GI or caustics or scattering).
A single render looks fantastic. However, there seems to be a serious problem when rendering an animated sequence. Each time a new frame is rendered (with the crystal rotated slightly) the lighting effects are completely unrelated to the previous frame - there is no coherence between frames. This results in an awful animation where the crystal appears to flash with a new, random light pattern every frame. Definitely not the result I was after.
I thought back to a previous threading issue with the Raster Render and wondered if this might be the root cause here. I run AoI on Windows and on Mac OS X. On my windows machine I was able to restrict the AoI Java process to a single processor core. Bingo! the animation worked perfectly and I had a coherent lighting effect through the complete sequence.
Every time I re-enabled multiple cores the 'noise' re-appeared. My hunch is that, for each animation frame, the random number sequence generated by the raytracer, although seeded, is being 'jumbled' because of different threads reading the next random at unpredictable times.
I did try using the new 'ThreadLocalRandom' class (Java 7) instead of the normal java.util.random but this cannot be seeded and so gave the same noisy result. I don't sufficiently understand the threading architecture of AoI to be able to solve this myself.
It would be nice to resolve this problem so that AoI can use the full set of processor cores for raytracer animations using GI.
Could you post an image or movie showing what you mean? The random seed is indeed different for each frame, but if you're using enough photons to create a converged image that shouldn't matter. What settings do you have for photon mapping?
I thought the seed was the same for each frame. Indeed, that is the key to making each rendered frame use the same sequence of random numbers and thus reproduce the same lighting effect per frame (this works with a single processor forced upon AoI). I think the problem is related to the asynchronous nature of mutliple raytracer renderer threads (launched by the ThreadManager ) when using more than 1 processor core.
Perhaps it isn't possible to use multiple cores *and* reproduce the same sequence of random numbers across mutiple rendering threads.
I will try to post the scene file and two movies somewhere to show you what I mean. I use Photon Mapping (Direct), 500 total photons, 50 estimator photons. I know this setting will not give 'realistic' results, but it produces fast renders, and if the random sequence is reproduced for every frame then the results are coherent across frames. It looks good and that's what really matters to me. On Mac OS X I don't think it is possible to choose processer affinity so you will always get the 'noisy' result if you have a multi-core machine. Although I did check that I could get the 'nice' result by recompiling the ThreadManager and setting the number of cores manually to 1. It worked fine that way :-) but was of course much slower.
Here goes with some YouTube videos and a Google Docs link to the scene file. Hope this works first go as there is no edit function on this Sourceforge forum. Pants!
The 'nice' animation, single processor core, single thread:
The 'noisy' animation, muli-core, multi-threaded:
The scene file:
"You may use standard BBCode tags in your post." Yeah?
I see what you mean. Here's a simple change that ought to fix this for you. Line 121 of PhotonMap.java is
ThreadManager threads = new ThreadManager();
Immediately after that, add this line:
That will make it use only a single thread for building photon maps.
Also, could you do an experiment? What happens if you use Final Gather instead of Direct? I'm interested in 1) does that make the problem go away, and 2) how much longer does it take to render?
Thanks Peter. I will try the patch to PhotonMap.java and will also do some experimenting with final gather versus direct. I'm away at the moment but will be able to do this in the next week I reckon
A summary, to be followed later by some links to short demo movies.
1. Setting the number of threads to 1 during building the photon map worked. There is now coherence between frames, using direct photon mapping. Nice short render time compared to a single thread ray trace. :-)
2. Using final gather instead of direct (but using multiple threads to build the photon map) does not solve the problem. The flashing between frames is still clearly visible. Additionally there are numerous 'sparkles' presumably due to the final gather .
3. Using final gather with a photon map built by a single thread removes the flashing between frames but does nothing to alleviate the 'sparklies'.
4. I used 500 total and 50 estimator photons in each case and used 1 ray to sample environment with final gather.
5. Final gather takes about twice as long to render each frame compared to direct.
6. I also tried restricted the ray tracing step to a single thread with final gather, but this mad no difference other than taking about 4 times longer to render :-(. I still got the 'sparklies'.
The sparkles are caused by insufficient antialiasing. You didn't say how many rays/pixel you're using, but try increasing that and/or the rays to sample environment.
50 photons to estimate illumination is a very small number, so I'm not surprised the results don't look good. The default is 200…
I was deliberately using ridiculously low numbers of photons thinking that although the renderd images would be noisy they might exhibit some coherence between animation frames. I was not using any antialising either.
I will do as you suggest and use more rays per pixel and also play around with more rays to sample the environment.