16 bit Floating point format

Started by
16 comments, last by ma_hty 15 years, 9 months ago
I'm sorry. The information you provided are just too confusing.

Why "Light information is missing or calculated wrong for ~50% of the normals."?

What are you expecting actually? And, how do you arrive such a expectation?

By the way, you have a demo program, right? Why don't you just reproduce everything faithfully before making your own interpretation?
Advertisement
Quote:Original post by ma_htyI don't think the alignment can be a problem at all.


I must stop posting late at night... For some reason, while I knew he was using floats, I was thinking "hmm half floats + npot could get messed up". Oh well :)
I whish I could reproduce that demo, but the problem is that I'll have to translate everything to Delphi instead of C++, OpenGL instead of DirectX, and Cg instead of HLSL. I can't run the ATI demo neither, since I don't have a DirectX10 computer. I did compile the original SH generation functions in C++ though, just to make sure I did not make a C++/Delphi translation error on that part.

I expect the scene to be fully white, because white light is coming from all directions. The ATI demo renders a tiny environment map for alot of points in the world. These cubemaps are used to check how much light is coming from each direction. This simulates Global Illumination. For example, if I place a probe on the ceiling, and render the floor beneath it with a light shining on it, the light will 'bounce' towards that probe. When rendering the world normally, each pixel will pick the most nearby probe and use the data. The environment maps are encoded into 12 SH coefficients (4xfloat4 for red, 4xfloat4 for green, and 4xfloat4 for blue).

I fake these environmentMap by just using white pixels for all directions:
<pseudo code for calculating SH coefficients for 1 probe>float3 environmentColor = texCUBE( envMap, coords );> replaced byenvironmentColor = 1;

This basically means that white light is coming from all directions. So if I render a certain pixel, it does not matter what its normal is, since the SH coefficients dot product with the transfer function *should* always give a white color as result. Unfortunately, that is not the case. I had a change to upload a picture demonstrating the problem:
http://img246.imageshack.us/my.php?image=globalillumwrongfh3.jpg

The white tiny dots are probe positions (a large uniform grid). However, I use only 1 probe for the entire world now, just to make sure the pixels are not picking the wrong probe or. Ow, and almost forgot:
dark wall on the left = -Z direction, which has a +z normal, white while on the other side = +Z, -z normal.
While behind the sphere = +x direction, -x normal.
Ceiling = +y (-y normal), floor = -y (+y normal).

What I said about 50% black is not true. It seems that the direction +z, slightly towards -x, is dark. It results in dark spot on the sphere. It's not sure the other directions are correct though.

Greetings,
Rick
The image doesn't look like illuminated by a ambient light source. Instead, it seems to be a diffuse surface under a directional light source.

Are you sure you have turn off the direct lighting?
It doesn't look like GI indeed, but that is because the lighting is fake now. That is because only 1 probe is used, with pure white light. So yes, the result should be similiar to
"dot( pixelNormal, incomingAmbientLightDir[directionIndex] ) * ambientColor[directionIndex]"
Where incomingAmbientLightDir is an array of directions all over the sphere surrounding the probe (sample points), and ambientColor is faked with white for all directions.

Plus it's not a matter of turning lights on/off, since everything is done in shaders. If the SH part works properly, alot of probes are used, and the white light will be replaced by the actual environment maps on these probe positions. These environment maps contain the surrounding scene, litten directly. But for now I keep it very simple, for testing purposes. If you want a full description of the GI technique, please see the ATI paper that is included in the demo link I gave.


BTW,
I tried to upload the data images in the 16 bit floating point (half) format. Packing these values worked, and uploading as well. But the results of the image were exactly the same. So, the problem in this whole story can't be the SH data textures with wrong uploaded values.

Greetings,
Rick
The ATI demo has two parts.

1) Direct lighting with shadow mapping
2) SH lighting for inter-reflection

If you are trying to reproduce them, you should have 1).

Anyway, please post your Cg script for the lighting evaluation (not the one for light probe evaluation). I'm sure we can find quite a lot of mistakes there.

By the way, I have read the whole thing before my second reply, including the paper and the demo program. I don't think I missed any points you said.
Well I'll be damned. I was about to post you a gigantic message with code, until I saw a tiny bug. The decimal of a 3D texture coordinate, picking these Basis SH values, was placed wrong. 3 weeks searching, and it turns out to be a stupid number. Always the same story :|

Sorry to bother you with all these questions, I think I fixed it :) Well, now I can ask if my results are ok. I rendered the scene without that fake light, and it seems to be ok. Although the light is a little bit weak. For example, the scene is still not pure white with the fake setting. It's almost white, but some normals result into a light gray result. I guess this has to do with the randomly placed sample points on the hemisphere, used to create these SH values. If I render a probe with red for the +x side, green for +y, and blue for +z, I can see this clearly in the scene as well, but the colors are a little bit "washed out". Pure red becomes a light brownish red, blue becomes somewhat purple, etcetera. Are these normal results?

I think I can reach my goal now, maybe powering up the indirect lighting somewhat to make it a little bit more intense.

Thanks for helping and your patience!
Rick
SH basis is efficient for handling low frequency lighting only.

You can expect that the result due to SH lighting will be very blurry. That's the limitation of SH. Not much you can do about it.

This topic is closed to new replies.

Advertisement