PhotonGI cache

[B.Y.O.B.]

In my main 3D app Cheetah3D this problem doesn't exist and whenever I port an interior scene with sunsky into Blender I have to put it into a Box for shielding, and the box has to be black or light will even leak through solid double geometry walls!

Maybe the issues come from the export/import? For example excessive scale in object space, or extremely large/small models, causing floating point precision issues? (anyway, offtopic, and I guess you already checked for these possibilities)

[lacilaci]

I tried changing scene scale, model scale, normals, shaders, tesselating mesh, modifying mesh. Changing settings...

If the cache lookup is smaller than wall thickness only then it won't get through. In every other situation it will go through mesh near corner if it's directly exposed to light (tested only sun and sky)

[Dade]

If the cache lookup is smaller than wall thickness only then it won't get through.

Yes but this is expected, the radius must be smaller of significative geometry features. I mean otherwise you could use a huge radius and render all the scene with just a single cache entry.

Just render a single plane with a box over, if the radius is larger than the box, light will start to leak from one side to the other. The test with cache entries is purely based on distance so, like I said, it is expected.

Given the pre-processing speed (and the insanely low memory usage) of current implementation, it hasn't a particular cost to use smaller radius.

In older implementation, you where pushed to used larger radius to reduce the rendering times (i.e. fixed by photon accumulation over cache entries) and to smooth the cache entries (i.e. fixed by cache filtering).

[lacilaci]

If the cache lookup is smaller than wall thickness only then it won't get through.

Yes but this is expected, the radius must be smaller of significative geometry features. I mean otherwise you could use a huge radius and render all the scene with just a single cache entry.

Just render a single plane with a box over, if the radius is larger than the box, light will start to leak from one side to the other. The test with cache entries is purely based on distance so, like I said, it is expected.

Given the pre-processing speed (and the insanely low memory usage) of current implementation, it hasn't a particular cost to use smaller radius.

In older implementation, you where pushed to used larger radius to reduce the rendering times (i.e. fixed by photon accumulation over cache entries) and to smooth the cache entries (i.e. fixed by cache filtering).

But wait, I understand that a large radius will leak through geometry like in your example. But I don't understand that in the situation I posted, how do cache entries from sun even end up inside the box? They aren't leak from outside are they?

[Dade]

But wait, I understand that a large radius will leak through geometry like in your example. But I don't understand that in the situation I posted, how do cache entries from sun even end up inside the box? They aren't leak from outside are they?

Isn't the sun hitting the floor outside the box ? I assume the sphere centered on a cache entry inside the box will include photons hitting the floor outside the box (if the radius is large enough). Filtering may further aggravate the problem by averaging cache entries inside and outside the box.

[lacilaci]

But wait, I understand that a large radius will leak through geometry like in your example. But I don't understand that in the situation I posted, how do cache entries from sun even end up inside the box? They aren't leak from outside are they?

Isn't the sun hitting the floor outside the box ? I assume the sphere centered on a cache entry inside the box will include photons hitting the floor outside the box (if the radius is large enough). Filtering may further aggravate the problem by averaging cache entries inside and outside the box.

Oh, so it's the whole radius of the sphere that creates photons even in the inside? I thought that if the cache hits a surface it is the only surface that will contains photons.

Couldn't the photon creation be limited by surface angle? So the photons could be created only up to a certain degree from surface normal that has been hit?

[Dade]

PhotonGI is now fully supported on all path tracers (PATHCPU, PATHOCL, TILEPATHCPU and TILEPATHOCL).

[Dade]

Oh, so it's the whole radius of the sphere that creates photons even in the inside? I thought that if the cache hits a surface it is the only surface that will contains photons.

It works in the opposite direction. The visibility map phase will create an (empty) cache entry inside the box. The photon tracing phase will accumulate photons hitting all the points inside the sphere around the cache entry. And the the test, if to accumulate on the cache entry, is purely based on distance and normal angle test (i.e. the 2 cache look up parameters).

Couldn't the photon creation be limited by surface angle? So the photons could be created only up to a certain degree from surface normal that has been hit?

It is already like that but the normals of the box bottom and the floor are the same (they both point up).

[Dade]

I also think that angle parameter should be hidden and materials should be cached as if no bump was applied.

I have switched from using shading normal to geometry normal in PhotonGI. So bump/normal mapping is now ignored.

It seems to work fine but it is hard to predict, give it a spin.

[lacilaci]

I also think that angle parameter should be hidden and materials should be cached as if no bump was applied.

I have switched from using shading normal to geometry normal in PhotonGI. So bump/normal mapping is now ignored.

It seems to work fine but it is hard to predict, give it a spin.

will try once it's built...

For excessive bump effect it would be better in the future to use microdisplacement/displacement(once implemented) and at that point it will be geometry.