Sorry for the delay in responding, I was traveling last week. I see that you talked about the prototype plugin I made to facilitate experiments Patro. I read the comments and there are people who are true in some aspects and others apparently have not studied the subject (no offense, I am too ignorant in most aspects of luxrender). The plugin is basically a copy of infinitesample with some additions to load 3 maps (could be just 2, that is irrelevant at this point) and use them to perform the rendering.
Luxrender is photorealistic, we try to keep this aspect, but if we think this way we'll be forgotten integrators such as photon mapping, irradiance cache, igi they are biased. We may use only and bidirectional path tracing, which are physically incorrect. The idea is to fool the human eye into believing they are seeing something real. Create a real illusion, that is our goal. All architecture for augmented reality I did not physically consistent, but delivers results that trick very well. My idea is to make anyone to use these resources and can produce good quality results with minimum effort.
Returning to iblinfinitesample:
- I recommend you read how the plugin infinitesample http://www.pbrt.org/plugins/infinitesample.pdf
, so that they understand the benefits of using one large and one small map. It is clear that we will use a lot of memory to load the maps, but the cost of calculating lighting for each sample will be lower, which will save time! our great villain when it comes to photo-realistic effects. Can see that in the infinitesample the map is transformed into a map of importance of same size as the original map and each sample (u, v) should be sought within the map CDF. If the CDF is large the search delay (which is what Patro was doing tests with large maps. As an assignment to test the plugin with a small map (512x256 or 1024x512) and then with a map 8k or more and you will see what I mean .) I have worked deeply with lighting plugins pbrt know why luxrender also inherited these problems.
- On the use of LDR as background maps. It has advantages and disadvantages.
+ Advantage: little size.
+ Disadvantages: can cause problems when you tone mapping. LDR must upload an image compatible with a tone mapping that will be applied in the rendering, to maintain photorealism.
The plugin I made for Patro has shortcomings, because to properly paint the bottom would have to change some kernel of luxrender methods to eliminate these effects of blur in the background. I made the changes in my version and will post the results on the next block.
The advantage is that we can coseguir plugin as well as with infintesample Got me, only using less memory if we use a mixture of small maps and large gain in processing speed (also could win in modifying infinitesample processing. I will do it and I will be sending the results later.)
Another advantage is that we adjust the results, a good help for those who use the luxrender as a tool for rendering, as it can get blur effects like reflections, shadows a little more diffuse, and maintain the light background and without additional blur. I understand that the blur in reflections should be n fact a reflection of the material property and would not have to modify the light to achieve this. But now think about how the ray tracing, the rayosale percorre camera and the scene. Physically? light reaches the eyes, just the opposite. Well the computer has to be done differently, but we can get the same visual effect, and that's the idea here.
Well guys, sorry for from and to English, but I did it with the help of a translator because there were many things to say. So if there is any doubt, without fear to post.