developing IBL illumination

[binarycortex]

using 2 or 3 hdr mixed toghether it's only a complex artificial lighting with more than a light source.... why this couldn't be accurate. i can't see how this could demage Luxrender.

I didn't say it would damage luxrender, I was responding to the whole surreal thing. It's great that people have figured out how to do surreal renders with LuxRender. But like it says, if this addition compromises quality or is not physically correct, then it won't make it in. I welcome the idea, and as I said before, we probably only need 2 slots, one for a small hdr to provide lighting and one for the high quality jpg or hdr for the reflections and background image. That would greatly save on memory usage. *thumbs up*

[vimax]

The issue I still see here about the 2 suggestions is the thing that jeanphi mentioned earlier that is:
1. in case it uses a high quality jpeg it loses the physical correctness in a certain range of exposures
2. in case it uses a high quality hdr it doesn't save memory, in fact it adds a bit because you also have to load the low res hdr as well.

[moure]

i provide you here some info regarding reflection and background mapping i found on fryrenders manual,

Background mapping

Sometimes, particularly in archviz, it is common to face the need to use a real photographed background behind your scene. Such is the case when the real landscape of the location must be seen through the windows of your scene, etc...

This can be achieved by rendering the alpha channel along with your scene (explained later in this manual) and doing some post-processing afterwards, but there is an alternative choice, which is to use a background map. Background maps are NOT part of the illumination of the scene. They do not illuminate, and they do not enter the GI at all. This has some non-intuitive implications that lead to very common misconceptions:

* The background map does not illuminate anything. It is just an image the engine uses to substitute the pixels of the render where the camera sees the background directly.

* The background is visible if seen directly ONL Y, which means that it will NOT be seen through glass, or any other objects, regardless of how transparent they are.

* Due to the same reasons, the background map will not be reflected by mirrors or glossy objects at all. Literally, the background map does not exist in terms of GI (illumination, reflection, refraction... are all the same thing in the context of a physically-based render engine).


The main advantage of using a background map instead of doing post-processing with the alpha channel is that the BKG map resolves the antialiasing and DOF blur of the contours of your scene correctly, while that takes some tweaking when an alpha channel is involved. On the other hand, the main drawback is that with an alpha channel you have a higher degree of control over positioning and color matching in post-processing.


Reflection mapping

Sometimes when rendering exterior shots in archviz it is desirable to make the glass in the windows reflect a real environment. But on the other hand, modeling a real environment for it to be reflected is too costly in most cases, and using a real HDRI environment or a photograph is just not compatible with the physical sky system.

Our engine provides a simple method to achieve this called Reflection mapping with which you can set a map that will override the reflections of mirror-like objects that reflect the environment directly, without affecting the GI of the scene.

A very common pitfall is to think that the RFL channel will affect all kinds of objects. In the context of a physically-based renderer, reflection and illumination are the exact same thing, so the engine could not detach the illumination of glossy or lambertian surfaces from their reflection (there is no such thing as components in fryrender). Being so, the RFL channel works for materials with Roughness = 0% only, and is ignored completely for all other materials.

my opinion is that having options like these should be part of luxrender and leave the option to use it or not to the user.

[patro]

The issue I still see here about the 2 suggestions is the thing that jeanphi mentioned earlier that is:
1. in case it uses a high quality jpeg it loses the physical correctness in a certain range of exposures
2. in case it uses a high quality hdr it doesn't save memory, in fact it adds a bit because you also have to load the low res hdr as well.

hmmm,
thought you misunderstood one point.

* if the plug will implemented.... you must don't use it, you can still use the "environment" one with "infinite" or "infinitesamples" *

you try to compare a 8K jpg 35Mb + 3K HDR 10Mb with a 8K hdr 200Mb.
you try to compare a total memory usage of about 200 Mb with one of about 1.5 Gb per map.

please also consider that a 8K latlong hdr can be used as background and rendered at a maximum width of about 3000 thought...
the latlong image is projected spherically, this mean that you will render only a portion of the for you visible half sphere background.
with larger render you'll notice increasing background pixels or fuzzyness. this mean that for greater render you will need a 8K hdr for reflection and a 16K jpg for the background.
the plugin is helpfull.

[aldozang]

hi guys,
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.

Thanks,

[aldozang]

Another thing I'm outstanding in the previous topic is that it can be avoided using HDR if we already have the image we want in the background. This is what I implemented for augmented reality, is not yet available but it is a possibility of using smaller maps for lighting and reflection and HDR have a background of high quality and equal in size to render. In the case of wanting to use the background of a portion of a mapar HDR, the best solution for now would place the camera, a light infinitesample with map large HDR rendering, this way to get only the background as a result of the render hdr. then use this as a background render in the render target. In this way results would be obtained with high quality and low cost of memory.

[aldozang]

Examples images with iblinfinitesample and infintesample plugins:The background map is the same for the 4 examples. I have used the 4000x2000 hdr image for background and a blured image for the lights and reflections in case 2 and 3.

image 1: buddhatestif.png : used infinitesample with the 4000x2000 hdr image of the environment map.

image 2: buddhatest1: used iblinfinitesample 4000x2000 hdr image for background and a hdr image with little gaussin blur for the lights and reflections.

image 3: buddhatest2: used iblinfinitesample 4000x2000 hdr image for background and the small blured image gived with the ueno map for light and reflections.

image 4: buddhatest3: used iblinfinitesample 4000x2000 hdr image for background and a hdr image with normal gausian blur (15pixels ratio) for the lights and reflections.

Adding mor blur in the lightmap you can obtain more blured reflection on the objects.

[patro]

Hi Aldo,
did you try to swap the position of the small reflection hdr with the small blured hdr?
i think that the resulting image is better.

[jeanphi]

Hi,

I don't see the point of the blur. If you want blurry reflctions, just use rougher materials, but keep the map plain. If you think there's a real speed advantage in having blurry maps, then we should reinstate the RayDifferential class and use mipmaping on the light map like PBRT does. But we removed it for speed reasons...
Here are the 2 points I see that could be improved with the current infinite light scheme:
- use a smaller sampling map that would be used to sampled the full size light map (thus getting good lighting accuracy in all cases but with less memory and faster lookups, however lookups are already logarithmic thanks to the standard library implementation)
- use a specific background image so that the details are preserved when the map is directly seen (otherwise even with a 8k map, a pixel of the map will span several pixels in the render)

Jeanphi

[patro]

Hi Aldo,

any news on this plugin? or is it just finished like is it?
thanks