Using this raytracer for generative art. A comment and a question.
I really enjoy using this collection of raytracers. Very very very fast. I haven't touched my GPU renderers since compiling yours. I am constantly impressed by the quality of long renders, and the speed where nice proofs appear. Since I use it to create generative art I don't care if it isn't fully featured.
Also, the biggest amazon EC2 instance enables cloud rendering with your engine. No OpenCL fuss. 60GB + Dual Xeon. It's fast!
Now for my question, I'm trying to pick apart the code to stick a 'std::cout<< currentIterationOfSPP << "\\n";' so I can get a stdout of the progression of a render to the file. If I set the SPP to 1024, where can I output the count from 0 -> 1024 ?
The renderer subdivides the image in a number of tiles to be rendered. You can output the current status by printing how many tiles got rendered in theIntegratorRenderer::renderThread() function. You should protect the printf by some mutex as this function is executed from multiple threads.
I managed to implement file export during the render within the GLUT loop, but how would I export the current render to a file during a long export? It seems the embreeDevice isn't being used?
I really appreciate your help, my work is being included in an art show in partnership with St Jude Childrens Research Hospital here locally and I am going to use your renderer to create a very large print. I will be sure to post a link on this forum when the work is complete and I will somehow credit you both in the literature for the event. =)
If I understand correct you want to export to a file during render to see the current status? This would have to get implemented in the backend inside the renderer. You could for instance add anstoreImage(film,"image.jpg") after the film->normalize() call in the IntegratorRenderer. But make sure to protect this call by a Mutex and not too call it too often!
How long do you expect your renderings to take? Isn't the status bar you implemented sufficient to track the progress?
This has to do with tile settings and accumulation but I cannot figure it out for the life of me. I just want to render to disk without a GLUT window, and periodically save the current progression to disk.
I understand it has to do with the number of tiles, but could I sample all the tiles at an SPP of 1, then save to disk, then resample all the tiles, then repeat the save to disk?
I would like the outputMode() function to behave like the displayMode() function by feeding the framebuffer back into the sampler. If I am simply totally mistaken as to how this software operates, I apologize. Thank you!
I utilize cloud resources for rendering and the instances can often go offline. I would like some insurance during the render that at least the current progress is recoverable by performing a periodic write to disk.In outputmode it is not rendering the entire image each pass and instead rendering individual tiles to the max SPP. I create some scenes that are purposefully complex and can benefit from 22,000 SPP and a 512 depth.
"Live mode" with GLUT seems to use very little memory compared to outputMode() which seems to hold all the samples in memory at once?
I'm going to try to create a 3rd mode that launches no glut window but uses it's scene settings so I can launch with progressive whole frame periodic saves in the cloud.
Again, thank you for this wonderful tool. I am building a tool that uses the Processing creative coding framework (http://processing.org) and a Half-Edge mesh procedural mesh generation libarary to export scenes that Embree can read and render, I think it will become a popular tool because your renderer is very high quality compared to the alternative open source renderers (luxrender, slg, cycles, etc.)
It is also nice to read the code of actual scientists.
Embree runs on both,Intel Core andIntel Xeon processors. Xeon is preferrable, because you can put multiple processors into a single machine and the maximum number of cores per processor ishigher. Embree's rendering performancescales almost linearly with the total number of cores and the clock rate. The more the merrier!